Intermittent issue where UCCX IVR won't take option 2 input - bug?

[2020]

So we have an intermittent issue that it really hard to pinpoint what is the cause.   I have 2 IVR scripts that when someone calls in and presses option 2 - it doesn't take it - you just hear a beep while you press the button and the script continues to play - then give the "Are you still there?" before repeating the script.   Both scripts have "Barge in" enabled and interruptible enabled on the Menu.   This issue may be happening on others but only 2 have been reported and both are on option 2,   it happens on internal and external calls that go to the IVR, and is so intermittent/randomly that I am not sure what to be looking for or get a good set of logging to send to TAC.     Has anyone else had an issue like this?  It is like not recognizing the DTMF tone.     What logs should I enable for it?  Or is there a way to see DTMF failures? 

[Anthony Holloway]

First, DTMF issues are not uncommon, and for this reason, I always advise to program in a default route in your scripts.  Do you already do that?

Second, DTMF issues are almost always a result of a CUCM issue, and not UCCX.  You see, UCCX can only send and receive DTMF via CTI over it's connection to CUCM, and that's pretty static.  What isn't static, are the various ways in which calls arrive to CUCM, from different PSTN gateways, IP Phones, analog gateways, MTPs and XCODERs.  Even within the category of PSTN Gateways, if it's SIP, you could have a mix of DTMF features coming in.  It's CUCM's job to broker the connection between these two, and sometimes it can't.

As far as proving whether or not UCCX is receiving the digits or not, you'd need to be able to either recreate the failure scenario, or get the exact call details of someone who had the problem, and then you can use my method described here to check for DTMF being received or not from CUCM to UCCX.  If you see it in these logs, then it was sent to UCCX and then the problem is with UCCX and likely a software defect, and not likely configuration.  Unless you're running out of Cisco Media Channels (you should have 10% more than you have CTI Ports).

As far as proving that the caller's device (E.g., IP Phone or PSTN gateway) sent you DTMF, you'd first need to figure out how the DTMF is being sent, because it will either go via the audio tones (MTP/XCODE), go via RTP with payload type of 101 to a media resource (MTP/XCODE), or go via signaling protocol (SIP, SCCP, MGCP) to CUCM.  Once you know that, then you know where to look to see the digits flowing from one end to the other.  For this task, you'll want to pull CUCM CallManager traces from RTMT and then look at them in TranslatorX. 

[UrbanPeasant]

Do you have an option 1? Does that work? I bet it's not a DTMF failure.

I had something very similar to this a couple of weeks back. Turned out to be my ITSP gateway negotiating with my CUBE and settling on fax for the call, when it wasn't a fax call. I had to change my voice service to stop the ITSP forcing us down a fax route when it was no such thing.

Their gateway forwarded a re-INVITE with SDP with “a=silenceSupp:off - - - -“ header, meaning they wanted fax.
Our voice service was configured with fallback to pass-through with the same codec as in the incoming mid-call INVITE (G.711alaw), so the CUBE treated the mid-call INVITE as a fax INVITE, meaning that while providing an answer, no DTMF details will be sent. So our response (200 OK), does not contain the RTP-NTE parameter as part of the SDP.

fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none (previously fallback g711alaw)

You'll end up seeing this in debug ccsip messages, but it's a keen eye that going to find it. Our support partner (CCIEs) had to back the problem off to TAC. No discredit to our partner, this is properly in-the-weeds stuff. 

Might help you, might not. 

Best

Nathan.

[2020]

Sorry for the delay,  that is really interesting and must've been a pain to pin down.  Was it intermittent for you or more of a constant?  I have reached out to my end users about this and asked them about option 1 - unfortunately they are slow to respond.   Now when troubleshooting, was there a way of it trying to force the issue?  Did you make an IVR for testing?  We currently have our gateways being managed by a third party so I want try to have something to really get some logs.  Now that you do see the debug ccsip, is there another log that we could see that could be a sign that is the issue?