Choppy Broken Audio

[[email protected]]

Getting a lot of complaints that callers cannot hear understand what is said due to choppy audio. There are a few occasions when the audio is choppy on the 3cx end. Lately, there have been a few calls where almost nothing can be heard. The problem is very noticeable on remote tunnel extensions using Windows 3cx client or Android 3cx client. We use multiple networks both hard wired and mobile network externally and doesnt seem to be a problem to any particular one of these networks. Server side, I have all TCP and UDP ports forwarded and even tried with firewalls temporarily turned off but no change to the problem. I am using G729 codec everywhere and bandwidth is not limited in any location. How do I troubleshoot this problem?

 

[Sean Glasspool]

There are a number of things I tend to do
1) Turn on voice recording. Listen to the audio and see if the calls are broken from the trunk or client side.
2) Packet Capture - perform the same thing as above pulling the audio from the pcap
3) make sure codecs are aligned. e.g, a-law on the trunk, a-law on the clients etc etc
4) Log a call with the SIP provider.
5) Log a call with 3CX.

Is the PBX on prem or hosted?

If on prem, can you apply any QoS on the firewall / router?
Can you measure any loss or jitter on the connection?

 

[eddv123]

Despite logging and Wireshark there are some checks you should do on the surface also which could identify potential issues before tracing etc.

Firstly I would take a look at this 3CX technical guide - it is a good read and covers most areas that you should investigate: https://www.3cx.com/blog/voip-howto/real-time-network-traffic-and-qos/

A couple of points I would like to extend on however:

First thing would be to review your network and see if you can identify any bottle-neck areas - WAN connections or uplinks between switches for example.

Also ensure you have enough bandwidth for the amount of calls being utilized - this guide here will assist with the calculations: https://www.3cx.com/blog/docs/bandwidth-utilised-for-voip/

As you have said you are using a compressed codec which should reduce the chances of this.

If daisy-chaining phones (using the WAN/PC ports) ensure you tag the voice traffic - data from the PC can be left as default (or lesser tagged if you desire) but the port attached to on the switch must be a trunk port if accepting multiple tagged traffic types.

If tagging locally then you must also check that your Internet Service Provider honours tagged traffic, and that it will prioritize accordingly.

3CX also provides provisioning for the phones if using VLAN's locally and Priority codes (DSCP):
https://www.3cx.com/sip-phones/vlan-configuration/ Supported phone models only.

If using DSCP (differentiated services code point) codes I would suggest using it with a Diffserv setting which can be found on most WAN routers. The issue being that any tags or settings applied on the network layer 2 side will be removed when hitting layer 3 (Router/Firewall).

Note: EF (46), is the typical marking for voice traffic.