cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3011
Views
15
Helpful
6
Replies

UCCX DTMF Issue

simonmossman
Level 1
Level 1

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

6 Replies 6

Jonathan Schulenberg
Hall of Fame
Hall of Fame

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?

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

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

What was the final solution to this issue as I'm running into a very similar problem. 

 

Thanks, 

Peter Kuznicki
Level 1
Level 1

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

 

Getting Started

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: