Before IP telephony came along, you didn’t have a choice in the audio quality of your telephone call. Thankfully, calls on those old analog and digital telephones sounded pretty good. In fact, the audio was dubbed “toll quality” and for years, that was the gold standard.
Of course, that quality came at a cost. Every one of those old telephones had a dedicated set of wires back to the PBX (Private Branch Exchange) and that PBX was all filled with costly and space consuming line cards. This made mobility impossible since telephones were tied to physical locations and not to users.
With the invention of the IP PBX, enterprises were able to replace those single-purpose wires with shared network cables that served both the voice and data needs of their employees. Also, all those line cards became unnecessary as thousands of telephones connected to an IP PBX over a single Ethernet interface.
In addition to eliminating wires, line cards, and the gateways to house those cards, telecom administrators were now given control over audio quality. If bandwidth was a concern, telephones could be assigned a low bandwidth codec like G.729 or G.726. If bandwidth was plentiful, those same telephones could be told to use higher bandwidth codecs such as G.711 and G.722.
For a deeper dive into audio codecs, please refer to my articles A Cornucopia of Codecs and Codecs Continued.
It needs to be understood that low bandwidth codecs don’t necessarily create a lousy audio experience. While the difference is noticeable from their higher bandwidth brothers and sisters, the audio quality is still pretty good.
It’s also important to understand that codec choice isn’t stagnant. In other words, the same telephone could potentially use G.711 for one call, G.729 for another, and G.722 for yet another. The beauty of IP protocols such as SIP and H.323 is that they aren’t tied to a particular codec and codec choice can be made in a fairly dynamic manner.
Communication Manager Codec Assignment
In Avaya, codec assignment is a multi-step process. First, you build Codec Sets that define lists of codecs, the parameters associated with those codecs, and encryption options. Next, Codec Sets are assigned to IP Network Regions. IP Network Map entries are then associated with IP Network Regions. IP telephones map to IP Ranges thereby creating the link between telephones and IP Network Regions. Lastly, Codec Sets are associated with the logical links between IP Network Regions.
This may sound complicated, but it’s really not that bad.
Let’s start with a Codec Set. For this example, I defined four codecs and two encryption methods – three if you count no encryption (none) as an encryption method.
Next, I built an IP Network Region. Notice how Codec Set 1 has been assigned to that IP Network Region.
Note how the IP Network Map references an IP Network Region.
Lastly, see how Codec Sets are assigned to IP Network Region to IP Network Region communication. Item 1 tells you that this is IP Network Region 1. Item 2 tells you that Codec Set 2 is used for communication between IP Network Region 1 and IP Network Region 21. Item 3 tells you that Codec Set 1 is used for communication between IP Network Region 1 and IP Network Region 24.
Breaking all this down we have the following.
- Codec Set 1 contains four possible codecs and thee encryption methods.
- IP Network Region 1 will use Codec Set 1 for all intra-region communications.
- All IP telephones in the address range of 10.100.4.0 to 10.100.4.255 will be in IP Network Region 1.
- A different Codec Set, Codec Set 2, will be used when a device in IP Network Region 1 calls a device in IP Network Region 21. You might do this because the bandwidth between the two regions is limited. To allow the maximum number of calls across this pipe, Codec Set 2 would only contain low bandwidth codecs such as G.729.
Choices Within Choices
If you understand Session Description Protocol, it should not come as a surprise that multiple codecs are listed inside a Codec Set. This is the nature of IP communications.
The same idea of presenting choices is true for encryption methods. The way this works is that the top method will be tried first. If that fails, the second method will be tried. If that still fails, the third method is tried.
In my example, the third method is “none” which means that if it is chosen, media will not be encrypted. I would only use “none” if you had to support telephones that cannot perform encryption and decryption.
To keep things simple, my configuration was fairly basic, but accurate. The point is that an administrator can use Codec Sets and IP Network Regions to balance quality and bandwidth.
We no longer live in a world where one size fits all and with the proper configuration, you can easily build a highly tuned platform for quality VoIP communications.
Mischief managed, I totally got that reference 🙂
Is there any solution in AVAYA end to end HD voice codec (Softphone to customer ) no avaya hard phone 96XX.
I can’t think of one. HD to the customer would require that the PSTN supported that, and it doesn’t. At this point, the Avaya WebRTC solution is only G.711 so that wouldn’t work, either.
You r awesome for the way u explain how stuff works!!
You are covering much needed topics that even Avaya didn’t documented well .. or at-least short and precise like you did … Really really helpful.. thanks!
If possible please post on CM-SM trunks usage on internal calls when SIP phones administered as ops off-pbx-stations.
Like can we use separate trunks for intra-location and inter-location calls on same CM-SM system.
challenges if any.
can we use different trunk to route off-px SIP requests from SM to CM other than application sequence trunk.
many thanks for these articles. Short question here:
What is the codec selection mechanism in the following scenario?
What drives the codec selection? Whoever starts the conversation?
The entity that sends SDP last gets to choose. That is part of why early and late offer are so important.