IVR not accepting DTMF for the SIP DIDs when dialing any call center

[mohsin majeed]

Hi Experts,

I am facing an issue of IVR not accepting digits once dialed through SIP trunk. SIP DID range 28354XX

I tried to troubleshoot with ITSP as below.

First reply from ITSP

These traces are collected by ITSP. Calling number 2835485 in unsuccessful call is one of the company DIDs. The successful call is tested by ITSP from their own DID just to show the difference

Unsuccessful call with payload “ 97 “

Successful Call with payload “ 101 “

INVITE sip:2195851@10.200.0.7:5060 SIP/2.0 Via: SIP/2.0/UDP 10.200.20.235:5060;branch=z9hG4bK99F700T20884 Record-Route: <sip:10.200.20.235:5060;transport=udp;lr> Call-ID: isbc8B87C9DE-8AB111E5-9CEFA4F2-85CD1AE5@10.66.7.126 From: "Belal Jamal"<sip:2835485@10.200.0.7>;tag=sbc0802C2F8FCB0-1A77 To: <sip:2195851@10.200.0.7> CSeq: 101 INVITE Date: Sun, 15 Nov 2015 09:24:45 GMT Supported: timer,resource-priority,replaces,sdp-anat Min-SE: 1800 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE,OPTIONS,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY,INFO,REGISTER Contact: <sip:2835485@10.200.20.235:5060> Call-Info: <sip:10.66.7.126:5060>;method="NOTIFY;Event=telephone-event;Duration=2000" Expires: 180 Allow-Events: kpml,telephone-event Max-Forwards: 69 Session-Expires: 1800 Remote-Party-ID: "Belal Jamal" <sip:2835485@10.66.7.126>;party=calling;screen=yes;privacy=off Cisco-Guid: 3022615040-0000065536-0000137307-0348655788 Content-Length: 241 Content-Type: application/sdp Content-Disposition: session;handling=required v=0 o=- 1290 4729 IN IP4 10.201.20.45 s=SBC call c=IN IP4 10.201.20.45 t=0 0 m=audio 58592 RTP/AVP 8 97 19 c=IN IP4 10.201.20.45 a=rtpmap:8 PCMA/8000 a=rtpmap:97 telephone-event/8000 a=fmtp:97 0-15 a=rtpmap:19 CN/8000 a=ptime:20

INVITE sip:2195851@10.200.0.7:5060 SIP/2.0 Via: SIP/2.0/UDP 10.205.60.134:5060;branch=z9hG4bK+d051124050774f947819bbbcb7a2c12a1+sip+1+aadf37deT01372 Record-Route: <sip:10.205.60.134:5060;transport=udp;lr> Call-ID: isbcaced5ff5a00675fd5d70c90745fd105e@10.250.40.1 From: "ENOC"<sip:4432549@10.200.0.7:5060>;tag=sbc080410.250.40.1+1+20a71046+f8289642 To: <sip:2195851@10.200.0.7:5060> CSeq: 101 INVITE Require: 100rel Expires: 180 Contact: <sip:10.205.60.134:5060> Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY Max-Forwards: 69 Accept: application/sdp,application/dtmf-relay Content-Length: 214 Content-Type: application/sdp v=0 o=- 108894756378322 108894756378322 IN IP4 10.201.20.45 s=SBC call c=IN IP4 10.201.20.45 t=0 0 m=audio 24166 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000

2nd Reply from ITSP

We have done the trace and found that you are now sending Pay load 101, but still not sending "PCMU"

Kindly ask your engineers to send the "PCMU" as the 2^nd priority.

The “PCMU” is G711 u-law, please configure this as the second priority.

Unsuccessful call

INVITE sip:2195851@10.200.0.7:5060 SIP/2.0 Via: SIP/2.0/UDP 10.200.20.235:5060;branch=z9hG4bK9A4EF576T33092 Record-Route: <sip:10.200.20.235:5060;transport=udp;lr> Call-ID: isbc738376D4-8AC511E5-B2E7A4F2-85CD1AE5@10.66.7.126 From: "Belal Jamal"<sip:2835485@10.200.0.7>;tag=sbc0807C37B70FC-1218 To: <sip:2195851@10.200.0.7> CSeq: 101 INVITE Date: Sun, 15 Nov 2015 11:47:15 GMT Supported: timer,resource-priority,replaces,sdp-anat Min-SE: 1800 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE,OPTIONS,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY,INFO,REGISTER Contact: <sip:2835485@10.200.20.235:5060> Call-Info: <sip:10.66.7.126:5060>;method="NOTIFY;Event=telephone-event;Duration=2000" Expires: 180 Allow-Events: kpml,telephone-event Max-Forwards: 69 Session-Expires: 1800 Remote-Party-ID: "Belal Jamal" <sip:2835485@10.66.7.126>;party=calling;screen=yes;privacy=off Cisco-Guid: 2623269120-0000065536-0000137941-0348655788 Content-Length: 244 Content-Type: application/sdp Content-Disposition: session;handling=required v=0 o=- 6546 3826 IN IP4 10.201.20.45 s=SBC call c=IN IP4 10.201.20.45 t=0 0 m=audio 55888 RTP/AVP 8 101 19 c=IN IP4 10.201.20.45 a=rtpmap:8 PCMA/8000 à Also configure PCMU as 2nd priority codec. a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:19 CN/8000 a=ptime:20

We configured the codec class with PCMU as priority 2nd under the dial-peer facing the ITSP. Below is the result for ITSP traces and reply.

3rd Reply from ITSP

Kindly note the analysis that is provided below, Remove the last line in the INVITE Message “a=rtpmap:19 CN/8000”.

Also make it “DYNAMIC DTMF”, in order to accept all payload.

Unsuccessful call

INVITE sip:2195851@10.200.0.7:5060 SIP/2.0 Via: SIP/2.0/UDP 10.200.20.235:5060;branch=z9hG4bK9AE8022F0T14507 Record-Route: <sip:10.200.20.235:5060;transport=udp;lr> Call-ID: isbc1ED6FC67-8B8A11E5-A52CA4F2-85CD1AE5@10.66.7.126 From: "Belal Jamal"<sip:2835485@10.200.0.7>;tag=sbc0802C8844DB4-1100 To: <sip:2195851@10.200.0.7> CSeq: 101 INVITE Date: Mon, 16 Nov 2015 11:15:04 GMT Supported: timer,resource-priority,replaces,sdp-anat Min-SE: 1800 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE,OPTIONS,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY,INFO,REGISTER Contact: <sip:2835485@10.200.20.235:5060> Call-Info: <sip:10.66.7.126:5060>;method="NOTIFY;Event=telephone-event;Duration=2000" Expires: 180 Allow-Events: kpml,telephone-event Max-Forwards: 69 Session-Expires: 1800 Remote-Party-ID: "Belal Jamal" <sip:2835485@10.66.7.126>;party=calling;screen=yes;privacy=off Cisco-Guid: 1204711808-0000065536-0000138838-0348655788 Content-Length: 255 Content-Type: application/sdp Content-Disposition: session;handling=required v=0 o=- 2137 631 IN IP4 10.201.20.45 s=SBC call c=IN IP4 10.201.20.45 t=0 0 m=audio 14544 RTP/AVP 8 0 101 19 c=IN IP4 10.201.20.45 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:19 CN/8000 == REMOVE THIS LINE

Now i would like to know how to remove this line or is it conceptually right.

Please find attached "sh run"

I am only troubleshooting 28354XX where we have other SIP ranges also please forget them.

Waiting for valuable comment.

Regards,

[Deepak Rawat]

Since CCX does not support inband RFC2833 DTMF method, can you check what DTMF had been set on inbound/outbound dial-peers to/from CUCM for the IVR setup. Try using an OOB DTMF mechanism such as dtmf-relay sip-notify

Also try to make an internal call directly to the IVR route point and see if the DTMF is working there or not to isolate if the issue is happening only for calls coming over a SIP trunk or for internal calls as well.

Regards

Deepak

[mohsin majeed]

Thanks deepak,

This issue is little misunderstood that i don't have issue with my CCX. The case is once i dial from my cisco phone to any other service or toll free number to any other company the digits are not accepted after IVR.

[Ayodeji Okanlawon]

There a few concerns here. The obvious one is why your ITSP is asking you to remove CN (confort noise). How does this affect DTMF.

The second one is why your cisco IOS gateway is including CN along with codecs that already have CN built into them i.e G711a/u. These already have CN built into them

The third is we do not know your full call flow and your problem may well not be related to what your ITSP is saying..

Finally here is the sip profile you need to remove that line..

You need to apply it to the outbound  dial-peer facing your ITSP.

voice class sip-profiles 1
response 200 sdp-header Attribute remove "rtpmap:19 CN/8000"

dial-peer voice 10 voip

voice-class sip profiles 1

[mohsin majeed]

Hi Ayodeji,

Thanks for your brief reply

About your first two concerns i have not much idea. But, i will confirm also from ITSP.

Call flow : SCCP/SIP (phone) --> CM --siptrunk--> UBE --> ITSP (28354XX). It seems to me also ITSP is playing around. Let see

Finally i will apply attribute remove config and will update.

[CoolCalmCollectedCapeCoralian]

Are you on Twitter sir?

[Vivek Batra]

If your ITSP saying CN payload type is a issue, it could be because PT 19 has been obsoluted before long time and 13 is in use. However it should have impact on call setup instead only on DTMF. If removing CN header completely from SDP resolves your issue, good. Else you can try changing the CN payload type from 19 to 13 (using rtp payload-type command) under outbound dial peer facing to ITSP and see if it makes any difference.

- Vivek

[mohsin majeed]

Thanks for reply

I will try 

[Suresh Subramanian]

Please crosscheck which inbound & outbound dial-peers the call is matching when you dial into the IVR and add 'no vad' in those dial-peers to remove CN from SDP.

[mohsin majeed]

Hi Suresh,

"no vad" is already under the dial peer config. You can see attached 

[Vivek Batra]

Call might be hitting incorrect dial peer. You should cross verify. As Suresh has suggested nicely an alternative option, 'no vad' should ommit the CN palyload line from SDP body.

- Vivek

[rossporubski]

We had a similar issue a few months back, it turned out we didn't have enough memory resources allocated in the MRG to support the total number of simulataneous calls into our call center. We'd be fine until heavy call volume hours of 10am to 11:30am and 1:30pm to 2:30pm. Once volume spiked DTMF functionality stopped.

Once we added two additional routers with enough RAM to support 400 simultaneous connections the DTMF issue was resolved.

[CoolCalmCollectedCapeCoralian]

With all respect to the commentors of this issue, it could be the routing handling the call, or it could have something to do with the "timing or code."

Can you send out the call over different routes (different providers) and get the same or different result?

If you can send out some routes without issue, it could be that a routing provider handling the communications is using older Sonus equipment.

Regardless if the communication is inband or out of band, when looking at the PCAP, if the RTP event is not seen, but the pressing of the button can be heard by the caller (in your ear lol,) it could be older restrictive equipment that does not recognise the DTMF event, resulting in no response from the IVR.

Please let me know if this helps.

Respectfully,

Charles

[avinsrid89]

Hi Mohsin,

Your ISP is wrong here.

The fact that you are sending a=fmtp:101 0-15 is enough for the DTMF to work with RTP Payload 101.

The codec payload and stuff are not even relevant here.

During your active call, execute "debug voip rtp session named-event" . If you see your digits being sent in this debug, then you are sending the DTMF tones to ISP and it is their work to fix it.

~Avinash