SIP Codec Negotiation Question

[kenneth.meyers]

Have a SIP Cube at a remote branch office (London).

CUCM running 9.1 at Hub location (US)

London Phones and London SIP Trunk from CUCM to CUBE are in same device pool/region etc.

Remote branch 7965 phone dials outbound (which will use the London CUBE) and CUCM sends an SIP INVITE to the London Cube with codec’s advertised of G711ulaw/G711alaw/G729 (m=audio 31030 RTP/AVP 0 8 18 101).

Inbound Dial-Peer has a Voice Class Codec of G729r8 only. CUBE sends back a “Not Acceptable Media” message.  I would think since the inbound dial-peer has G729 which is listed in the INVITE that it would select that and proceed with the call.  This is not the case. Why would the inbound dial-peer not select G729 as an acceptable codec and extend the call?

Here’s some info from the CUBE and log.

===================================

INVITE as Seen from the London CUBE @ 192.168.23.1 (172.19.108.4 is CUCM in US)

Received:

INVITE sip:9001434XXX6149@192.168.23.1:5060 SIP/2.0

Via: SIP/2.0/TCP 172.19.108.4:5060;branch=z9hG4bK18b35581cd0db

From: "London Verizon SIP" <sip:02036XXXXXX@172.19.108.4>;tag=219815~91e77be1-0818-449d-af4c-9b6a8d63e011-39811112

To: <sip:9001434XXX6149@192.168.23.1>

Date: Mon, 09 Dec 2013 13:18:14 GMT

Call-ID: 5a89b480-2a51c316-d26d-46c13ac@172.19.108.4

Supported: 100rel,timer,resource-priority,replaces

Min-SE:  1800

User-Agent: Cisco-CUCM9.1

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK,

UPDATE, REFER, SUBSCRIBE, NOTIFY

CSeq: 101 INVITE

Expires: 180

Allow-Events: presence

Supported: X-cisco-srtp-fallback,X-cisco-original-called

Cisco-Guid: 1518974080-0000065536-0000007448-0074191788

Session-Expires:  1800

P-Asserted-Identity: "London Verizon SIP" <sip:02036XXXXXX@172.19.108.4>

Remote-Party-ID: "London Verizon SIP" <sip:02036XXXXXX@172.19.108.4>;party=calling;screen=yes;privacy=off

Contact: <sip:02036XXXXXX@172.19.108.4:5060;transport=tcp>

Max-Forwards: 70

Content-Type: application/sdp

Content-Length: 311

v=0

o=CiscoSystemsCCM-SIP 219815 1 IN IP4 172.19.108.4

s=SIP Call

c=IN IP4 172.16.65.99

b=TIAS:64000

b=AS:64

t=0 0

m=audio 31030 RTP/AVP 0 8 18 101

a=rtpmap:0 PCMU/8000

a=ptime:20

a=rtpmap:8 PCMA/8000

a=ptime:20

a=rtpmap:18 G729/8000

a=ptime:20

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

=======================================

Inbound Dial Peer on the London Cube has a Voice Class Codec of G729r8 as the acceptable Codec. 

BST: //-1/5A89B4800000/DPM/dpAssociateIncomingPeerCore:

Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=201

voice class codec 21

codec preference 1 g729r8

dial-peer voice 201 voip

description INBOUND from CUCM to CUBE (ultimately external)for numbers start

incoming called-number 9T

voice-class codec 21

voice-class sip bind media source-interface Loopback0

dtmf-relay rtp-nte

====================================================

London CUBE sends a  SIP/2.0 488 Not Acceptable Media    

Sent:

SIP/2.0 488 Not Acceptable Media

Via: SIP/2.0/TCP 172.19.108.4:5060;branch=z9hG4bK18b35581cd0db

From: "London Verizon SIP" <sip:02036XXXXXX@172.19.108.4>;tag=219815~91e77be1-0818-449d-af4c-9b6a8d63e011-39811112

To: <sip:9001434XXX6149@192.168.23.1>;tag=96354F4-5E3

Date: Mon, 09 Dec 2013 13:18:14 GMT

Call-ID: 5a89b480-2a51c316-d26d-46c13ac@172.19.108.4

CSeq: 101 INVITE

Allow-Events: telephone-event

Warning: 304 192.168.23.1 "Media Type(s) Unavailable"

Reason: Q.850;cause=65

Server: Cisco-SIPGateway/IOS-12.x

Content-Length: 0

[Ayodeji Okanlawon]

Kenneth,

I have never deployed a solution like this..I have alwayas ensured that on my inbound leg, the codecs advertised matches on both ends...It looks as if even though this should work, CUBE is detecting that the offfered codecs do not match on the inbound leg bcause some of the codecs are missing...To confirm this lets do the ff

1. Remove g729 from the codec list and eplac with g711u or g711a and confirm that you still get media not accepted

2. remove voice class codec and hard code one of the codecs and test again..

If my assumptions are right, you should get the same issue. If this is the case then you will need to have a voice  class codec with all the codecs in the list that is offered by CUCM. You can choose what codec you use for this call on the outbound leg. Eg you can configure the outbound leg to use G729 and that wouldnt be a problem..

Let me know your findings

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[kenneth.meyers]

I removed the codec list and replaced with a list allowing only G711ulaw / G711alaw and still received the "Media Not Acceptable" message.

Hardcoding the codec's to either G729 or G711 had the same "Media Not Acceptable" result.

Only having the inbound dial-peer have all 3 codec's in the codec list created a working solution. 

Initially my thinking was to accept it G729 as opposed to G711 so when the call leg to the ITSP selects G729 the CUBE wouldn't look to allocate a X-Coder (if it accepted it via the inbound call leg as G711) and it would be G729 all the way through. That thinking won't work and only having all codec's listed will allow the inbound call leg to complete.

Thanks for your help!

Ken

[Ayodeji Okanlawon]

Ken,

Glad to be of help, I knew that is what the issue will be. In this scenario there is no need to worry about CUBE invoking a xcoder because the inbound leg has multiple codecs in it, whatever outbound leg is set to will be fine as long as the codec is offered in the inbound leg..

You can refer to this document  I wrote on codec selection over sip trunks and dont forget to rate any useful posts

https://supportforums.cisco.com/docs/DOC-26098

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

[Jagpreet.Singh]

Hi Kenneth,

     Adding to what has already been said, just to cover all bases, you have checked the outbound leg as well from the CUBE to the provider? That does not get invoked at all ?

Regards,

Jagpreet

[Nishant Savalia]

Hi Kenneth,

As your problem is already solved and if it's possible then can you please check with your old configuration again in addition to add your "Voice-class codec 1 (G729r8 only)" on outgoing and incoming dial peer as well.

Regards,

Nishant Savalia