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:
- What bandwidth is available up and down?
- 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.
- Match the codecs and order at the extension level.
- Is QoS enabled at the router side so that it can prioritize packets leaving the site?
- 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.