cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4986
Views
5
Helpful
8
Replies

CUCM and CUBE Codec Negotiation

Robert Shaw
Participant
Participant

Hi Guys,

I appreciate that this topic is covered quite in depth both on the forums and official documentation.  I'm having trouble digesting all of the information into something useful.

I'm having trouble with Codec Negotiation between my ITSP -> CUBE -> CUCM.  My regions between CUBE and IP Phones are set to G729 and my Dial Peers are all set to use a Codec Class configured with G729 in first place.  However, on some calls (mostly seems to be inbound) I'm still getting G711 selected and having to use local Transcoder resource between the Phone and ITSP.

This is my environment,

CUCM 9.1.2

CUBE 2921, Version 15.4(3)M3,

When I run,

sh sccp connections
sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx

34423059 37580882 xcode sendrecv g729 25536 16600 10.0.11.155
34423059 37580881 xcode sendrecv g711a 25568 25554 10.0.5.3
34423065 37580946 xcode sendrecv g729 25220 20688 10.0.13.38
34423065 37580900 xcode sendrecv g711a 25212 25558 10.0.5.3
34423072 37580953 xcode sendrecv g729 25496 23954 10.0.51.79
34423072 37580952 xcode sendrecv g711a 25444 25278 10.0.5.3

Total number of active session(s) 3, and connection(s) 6

I can see a number of active calls using Transcoders.  The local leg is using G.729 between phone and CUBE, but the ITSP end is using G.711.

I have run through some sample outputs of ccsip messages and can see the majority of calls do negotiate with G.729 for both call legs but there is the odd call, (mainly inbound) that negotiates at G711 with the ITSP even though G729 is offered as the preferred codec.

How do I go about troubleshooting this to identify the reason why G711 is being negotiated with the ITSP?

I have attached a couple of outputs, one showing an example call where G711 is being selected with CCSIP Messages and debug voip dialpeer inout enabled.  The config is the Dial-Peers and relevant Voice Class Codec.  Please let me know if you need to see anything more.

1 Accepted Solution

Accepted Solutions

It absolutely works SIP to SIP. I have used that in customer networks. Your solution of removing G711 from the codec list bears out what I was saying. You present an ordered list on each leg when CUBE is involved in the codec negotiation. The calling side (ITSP in this case) can pick anything from the list. If you use transparent, CM wouldn't offer G711. Forcing it to G729 will break and faxing over that ITSP, so keep that in mind.

View solution in original post

8 Replies 8

Mohammed Khan
Cisco Employee
Cisco Employee

I don't see any issue in Voice gateway config, Looks CUCM is doing something wrong here.

Can you collect Detailed Cisco Callmanager logs for working and non-working sample call.

Regards,

Mohammed Noor

Refer below link to collect logs

https://supportforums.cisco.com/document/126666/collecting-cucm-traces-cucm-862-tac-sr

Elliot Dierksen
VIP Engager VIP Engager
VIP Engager

The calling party has the option to select any codec from the list you offer, even if they select one that isn't at the top of the list. My suggestion would be to change your CUBE to use "codec transparent" on the dial peers to the ITSP and to CM. You will almost certainly need a SIP profile that forces early offer on the SIP trunk to the CUBE. Then CM is in control of the codec negotiation. Right now, CUBE makes its choice with the ITSP, and CUBE and CM do a separate negotiation on the leg between them.

Hi Elliot,

Thanks for the response.  I just did a little reading up on this and it appears that its for H.323 to H.323 calls only.  Have you seen it working in a SIP to SIP environment?  Is it possible that the cause could be the phones?  The majority of the phones we have are the old SCCP models, we have very few of the newer SIP phones.

Thanks

Rob

It absolutely works SIP to SIP. I have used that in customer networks. Your solution of removing G711 from the codec list bears out what I was saying. You present an ordered list on each leg when CUBE is involved in the codec negotiation. The calling side (ITSP in this case) can pick anything from the list. If you use transparent, CM wouldn't offer G711. Forcing it to G729 will break and faxing over that ITSP, so keep that in mind.

Thanks Elliot, I have separate Dial-Peers forcing G711 for faxing.  Thanks a lot for your help.

Robert Shaw
Participant
Participant

Just in case anyone comes across this in the future.  The problem was my voice-class codec list contained G711.  It must have been that my ITSP was seeing that G711 was an option and selected that rather than my preffered codec G729.  I created a new Voice-class codec list containing only G729, applied this to my inbound and outbound dial-peers and it works perfectly.

Thanks everyone for your responses!

jcvanwyng
Beginner
Beginner

You can keep your codec list in the CUBE to allow both G711 and G729.  I do that today because I use both codecs depending on where the call is going.  We have SIP Early-offer forced on the dial-peers.  Assuming that is what you have too, you can control the codec negotiations for inbound calls from the ITSP using Regions and codec preference lists in CUCM.  In order for this to work, you must set "Accept Audio Codec Preferences in Received Offer" to OFF in the SIP Profile.  If you do not turn that off, the prefered codec listed in the SDP of the Invite is what will be used.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers