How to verify DTMF method used from CCM SDI Logs?

[tacl75]

Hi guys,

I have a SIP trunk configured in CCM 8.6.1 with another SIP provider network.

The call was successful but DTMF not working at all when provider route to Meet Me conference or some other IVR or Voicemail system which requires DTMF signaling.

I have checked the logs and my setting were to use "No Preference" for DTMF method. I am using Cisco 6941 phone registered to CCM and dial an US number or UK number which will travel through the SIP provider.

I have extracted the SDI logs and trying to understand how do I determine if the phone has used RFC2833 or OOB method.

Any advise will be appreciated.

Thanks,

Tony                  

[Ayodeji Okanlawon]

You need to look at the SDP either in your INVITE if you are using EO or the SDP in the 200 OK ad the ACK to see what dtmf method is negotitated by CUCM and the ITSP trunk...Its most likely its rfc2833...

If your 6941 phone is a SCCP phone then you are going to need an MTP for DTMF because the SCCP phone dont support rfc2833..they do OOB DTMF

Please rate all useful posts

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

[tacl75]

What is EO? Do you have a sample message format or key word that I can do a search?

I have tried with Cisco 8961 SIP phone and the result is the same. Any similar experience?

Thanks,

Tony

[Ayodeji Okanlawon]

Can you attach the CUCM SDI logs. Include the calling and called number and time of call..I will have a look

Please rate all useful posts

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

[tacl75]

I wish I can but the environment which I am working in are highly classifed and confidential. I can only type in if you have specific words needed.

[Ayodeji Okanlawon · Accepted solution]

In that case I suggest you open a TAC case. There is no way to troubleshoot this without looking at the logs. We need to see what DTMF is negotiated and this will be in the sip traces. They will be present in the SDP in both the offer and the asnwer from both ends

Eg...trace below:

Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 273

v=0
o=CiscoSystemsSIP-GW-UserAgent 4869 3087 IN IP4 10.100.70.200
s=SIP Call
c=IN IP4 10.100.70.200
t=0 0
m=audio 22720 RTP/AVP 18 101
c=IN IP4 10.100.70.200
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000---------------------------------------DTMF using payload type 101
a=fmtp:101 0-15-------------------------------------dtmf digits supported (0-15)
a=ptime:20

Please rate all useful posts

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

[tacl75]

v=0

o=CiscoSystemsSIP-GW-UserAgent 4869 3087 IN IP4 10.100.70.200

s=SIP Call

c=IN IP4 10.100.70.200

t=0 0

m=audio 22720 RTP/AVP 18 101

c=IN IP4 10.100.70.200

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15-------------------------------------dtmf digits supported (0-15)

a=ptime:20

v=0
o=CiscoSystemsSIP-GW-UserAgent 4869 3087 IN IP4 10.100.70.200
s=SIP Call
c=IN IP4 10.100.70.200
t=0 0
m=audio 22720 RTP/AVP 18 101
c=IN IP4 10.100.70.200
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000

a=sendrecv

I have located the above message in the 200 ok message sending to provider. Except the below info from your example:

a=fmtp:101 0-15-------------------------------------dtmf digits supported (0-15)
a=ptime:20

Does it mean anything?

[Ayodeji Okanlawon]

What about the SDP from the provider? What is in that mesasge

Please rate all useful posts

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

[tacl75]

Correction:

This is the Invite msg to Provider:

17:55:34.649 |//SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to 163.x.x.x on port 5060 index 11123
[67194208,NET]
INVITE sip:512345678900@163.x.x.x:5060 SIP/2.0
Via: SIP/2.0/TCP 10.x.x.x:5060;branch=z9hG4bK4b46656442af96
From: "SME TEST PHONE" <>;tag=33062097~0c91b225-fc14-4e60-bc42-78a5f37bcae2-77536268
To: <512345678900>
Date: Wed, 08 May 2013 09:55:34 GMT
Call-ID: 6bccb480-18a12116-4b4660-8dfe5c0a@10.x.x.x
Supported: timer,resource-priority,replaces
Min-SE:  1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Call-Info: <10.X.X.X:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 1808577664-0000065536-0000000008-2382257162
Session-Expires:  1800
P-Asserted-Identity: "SME TEST PHONE" <>
Remote-Party-ID: "SME TEST PHONE" <>;party=calling;screen=yes;privacy=off
Contact: <>
Max-Forwards: 68
Content-Length: 0

|4,100,63,1.33074112^10.x.x.x^*

Then an Incoming SIP message received from provider

17:55:35.232 |//SIP/SIPTcp/wait_SdlReadRsp: SdlRead bufferLen=720|4,100,63,1.33074114^163.x.x.x^*
17:55:35.232 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from 163.x.x.x on port 5060 index 11123 with 720 bytes:
[67194212,NET]
SIP/2.0 200 OK
From: "SME TEST PHONE" <>;tag=33062097~0c91b225-fc14-4e60-bc42-78a5f37bcae2-77536268
To: <512345678900>;tag=50a25a3-13c4-518a2117-128d1374-2ee958b5
Call-ID: 6bccb480-18a12116-4b4660-8dfe5c0a@10.x.x.x
CSeq: 101 INVITE
Via: SIP/2.0/TCP 10.x.x.x:5060;branch=z9hG4bK4b46656442af96
Contact: <512345678900>
Content-Type: application/sdp
Content-Length: 228

v=0
o=- 3240169194 6814052 IN IP4 163.x.x.x
s=-
c=IN IP4 163.x.x.x
t=0 0
m=audio 21130 RTP/AVP 18 101
c=IN IP4 163.x.x.x
a=rtpmap:18 g729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:18 annexb=no
a=sendrecv
|4,100,63,1.33074114^163.x.x.x^*

Anything unusual?

[Ayodeji Okanlawon]

Nothing unusual..but what is the SDP in the ACK sent by CUCM to the provider...??

Please rate all useful posts

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

[tacl75]

ACK sip:512345678900@163.x.x.x:5060;maddr=163.x.x.x;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.x.x.x:5060;branch=z9hG4bK4b46656442af96

From: "SME TEST PHONE" <>;tag=33062097~0c91b225-fc14-4e60-bc42-78a5f37bcae2-77536268

To: <512345678900>;tag=50a25a3-13c4-518a2117-128d1374-2ee958b5

Date: Wed, 08 May 2013 09:55:34 GMT

Call-ID:6bccb480-18a12116-4b4660-8dfe5c0a@10.x.x.x

Max-forwards: 70

CSeq: 101 ACK

Allow-Events: presence, kpml

Content-Type: application/sdp

Content-Length: 186

v=0

o=CiscoSystemCCM-SIP 33062097 IN IP4 10.x.x.x

s=SIP Call

c=IN IP4 163.x.x.x

t=0 0

m=audio 25756 RTP/AVP 18

a=rtpmap:18 g729/8000

a=ptime:20

a=fmtp:18 annexb=no

This was the ACK reply from provider.

I actually scan through the logs and found this:

17:55:35.311 |updateEndpointsDtmfCaps: KPML Supported.|*^*^*

17:55:35.311 |updateEndpointsDtmfCaps: Detected NO inband DTMF support.|*^*^*

This message appears after 200 ok msg and before ACK msg. Does it mean the endpoint does not support RFC2833 ?

[Ayodeji Okanlawon]

There possibly two issues..The ACK from CUCM does not contain any dtmf attribute...and secondly your SCCP phones may support only KPML OOB dtmf..

First of all I suggest you change your sip trunk DTMF to rfc2833...Then test your sip phone and see if DTMF works on it.. For your SCCP phone you will certainly need an MTP to do DTMF conversion..

Please rate all useful posts

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

[tacl75]

I have tried setting the DTMf option to RFC2833 on the SIP trunk and used a Cisco 8961 phone to test. No luck to get it work. From the logs, I did not see the statement saying "KPML Supported" but only the second statement saying:

" Detected NO inband DTMF support ". Any bugs on this version of CCM 8.6.1.21019-1 and 8961 phone running firmware version 9.2.2?

Or how do I make sure that it should be using RFC2833 instead of OOB method?

[Ayodeji Okanlawon]

First question is did you reset the sip trunk after you enabled rfc2833..Second is I cant really help unless I see the logs. You can mask your numbers...You need to know what DTMF method the phones support. CUCM logs will tell us if your phone support rfc2833..this is why we need the logs...You also need to see that both cucm and provider negotiate rfc2833..again I need to see traces to confirm this...

I need CUCM SDI traces..

Please rate all useful posts

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

[tacl75]

I did a reset on the trunk as well as the route list associated with it. I can see that the provider is supporting RFC2833 since from the incoming SIP message, there is a

a=rtpmap:101 telephone-event/8000

, so I think they are fine.

But I do not know why they did not reply with a=fmtp:101 0-15 since you have mentioned that its the dtmf digits supported.

On the other hand, i trying to simulate the call between CCM clusters, and it seems to be the same behaviour though the SIP trunk are set to RFC2833.

My test scenario is:

8961 --> CCM1 --> Cisco SME --> CCM2 --> 8961