No DTMF in UCCX after Call Redirect to another script.

[Ariel Gonzalez]

I have a Main script, where DTMF is working correctly, that then Redirects calls into other script's Route Points. The second script that receives the calls seems to not request DTMF resources and therefore cannot handle DTMF events.

The call flow is as follows: CUBE -> SIP Trunk -> CUCM -> UCCX. Trunk was originally not requiring an MTP, and was configured for RFC2833 DTMF. IOS 15.2(4)M5, CUCM 9.1.2.10000-28, UCCX 9.0.2.10000-71.

While the Main script is handling the call, there is (correctly) an MTP handling DTMF transcoding for the CTI Port. However after the Redirect to the second script, the MTP is released and the stream goes directly into the UCCX server, as observed from the CUBE using show commands. DTMF events then stop being registered by the script.

Enabling KPML in the CUBE, as suggested here (https://supportforums.cisco.com/discussion/11949871/dtmf-not-working-uccx) has pretty much the same result, in that the first script will successfully subscribe to the events, while the second script will not.

This is an example of a successful subscription:

001684: Jun  7 15:35:37.256 AST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SUBSCRIBE sip:1234567@192.168.16.12:5060 SIP/2.0
Call-ID: BC174B4B-EDB111E3-B7DDFB5C-1E9B8804@192.168.16.2
CSeq: 103 SUBSCRIBE
Max-Forwards: 70
Date: Sat, 07 Jun 2014 19:35:37 GMT
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5
Event: kpml
Expires: 7200
Contact: <sip:192.168.16.2:5060>
Content-Type: application/kpml-request+xml
Content-Length: 327

<?xml version="1.0" encoding="UTF-8"?><kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0"><pattern persist="persist"><regex tag="dtmf">[x*#ABCD]</regex></pattern></kpml-request>

001685: Jun  7 15:35:37.256 AST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SUBSCRIBE sip:1234567@192.168.16.2:5060 SIP/2.0
Call-ID: BC174B4B-EDB111E3-B7DDFB5C-1E9B8804@192.168.16.2
CSeq: 101 SUBSCRIBE
Date: Sat, 07 Jun 2014 19:35:37 GMT
User-Agent: Cisco-CUCM9.1
Event: kpml
Expires: 7200
Contact: <sip:192.168.16.12:5060>
Accept: application/kpml-response+xml
Max-Forwards: 70
Content-Type: application/kpml-request+xml
Content-Length: 370

<?xml version="1.0" encoding="UTF-8" ?>
<kpml-request xmlns="urn:ietf:params:xml:ns:kpml-request" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-request kpml-request.xsd" version="1.0">

  <pattern interdigittimer="7260000" persist="persist">
    <regex tag="dtmf">[x*#ABCD]</regex>
  </pattern>

</kpml-request>

This is the DTMF event before the redirect:

<?xml version="1.0" encoding="UTF-8"?><kpml-response version="1.0" code="200" text="OK" digits="1" tag="dtmf"/>

Then this is the response to the SUBSCRIBE after the transfer:

<kpml-response xmlns="urn:ietf:params:xml:ns:kpml-response" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:kpml-response kpml-response.xsd" code="487" digits="" forced_flush="false" suppressed="false" tag="dtmf" text="Subscription Expired" version="1.0"/>

Currently I have it configured to not use KPML and to require an MTP for all calls in the trunk for it to work, however this is not ideal. Anyone knows why this is happening?

[Gergely Szabo]

Hi,

could you please explain, why the redirect? Would it be possible to handle this using a subscript (via the Trigger Application mechanism)?

G.

[Ariel Gonzalez]

Subscripts are a pain to debug. I do use them, for Business Hours and Holiday type scripts. If this problem turns out to be a "feature" not a bug, then I might just be forced to use subscripts all over.

[Gergely Szabo]

Hi,

this might sound a little crazy, but could you try to transfer the call sort of forcing to go through a separate device, sending it off CUCM to perhaps the router hosting the CUBE and sending it back to CUCM immediately?

UCCX uses JTAPI method calls to transfer active calls and they might have left something out, but this is just a wild guess.

G.

[Ravi Shankar Pandit]

Hi ,

Can you please try to call 2nd trigger directly and see if its able to recognize the DTMF . Try dialing internally . Please upload your scripts and MIVR logs .

Regards

Ravi

[Ariel Gonzalez]

I'm not at the customer site, but will get the logs as soon as I can.

Dialing directly into the 2nd trigger will invoke the MTP and DTMF will work. The problem seems to be only after a redirect.

I will also try to create a test case script, since I can't post the original ones here. Will also try Gregerly's test of redirecting the call to another number before sending it to the second trigger in order to "trick" the system. Maybe into a CUC Call Handler or something.

I was mainly wondering if other people had the same problem after redirects, or if it was just a bug in my version or script implementation.

[Ravi Shankar Pandit]

If direct call from internal number is working fine then I dont think there is any issue with UCCX script .

Might be some issue in CUCM .

Regards

Ravi

[roboliveira]

Did you ever find a solution to this problem?  I am running into this same issue.

TIA

[Ariel Gonzalez]

Not proud of the "solution" but I just set it to always use an MTP for all calls coming in through that SIP Trunk.

I have not seen this problem again in other customers, so I don't know if there is something strange in that specific configuration, if it's version related, or anything else.

[roboliveira]

 Thanks for the response! 

I actually did a little testing yesterday and configuring kpml on the dial-peer actually worked for us. We're actually running the same exact version of call manager and contact center defined in the original post.  

[shh5455]

I'm having this issue as well.  I'm not in love with the MTP option as there are a finite amount of resources and I've had trouble with consuming them all in the past.