Understanding Avaya Codec Selection

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 to 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.

Mischief Managed

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.


  1. jitsusama · · Reply

    Mischief managed, I totally got that reference🙂

  2. Is there any solution in AVAYA end to end HD voice codec (Softphone to customer ) no avaya hard phone 96XX.

    1. 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.

  3. Nikhil Reddy · · Reply

    You r awesome for the way u explain how stuff works!!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: