02-07-2017 01:45 AM - edited 03-19-2019 12:05 PM
Hello all
Our current setup allowas calls to hit our CUCM on an incoming DDI. This is then passed into the UCCX to access a multi option IVR. If the call comes in direct then all options are selectable from the IVR menus and sub menus.
However, there is an option to transfer to the operator on "Opt 0". If the call is answered by the operator and the user wishes to speak to a certain team within the IVR, they are transferred back into the UCCX via the IVR once again. All options are presented from the menu, but when you try and select the correct option the IVR ignores the input (i.e option 1 through 6).
If an option is selected followed by the hash / pound # key, the call selects to the chosen option.?
Anyone?
Thanks in advance
02-07-2017 05:06 PM
What type of PSTN circuit, voice gateway model/version, protocol between the gateway and CUCM are in use? What DTMF relay option(s) are configured to the carrier (if not PRI/analog) as well as between the gateway and CUCM?
Whem reviewing traces, how does the attendant console handle to transfer? How does it step out of the call and what is the media path after doing so, if RFC2833?
02-08-2017 03:16 AM
Hi Jonathan
Thanks for the reply
Just to clarify: The circuit was cutover from ISDN to SIP and we are now using two SIP trunks connecting into a third party's SBC devices into the new SIP provider. The original gateways were H323 but are no longer used.
When connected via the ISDN we had no issues. Since the move to SIP we have had to make changes to the call control group in the UCCX and reset all the CTI ports as initially we had no MOH stream when calling into the main RP externally and entering the IVR script. However, the MOH streamed when calling the RP internally.
This issue is now resolved so just a bit of background
So current situation:
External callers can select all options within the IVR and get through to the correct teams.
If the caller does not select an option and chooses to select "0" and go back to the operator it comes out of the IVR and hits reception phones.
If the receptionist then puts the call back to the IVR all options are still available but if you select the numbered option, say 2 for instance, the option is not recognised unless you follow it with the # key
02-08-2017 06:09 AM
Most SIP carriers only support RFC2833 for DTMF relay. CCX doesn't support in-band DTMF, including RFC2833. Something has to be interworking between the provider and the CCX CTI Ports. This could be your SBC with SIP KPML toward CUCM or it could be CUCM with an IOS Software MTP. I strongly suggest the former.
If you are using CUBE as your SBC this is as simple as including both RFC2833 and SIP KPML in the VoIP dial-peer facing CUCM. CUCM will ask for KPML when it needs out-of-band DTMF. CUBE will convert the NSE RTP packets to SIP KPML messages that CUCM can forward to the CTI Port over QBE. The command is "dtmf-relay rtp-nte sip-kpml".
If you are relying on CUCM to solve this with an MTP then you'll need to collect the trace files and investigate what happens with the MTP after the additional transfers relating to the operator. Reading CUCM traces can be tricky so you may need to open a TAC case for assistance on this front.
02-16-2017 07:35 AM
Thanks for the detailed explanation Jonathan.
It looks the latter case of having to open a call with TAC to decipher the trace files.
Will let you know the outcome
07-30-2018 02:54 PM
What was the final solution to this issue as I'm running into a very similar problem.
Thanks,
08-29-2022 09:40 AM
For this issue it was later determined that we hit bug ID CSCve21725 - DTMF Interworking Fails on CUBE Ent When Renegotiates From RF2833-RFC2833 to RF2833-KPML and in our scenario had to remove midcall-signaling passthru media-change
Symptom:
When using the CUBE command midcall-signaling passthru media-change DTMF is not working when an existing call (where DTMF is working) is transferred to UCCX.
A direct call to UCCX has DTMF functioning properly. I see CUBE internetworking between rtp-nte and sip-kpml
Only a call, internally transferred, to UCCX loses DTMF function when midcall-signaling passthru media-change present.
If we remove "midcall-signaling passthru media-change " then the call works.
Conditions:
rtp-nte inbound to SIP KPML outbound in CUBE
midcall-signaling passthru media-change
Workaround:
remove midcall-signaling passthru media-change
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: