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 220.127.116.1100-28, UCCX 18.104.22.16800-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:
SUBSCRIBE sip:firstname.lastname@example.org:5060 SIP/2.0
CSeq: 103 SUBSCRIBE
Date: Sat, 07 Jun 2014 19:35:37 GMT
<?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:
SUBSCRIBE sip:email@example.com:5060 SIP/2.0
CSeq: 101 SUBSCRIBE
Date: Sat, 07 Jun 2014 19:35:37 GMT
<?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">
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?
could you please explain, why the redirect? Would it be possible to handle this using a subscript (via the Trigger Application mechanism)?
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.
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.
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 .
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.
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 .
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.
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.