[cisco-voip] no DTMF to a specific number

[Eric Pedersen]

Hi Chris,

Turning on rel1xx in CUCM gets CUCM to send a PRACK to the SIP 183, but still doesn't fix the dtmf problem.  With or without PRACK enabled, both the Invite and Session Progress have the "Allow-Events: kpml" header. Also, I have early offer configured in CUCM, and RTP is set up after the 100/183 exchange so the gateway in theory should be able to subscribe to kpml at that point.

It's only been one number so far and I have a workaround by having a specific dial-peer to use sip-notify so maybe I'll wait and see if I get more problem reports before opening a TAC case.

Thanks,
Eric

From: Chris Ward (chrward) [mailto:chrward at cisco.com]
Sent: 24 October 2012 7:58 AM
To: Eric Pedersen; cisco-voip at puck.nether.net
Subject: RE: no DTMF to a specific number

According to the bug it could be. But as you said, it's just one number and in production so it's something to test carefully.

+Chris
Unity Connection TME

From: Eric Pedersen [mailto:PedersenE at bennettjones.com]
Sent: Tuesday, October 23, 2012 6:18 PM
To: Chris Ward (chrward); cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: no DTMF to a specific number

We're running 15.1(4)M4. I don't have any configuration for reliable responses though so the gateway doesn't send a PRACK.  Do you think that's the problem? I can try turning on rel1xx in CUCM.

From: Chris Ward (chrward) [mailto:chrward at cisco.com]
Sent: 23 October 2012 3:25 PM
To: Eric Pedersen; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: no DTMF to a specific number

12.5 = 15.X I believe...

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Chris Ward (chrward)
Sent: Tuesday, October 23, 2012 5:23 PM
To: Eric Pedersen; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] no DTMF to a specific number

Did some quick topic searching and found a thread that suggests the fix for CSCsm15480 should enable KPML before connected state.

Looks like "12.4(15)XL04 or 12.4(15)T08" or anything 12.5 and up should have the fix. What IOS are you running on your GW?

+Chris
Unity Connection TME

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Eric Pedersen
Sent: Tuesday, October 23, 2012 4:52 PM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] no DTMF to a specific number

CUCM 8.6 <- SIP-> GW(IOS 15.1)  <- PRI -> PSTN

I'm having a strange DTMF relay problem with a specific destination: when we call this number, their IVR answers but DTMF doesn't work.  I ran an ISDN debug, and I see that their IVR audio starts after we receive an ISDN PROGRESS message without ever receiving an ISDN CONNECT message. At this point the gateway has only sent a SIP 183 Session Progress message to CUCM, not a SIP 200.  I have the gateway configured to use KPML for DTMF relay, but the gateway doesn't subscribe to kpml until after sending SIP 200.

I set up a specific incoming dial-peer for this number with dtmf-relay sip-notify and that works fine, but I'd rather not do a one-off configuration for this, and kpml seems to work fine with every other call.

Has anyone seen anything like this? It seems to me like this is a configuration problem on their end, but it works calling from my cell phone.

FYI, this is what the ISDN message sequence looks like for the problematic call:
715102: Oct 23 13:34:51.065 MDT: ISDN Se0/0/1:23 Q931: Sending SETUP  callref = 0x5559 callID = 0xD360 switch = primary-dms100 interface = User
715103: Oct 23 13:34:51.065 MDT: ISDN Se0/0/1:23 Q931: TX -> SETUP pd = 8  callref = 0x5559
715104: Oct 23 13:34:51.193 MDT: ISDN Se0/0/1:23 Q931: RX <- CALL_PROC pd = 8  callref = 0xD559
715105: Oct 23 13:34:52.541 MDT: ISDN Se0/0/1:23 Q931: RX <- PROGRESS pd = 8  callref = 0xD559
<-- IVR STARTS -->
715133: Oct 23 13:35:26.633 MDT: ISDN Se0/0/1:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x5559
715134: Oct 23 13:35:26.693 MDT: ISDN Se0/0/1:23 Q931: RX <- RELEASE pd = 8  callref = 0xD559
715135: Oct 23 13:35:26.693 MDT: ISDN Se0/0/1:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x5559

A call to a working IVR looks like:
714989: Oct 23 13:33:07.677 MDT: ISDN Se0/0/1:23 Q931: Sending SETUP  callref = 0x554F callID = 0xD356 switch = primary-dms100 interface = User
714990: Oct 23 13:33:07.677 MDT: ISDN Se0/0/1:23 Q931: TX -> SETUP pd = 8  callref = 0x554F
714991: Oct 23 13:33:07.793 MDT: ISDN Se0/0/1:23 Q931: RX <- CALL_PROC pd = 8  callref = 0xD54F
714995: Oct 23 13:33:10.341 MDT: ISDN Se0/0/1:23 Q931: RX <- ALERTING pd = 8  callref = 0xD54F
714996: Oct 23 13:33:10.541 MDT: ISDN Se0/0/1:23 Q931: RX <- CONNECT pd = 8  callref = 0xD54F
714998: Oct 23 13:33:10.541 MDT: ISDN Se0/0/1:23 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x554F
<-- IVR STARTS -->
715007: Oct 23 13:33:15.629 MDT: ISDN Se0/0/1:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x554F
715008: Oct 23 13:33:15.689 MDT: ISDN Se0/0/1:23 Q931: RX <- RELEASE pd = 8  callref = 0xD54F
715009: Oct 23 13:33:15.693 MDT: ISDN Se0/0/1:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x554F

Regards,
Eric

The contents of this message may contain confidential and/or privileged

subject matter. If this message has been received in error, please contact

the sender and delete all copies. Like other forms of communication,

e-mail communications may be vulnerable to interception by unauthorized

parties. If you do not wish us to communicate with you by e-mail, please

notify us at your earliest convenience. In the absence of such

notification, your consent is assumed. Should you choose to allow us to

communicate by e-mail, we will not take any additional security measures

(such as encryption) unless specifically requested.



The contents of this message may contain confidential and/or privileged

subject matter. If this message has been received in error, please contact

the sender and delete all copies. Like other forms of communication,

e-mail communications may be vulnerable to interception by unauthorized

parties. If you do not wish us to communicate with you by e-mail, please

notify us at your earliest convenience. In the absence of such

notification, your consent is assumed. Should you choose to allow us to

communicate by e-mail, we will not take any additional security measures

(such as encryption) unless specifically requested.



The contents of this message may contain confidential and/or privileged
subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20121024/3da9e693/attachment.html>