cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays
2910
Views
5
Helpful
13
Replies
mohsin majeed
Explorer

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

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 2nd 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,

13 REPLIES 13
Deepak Rawat
Cisco Employee

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

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.

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

Please rate all useful posts

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.

Are you on Twitter sir?

Vivek Batra
Engager

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

Thanks for reply

I will try 

Suresh Subramanian
Rising star

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.

//Suresh Please rate all the useful posts.

Hi Suresh,

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

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
Participant

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.

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
Beginner

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

Content for Community-Ad

Spotlight Awards 2021