Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

No DTMF in UCCX after Call Redirect to another script.

 

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?

 

 

9 REPLIES

Hi,could you please explain,

Hi,

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

G.

New Member

Subscripts are a pain to

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.

Hi,this might sound a little

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.

Cisco Employee

Hi , Can you please try to

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

New Member

I'm not at the customer site,

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.

Cisco Employee

If direct call from internal

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

New Member

Did you ever find a solution

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

TIA

New Member

Not proud of the "solution"

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.

New Member

 Thanks for the response! 

 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.  

551
Views
0
Helpful
9
Replies
CreatePlease login to create content