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.?
Thanks in advance
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?
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
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.
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