cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1275
Views
5
Helpful
6
Replies

Voice class codec issue

Kalyan iyer
Level 1
Level 1

Hi,

I have a sip trunk terminating on a CUBE. On the CUBE, I hard-code the dial-peer 211 with G.729 codec. On an inbound call to a DID terminating on the IP phone, the call negotiated g.729 and completed successfully. No issues.

Now I created a voice class codec with 2 codecs in the following preferences

voice class codec 1

codec preference 1 ---> g729

codec preference 2 ---> g711

I then apply this to a dial-peer 211.

On an inbound call from the same incoming number to the same DID(same endpoint), this call is now negotiated only at G.711 codec. I verified that I am hitting the same dial-peer by using "show call active voice brief" and checking the pid. It is using dial-peer 211.

My expectation is that the call will still negotiate G.729 and will use G.711 only if the call cannot be completed at G.729.

As a test, I also verified by removing codec preference 2 (i.e.) G.711 from voice class codec 1 and call negotiated at G.729.

BTW, in each scenario, I used the show voice call active compact to verify the call legs and codecs being used.

CUCM version 9.1 and IOS 15.1(4). Any ideas why this odd behavior?

Regards,

K iyer

6 Replies 6

Chris Deren
Hall of Fame
Hall of Fame

Are you using Early offer or delayed offer?  Look at your invite SDP message as to what capabilities are sent and negotiated, depending on whether you use early or delayed offer it is the other side that decides.

HTH,

Chris

Thank you for reply. Early offer is being used.

From the SIP traces, I see that the when the call comes in, the service provider (in this case Verizon), sends the SDP both G729 and G711 in their SDP. CUBE sends in its invite to CUCM both G729 and G711 in that order. I see CUCM sending an OK message back with G711 as the accepted codec. When the dialpeer is hardcoded with G729, CUBE sends G729 as the only codec to CUCM and CUCM sends a 200 - OK with G729 back.

What is the region between the SIP trunk/GW in CUCM and the end point? if it is G711 then this works as expected.

Chris

hi,

please try this.create the region with G729 only and assign it to your phone device pool .

mkchandak
Level 1
Level 1

Here is the catch with CUCM. CUCM always prefers and will use the "best available codec" offered. Therefore, when the gateway forwards the setup to CUCM, it would see g711 as a valid option and would use it. Here is more info on the same:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/9_1_1/ccmsys/CUCM_BK_C5565591_00_cucm-system-guide-91_chapter_0101.html#CUCM_RF_RE6237E1_00

Regions

Regions provide capacity controls for Cisco Unified Communications Manager multi-site deployments where you may need to limit the bandwidth for individual calls that are sent across a WAN link, but where you want to use a higher bandwidth for internal calls. Additionally, the system uses regions also for applications that only support a specific codec; for example, an application that only uses G.711. Use regions to specify the maximum transport-independent bit rate that is used for audio and video calls within a region and between regions; in this case, codecs with higher bit rates do not get used for the call.

Cisco Unified Communications Manager prefers codecs with better audio quality. For example, despite having a maximum bit rate of 32 kb/s, G.722.1 sounds better than some codecs with higher bit rates, such as G.711, which has a bit rate of 64 kb/s.

HTHs

Please rate helpful posts.

Thank you all for the response. I understand that if the bandwidth is available to do G711, it will choose the best available codec. But the phones and the CUBE are connected through regions that are set up for only G729. Also on CUCM 9.1, there is the audio codec preference list where I have G.729 prioritized above G.711. I am not sure what else needs to be checked.

Regards,

Kalyan