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?
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.
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.
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:
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.
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.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...