cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2680
Views
0
Helpful
7
Replies

CMS Failing to Negotiate g.711alaw

Jason Neurohr
Level 1
Level 1

Hi All,

We have a CMS running 2.2.8 receiving an inbound INVITE from an SBC (below EXHIBIT A) advertising g.711alaw, which the CMS supports. However, the OK response from CMS is omitting the g.711alaw and causing the call to be torn down (EXHIBIT B). Has anyone else encountered this?

 

EXHIBIT A:

TCP SIP Message from sbc:21194 to cms:5060


INVITE sip:aaaaaaaa@cms:5060;user=phone;transport=tcp SIP/2.0
Via: SIP/2.0/TCP sbc:5060;branch=z9hG4bKhb3o173070anj2eobs00.1
From: <sip:bbbb@sbc;user=phone>;tag=92702
To: "aaaaaaaa"<sip:aaaaaaaa@cms:5060;user=phone>
Call-ID: 0ecbfc80f57a4da7c33a6c68c4e0bab763ea713@1.1.1.1
CSeq: 34909 INVITE
Content-Type: application/sdp
Contact: <sip:bbbb@sbc:5060;user=phone;transport=tcp>
User-Agent: Nortel SESM 18.0.28.1
Max-Forwards: 49
Supported: com.nortelnetworks.firewall,p-3rdpartycontrol,nosec,join,x-nortel-sipvc,gin,replaces,tdialog
P-Asserted-Identity: <sip:bbbb@sbc;user=phone>
Allow: INVITE,BYE,CANCEL,ACK,REGISTER,SUBSCRIBE,NOTIFY,MESSAGE,INFO,REFER,OPTIONS,PUBLISH,PRACK
x-nt-corr-id: 6b9ea0b6-2b88-1b21-b7ca-00e0ed67007e
x-nt-location: -1
P-Charging-Vector: icid-value=6b9ea0b6-2b88-1b21-b7ca-00e0ed67007e;icid-generated-at=1.1.1.1
Content-Length: 232

v=0
o=SST 1883706522 1883706522 IN IP4 sbc
s=-
e=unknown@invalid.net
t=0 0
m=audio 17170 RTP/AVP 8 101
c=IN IP4 sbc
b=AS:80
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=3gOoBTC
a=ptime:20

 

EXHIBIT B:

TCP SIP Message from cms:5060 to sbc:21194

SIP/2.0 200 OK
Via: SIP/2.0/TCP sbc:5060;branch=z9hG4bKhb3o173070anj2eobs00.1
Call-ID: 0ecbfc80f57a4da7c33a6c68c4e0bab763ea713@1.1.1.1
CSeq: 34909 INVITE
Max-Forwards: 70
Server: Acano CallBridge
Contact: <sip:cms;transport=tcp>;isFocus
To: <sip:aaaaaaaa@cms:5060;user=phone>;tag=9d50551cf96d2340
From: <sip:bbbb@sbc;user=phone>;tag=92702
Allow: INVITE,ACK,CANCEL,OPTIONS,INFO,BYE,UPDATE,REFER,SUBSCRIBE,NOTIFY,MESSAGE
Supported: timer,X-cisco-callinfo
Session-Expires: 1800;refresher=uas
Min-SE: 90
Content-Type: application/sdp
Content-Length: 175

v=0
o=Acano 0 0 IN IP4 cms
s=-
c=IN IP4 cms
b=CT:2000
t=0 0
m=audio 55574 RTP/AVP 101
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

7 Replies 7

Zoltan Kelemen
Cisco Employee
Cisco Employee

is there anything in the logs prior to the OK which may hint at why the codec is dropped?

Hey Zoltan, thanks for the reply. No, no hints as to why it's happening. Without SIP Tracing, these are all the logs CMS provides.

 

Oct 12 07:18:35 user.info CMS01 host:server:  INFO : call 170: recognised as Nortel SIP GW
Oct 12 07:18:35 user.info CMS01 host:server:  INFO : call 170: incoming SIP call from "sip:caller@sbc;user=phone" to local URI "sip:ivr@cms:5060;user=phone;transport=tcp"
Oct 12 07:18:35 user.info CMS01 host:server:  INFO : call 170: setting up UDT RTP session for DTLS (combined media and control)
Oct 12 07:18:35 user.info CMS01 host:server:  INFO : call 170: ending; remote SIP teardown - connected for 0:00
Oct 12 07:18:35 user.info CMS01 host:server:  INFO : call 171: recognised as Nortel SIP GW
Oct 12 07:18:35 user.info CMS01 host:server:  INFO : call 171: incoming SIP call from "sip:caller@sbc;user=phone" to local URI "sip:ivr@cms:5060;user=phone;transport=tcp"
Oct 12 07:18:35 user.info CMS01 host:server:  INFO : call 171: setting up UDT RTP session for DTLS (combined media and control)
Oct 12 07:18:35 user.info CMS01 host:server:  INFO : call 171: ending; remote SIP teardown - connected for 0:00

You can get more detailed logs if you enable debug logging, reproduce the issue, then SFTP into the CMS and download the "log" file (syslog file).  The event logs seen in the web interface don't really provide any detailed information, but the syslog file can provide the entire SIP trace.

Hey Patrick,

Yes, the SIP detailed trace is what I had in the original thread (just the specific messages extracted). The logbundle shows nothing more then the same SIP messages mixed with the the logs from my other reply unfortunately.

As this looks like a bug (and I cannot find any known issue like this) or at very least a lack of feedback from CMS, I would suggest opening a TAC case, so that engineering can be involved to investigate.

collecting full logs + pcap may help better understanding what is going on.

It's definitely a bug; we are working with TAC now.

 

I've done further testing, and the problem is isolated to specifically g.711alaw. If I send g.711ulaw only the call will establish no problem. So the issue seems to be specifically with the g.711alaw implementation on the CMS.

 

I'll update the thread once I know more.

I've identified the cause of the problem now. Pending implementation to production and confirmation from TAC. The Supported header includes an "x-nortel-sipvc' extension, which when removed causes the CMS to send PCMA and PCMU correctly in it's SDP:

 

This causes CMS only to send g711ulaw:
'Supported: com.nortelnetworks.firewall,p-3rdpartycontrol,nosec,join,x-nortel-sipvc,gin,replaces,tdialog\r\n'


Without it, CMS sends both ulaw and alaw:
‘Supported: com.nortelnetworks.firewall,p-3rdpartycontrol,nosec,join,gin,replaces,tdialog\r\n’

 

Jason

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: