SIP/2.0 488 Not Acceptable Media on Cisco router

[Tomas Mazur]

Hello,

Could someone explain how can I go about matching codecs or transcoding SIP calls between Deutsche Telekom and our endpoints.

We are in the process of migrating from ISDN to SIP trunk provided by Dutsche Telekom (DT). I am currently facing issue with external calls not connecting due to codec mismatch.

Basic topology is this:

DT <SIP trunk> CUBE on Cisco 2901 < SIP trunk> CUCM 9.1 <-> Cisco 7942 phones or Jabber

Codecs offered by DT are 1) G.711alaw and 2) g722-64.

Codec used on SIP trunk between CUCM and CUBE is G.711ulaw. 

This is the config I have so far for dial-peers and codecs

voice-card 0
 dspfarm  
 dsp services dspfarm

voice class codec 1
 codec preference 1 g711alaw
 codec preference 2 g722-64

dspfarm profile 1 transcode universal  
 codec g729abr8
 codec g729ar8
 codec g711alaw
 codec g711ulaw
 codec g729r8
 codec g722-64
 maximum sessions 6
 associate application CUBE

dial-peer voice 3000 voip
 description <<Incoming from Deutsche Telekom>>
 session protocol sipv2
 incoming called e164-pattern-map 3000
 voice-class codec 1  
 voice-class sip early-offer forced
 voice-class sip bind control source-interface ATM0/1/0.7
 voice-class sip bind media source-interface ATM0/1/0.7
 dtmf-relay rtp-nte sip-notify
 no vad

dial-peer voice 3010 voip
 description <<From CUBE to Deutsche Telekom>>
 session protocol sipv2
 session transport tcp
 destination e164-pattern-map 3010
 voice-class codec 1  
 voice-class sip outbound-proxy dns:reg.sip-trunk.telekom.de  
 voice-class sip bind control source-interface ATM0/1/0.7
 voice-class sip bind media source-interface ATM0/1/0.7
 dtmf-relay rtp-nte
 ip qos dscp cs6 signaling
 clid strip name
 no vad
!
dial-peer voice 2000 voip
 description <<Incoming from CUCM to CUBE>>
 session protocol sipv2
 incoming uri via 2000
 voice-class sip bind control source-interface GigabitEthernet0/0
 voice-class sip bind media source-interface GigabitEthernet0/0
 dtmf-relay rtp-nte sip-notify
 codec g711ulaw
 no vad
!
!
dial-peer voice 2010 voip
 description <<From CUBE to CUCM>>
 session protocol sipv2
 session transport tcp
 session server-group 1
 destination e164-pattern-map 2010
 voice-class sip bind control source-interface GigabitEthernet0/0
 voice-class sip bind media source-interface GigabitEthernet0/0
 dtmf-relay rtp-nte
 codec g711ulaw
 no vad
!

Transcoder appears to be registered:

#show dspfarm profile 
Dspfarm Profile Configuration

 Profile ID = 1, Service =Universal TRANSCODING, Resource ID = 1   
 Profile Service Mode : Non Secure 
 Profile Admin State : UP 
 Profile Operation State : ACTIVE 
 Application : CUBE   Status : ASSOCIATED 
 Resource Provider : FLEX_DSPRM   Status : UP 
 Total Number of Resources Configured : 6 
 Total Number of Resources Available : 6 
 Total Number of Resources Out of Service : 0 
 Total Number of Resources Active : 0
 Codec Configuration: num_of_codecs:6 
 Codec : g722-64, Maximum Packetization Period : 30 
 Codec : g729r8, Maximum Packetization Period : 60 
 Codec : g711ulaw, Maximum Packetization Period : 30 
 Codec : g711alaw, Maximum Packetization Period : 30 
 Codec : g729ar8, Maximum Packetization Period : 60 
 Codec : g729abr8, Maximum Packetization Period : 60

When making external calls to the router I keep getting these SIP messages:

Invite

195101: .Jun 21 17:48:37.663: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received: 
INVITE sip:+49896161350@217.86.242.157:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 217.0.15.67:5060;branch=z9hG4bK366fcc655e8cc5082f9bc0d550b43293.b142a213
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>
Max-Forwards: 58
To: +498961613515 <sip:+498961613515@telekom.de;transport=udp;user=phone>
From: <sip:+447812344567@sip-trunk.telekom.de;transport=udp;user=phone>;tag=b0fc111f
Call-ID: 319f1a3b6d0b94e4@62.156.103.70
Contact: <sip:WRp/ESjOusBGBNYFgfgmFAnbj/0a+sQrAyTP17gbWvLBqzeW6wiU7y2UMx7MDvII@th1>
Supported: 100rel,199,histinfo,timer
Session-Expires: 1800;refresher=uac
CSeq: 12084580 INVITE
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REGISTER, UPDATE
Min-SE: 900
P-Asserted-Identity: <sip:+447885539326@sip-trunk.telekom.de;user=phone>
P-Called-Party-ID: <sip:+498951513515@sip-trunk.telekom.de;user=phone>
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 432
v=0
o=- 1172086142 1172086143 IN IP4 217.0.15.67
s=on transit
c=IN IP4 217.0.132.9
t=0 0
m=audio 13536 RTP/AVP 8 101 0 108 102 18 4 109
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:108 AMR/8000
a=fmtp:108 mode-change-neighbor=1;mode-change-period=2;mode-change-capability=2
a=rtpmap:102 AMR/8000
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:109 G726-16/8000
a=ptime:20

To which router replies with:

195102: .Jun 21 17:48:37.671: //6541/4011C65094C1/SIP/Msg/ccsipDisplayMsg:
Sent: 
SIP/2.0 488 Not Acceptable Media
Via: SIP/2.0/TCP 217.0.15.67:5060;branch=z9hG4bK366fcc655e8cc5082f9bc0d550b43293.b142a213
From: <sip:+447123456789@sip-trunk.telekom.de;transport=udp;user=phone>;tag=b0fc111f
To: +498961613515 <sip:+498961613515@telekom.de;transport=udp;user=phone>;tag=B9E0678-2399
Date: Fri, 21 Jun 2019 16:48:37 GMT
Call-ID: 319f1a3b6d0b94e4@62.156.103.70
CSeq: 12084580 INVITE
Allow-Events: telephone-event
Reason: Q.850;cause=65
Server: Cisco-SIPGateway/IOS-15.7.3.M4b
Session-ID: 19d007e73ede5f588f709999fb11c32d;remote=d1a3d045f65950738b30736054c52285
Content-Length: 0

I am attaching SIP debug from the router for those interested.

Thanks for any suggestions

Tom

[Maren Mahoney]

A couple of questions:

First, is the CUBE attempting to signal to CUCM and then sending the 488 response back to the ITSP? Or is the 488 response the first action the router takes after receiving the INVITE?

Second, you say the DT is offering G77alaw and G722, but I don't see G722 in the rtpmap in the INVITE. (And if I'm correct, removing G722 from the voice class codec 1 might fix the problem.)

Third, (because I'm curious), what is causing you to use g711ulaw on the CUCM side?

Maren

[Tomas Mazur]

Hi Maren,

To answer your questions:

1) Based on the ccsip debug it appears the call never makes it to the CUCM. I have also checked on CUCM via real time session trace and there are no incoming calls. I am attaching picture of debug from translator-X FYI.

2) I used codecs based on this document by Cisco - Connecting CUCM 11.5.1 to DT All IP SIP trunks PDF

It was surprising to see all of those being advertised in the IVITE message - not entirely sure why that is as Deutsche Telekom's and Cisco docs both state that only two codecs are supported. I followed your suggestion and removed G722 from the voice codec class. Still getting the 488 response though. - Should I try G722 across the entire call path instead?

3) This was not a design decision - I simply followed the guide I listed above and left it at defaults.

Another test I have run just now was:

On CUCM:

• tick Media Termination Point Required
• Select 711alaw in MTP Preferred Originating CodecRequired Field

On CUBE:

•  update both CUCM dial peers to only use codec 711alaw

I then made few calls and all go the same - there is silence for few seconds and call disconnects without any dial tone or message.

Supported codecs: G722 + G711a-Law

The negotiation of other codecs between two IP-PBXs is not prevented. Over network boundaries, codecs beyond the default codec G.711 may not be usable.

Any other ideas?

Thanks Tom

[Tomas Mazur]

Hi Maren,

To answer your questions:

1) Based on the ccsip debug it appears the call never makes to the CUCM. I have also checked on CUCM via real time session trace and there are no incoming calls. I am attaching picture of debug from translator-X FYI.

2) I used codecs based on this document by Cisco - Connecting CUCM 11.5.1 to DT All IP SIP Trunks via CUBE 11.5.2
It was surprising to see all of those being advertised in the IVITE message - not entirely sure why that is as Deutsche Telekom's and Cisco docs both state that only two codecs are supported.

I followed your suggestion and removed G722 from the voice codec class. Still getting the 488 response though. Should I try using G722 across all call paths?

3) This was not a design decision - I simply followed the guide I listed above and left it at defaults.

Another test I have run just now was:

On CUCM:
  * tick Media Termination Point Required
  * Select 711alaw in MTP Preferred Originating CodecRequired Field

On CUBE:
 * update both CUCM dial peers to only use codec 711alaw

I then made few calls and all go the same - there is silence for few seconds and call drops.

This is excerpt from DT's technical doc (in German):
Supported codecs:
G722 + G711a-Law

The negotiation of other codecs between two IP-PBXs is not prevented.
Over network boundaries, codecs beyond the default codec G.711 may not be usable.

Any other ideas??

Thanks
Tom

[Maren Mahoney]

Ok, so we know that the CUBE itself has the issue rather than a disagreement between the CUBE and CUCM.

I'm less worried about the G722 on the telco side than I am about the mis-matched alaw-ulaw on the CUBE. I was hoping that removing the G722 on the telco side would allow the CUBEs transcoder to fix the problem, but obviously it didn't.

My next suggestion would be to force g711alaw on both the DK-facing dial peers and the CUCM-facing dial peers. And, in CUCM set up a custom codec selection list that favors a-law over u-law and apply it to the region connecting the phones with the trunk. With everything using a-law only (and you want to get rid of the tick on the MTP Required if you have CUCM 9 or later - that is no longer a recommended practice) we will know if the problem is codec selection or something else.

Maren

[Tomas Mazur]

Hello Maren,

I have followed all of your suggestions however calls are still dropped with the same 488 error message.

Any other suggestions? 

Thanks

Tom

[Dennis Mink]

Make sure you force the inbound dialpeer on cube to use g711 only. So the external inbound call gets forced on g711. The the outbound dialpeer to cucm forced to g711 too.

[TONY SMITH]

Are you sure the incoming call from the ITSP is matching the correct dial peer?