Changing codecs for better quality calls


Hi there

We have a UCM6510 with about 15 GXP2170 phones. We have been having poor call qualtiy, chopping of sound, signalling issues and so forth. I have tried changing the codecs so we can use G723.1 or G729AB, however it never sets. I have set it on the phones themselves, and on the PBX itself, however all calls just default to PCMU and the issues remain. This system is so frustrating and Im really starting to regret purchasing. I have been using wireshark to try to diagnose the problems but grandstream misses most of the data except for the prior 10 minutes so by the time i have found out there are phone issues i miss the corresponding data to troubleshoot. Can someone point me in the right direction please?


Of the top of my head (meaning, I’m not in front of a system at the moment to confirm) there’s a couple things to consider.

If you’re trying to set the trunk codec, whatever you select must be supported by your provider.

The first handshake will negotiate between the system and the provider.

So, if you have 729, 711u, and 711a selected in the UCM but the provider has only activated 711u, during the negotiations, the system and provider will decide on 711u.

The second handshake is between the UCM and the phone extension.

While you can have the extension and the UCM on one codec and the truck on another just fine, the transcoding can cause problems.

My personal ideal is to use the same codec everywhere.

Regarding setting the extension codec, you can look in the extension itself, the global template, the (I forgot the other) template, and the model template.

Also, I’ve seen troubles because someone turned on the jitter buffer when it was not needed.


Costwise has it right.

However, let’s take it a step further -
It sounds like you still have PCMU set on the extension side. To CW’s point, you may have a low rate codec on the provider side and then on the extension side the higher rate PCMU/g711u. As it is not possible to improve the sound quality over what the source provides, you are indeed best off setting the same codec throughout the system.

However, before changing things, how are calls between extensions?

As the UCM really does not understand the physical difference between an external call and one that is internal (it only sees and processes data packets as they are delivered), if internal calling between extensions is fine, then the UCM is not at fault.

The choppiness you refer to is known as jitter. Jitter is a form of latency in that the packets are not being delivered at the same rate and in the same order as that when sent. In some cases, there may be some packets that do not arrive at all and if the situation worsens, the calls may start to drop.

Manufacturers recognize the jitter potential and many have included a jitter buffer to try and overcome some of the issues. The jitter buffer introduces a small delay (that you select) such that as packets arrive, the UCM will buffer the packets and then examine them and try and put them back into the correct order before sending to the destination. So, if packets were sent as 1, 2, 3, 4, 5, 6, 7, etc., but were seen at the UCM as arriving as 1…2, , 4, …6, 5, 7, etc., the jitter buffer will try and rearrange the packets and then stream them to the endpoint in an attempt to try and make it more like how sent. The trade-off is in how much of a buffer will you select as the delay will allow for more packets to be handled, but might also be noticed by the folks on the call. The static setting is usually more of a hardware induced delay that will always introduce the selected delay time, where as the dynamic setting is usually a software delay that will attempt to adjust automatically to the needed delay periods for the given conditions and will do so within the min and max settings selected.

The key here is that the jitter buffer is a tool that you can utilize to help deliver a better experience from a compromised source; which means you need to examine the source:

  1. What bandwidth is available up and down?
  2. What side of the conversation hears the issue, the external side, internal side or both?
    3, What codec does the provider support? Set the trunk to use only that which they do and set the order for the moment such that the lower rate codec is the first in the order.
  3. Match the codecs and order at the extension level.
  4. Is QoS enabled at the router side so that it can prioritize packets leaving the site?
  5. There are a number of web based VoIP test sites that you can use to test the line conditions. Find one and then use the available settings to approximate what your needs are and then run the test for as long as possible and do so periodically throughout the day so as to get a good feel for the connection over time and under various load conditions.


Thank you guys for all your help. It turns out that my firewall settings on pfsense had to be adjusted. I had to enable traffic shaping and setup the priq queue and set VoIP to the highest setting and then set the VPN traffic to the next highest level. Then i had to adjust the floating rules so that these were assesed first and now the calls work perfectly. A firmware upgrade got rid of a LOT of SIP registrations being lost and reconnecting in the same second. Also the codec issue appears to have sorted itself out now too with the firmware upgrade. However it appears im getting about 1 call a day dropped due to

To user: 833UCM hung up the call (send SIP BYE)! Hungup cause: Response to STATus ENQuiry

so ill have to go and figure that out now.

Thanks again for all yuour help.