Poor outbound audio on some calls using Cyta SIP

[NikosL]

Hi all,

We have installed 3CX (3SC Ent), using a Cyta trunk. The issue we have is that when connecting to specific external numbers, the outbound audio is very poor. On other numbers, the audio is perfect. The outcome of Cyta's investigation is that the PBX is transmitting using 200ms buffering instead of 20ms buffering that their systems can handle. The reason that other calls have excellent audio, is that they are passing through different media servers that support this buffering.

Has anyone seen anything similar?

Any help will be greatly appreciated!

 

[JohnS_3CX]

Hi Nikos,

Can you share some more information please, like how exactly the engineer came to the conclusion that the system was transmitting 200ms instead of 20?

We would be very interested in seeing the evidence they collected.

 

[NikosL]

Hello John,

Thank you for replying! I have the packet capture they performed on one of the calls (attached below). If I can provide anything additional, please do let me know and I will get it.

Cheers,
Nikos.

 

[JohnS_3CX]

I see what you mean, lets look into it a bit further.

Can you also share some more details?

- was the capture run from the pbx management console?
- do you have more than one NIC in the machine?
- does the provider give you a 2nd modem dedicated to SIP only?
- are static static routes set on the OS ?

 

[NikosL]

Hi John,

Please find the details below:

- was the capture run from the pbx management console?
No, the capture was run by the Cyta engineer directly on the modem. I also have a capture I run from the PBX using tcpdump -i, but as per Cyta, that capture didn't show any issues.

- do you have more than one NIC in the machine?
The PBX is running on a VM, which has two interfaces:
eth0 which connects to the internal network and internet
eth1 which is directly connected (through a dedicated physical interface) to the provider's modem

- does the provider give you a 2nd modem dedicated to SIP only?
No, they use a single modem configured as follows:
Port1: Bridged to our firewall for the customer's internet traffic
Port4: Bridged to the PBX

- are static static routes set on the OS ?
Yes, so that SIP traffic can be routed through the correct interface, while all other traffic goes through the public interface.

 

[JohnS_3CX]

Hi Nikos,

" I also have a capture I run from the PBX using tcpdump -i, but as per Cyta, that capture didn't show any issues. "

I think this is the most important part here. If the capture from the PBX (for that same call) did not show any issues, then you have to look elsewhere to justify the 200ms packet delta.

 

[NikosL]

Hi John,

I figured as much, but I am a bit at a loss here. The installation is a very simple one:
One physical server running Hyper-V 2012 R2, which is hosting only one VM, which is the PBX. The v-switch defines two interfaces (one that is 100% dedicated to the PBX, with a direct connection to Cyta's modem and one that is connected to the internal network of the customer). Is it possible that the physical interface of the server does this, or should I be looking from the modem and onwards?

Thanks again for your help on this!

 

[JohnS_3CX]

I'd say since this is a dedicated machine, ditch 2012R2 and Hyper-V, go bare metal with our Debian ISO

You'll be saving resources that Windows would be taking up, and you can also skip all the virtualization layers in the middle.

 

[NikosL]

Hi John,

Ditching the Hyper-V is not an option, as additional VMs will be installed in the very near future. Having said that however, I am happy to say that I have solved the problem. The culprit has been identified and it was the server's onboard NIC. I installed an additional NIC and everything works perfectly now.

I would like to thank you again for looking into this and helping out.

Take care.

Cheers,
Nikos.

 

[cobaltit]

Any chance it was related to this?

 

[JohnS_3CX]

Hi Nikos,

That's really good to know in this case, if you like share the type of NIC here publicly in case someone else faces the same issue because some NICs have indeed been shown to be problematic.