PSTN call to UCCX IVR for jabber endpoint no audio

[ragz3000]

PSTN -> CUBE -> SIP Trunk -> CUCM -> UCCX -> Internal Jabber device

Scenario 1:

a) When MTP is disabled on CUBE, calls have audio for direct call between PSTN to Jabber device.

b) When MTP is disabled on CUBE, calls does NOT have audio for call between PSTN to Jabber device (using UCCX IVR).

Scenario 2: When MTP is enabled on CUBE, all above scenarios work fine.

Much appreciate your assistance.

[Anthony Holloway]

Was your MTP enabled or disabled on your CUBE SIP Trunk in CUCM before you started troubleshooting this?

What DTMF is negotiated between CUBE and CUCM while the call is on UCCX? If you don't know, please use the following command to check on CUBE:

show voice call active | in Peer|Dtmf|Coder|VAD

[Ayodeji Okanlawon]

Hi there,

The issue here is simply dtmf related. UCCX devices, cti ports, cti route points only support OOB signalling for DTMF while most sip deployments will use rfc4733. Hence an MTP device is needed. A common issue I have seen here is that due to lack of careful design taking the need for MTP into consideration, sometimes cucm selects a random mtp resource to use. I won't be surprised that this is what is happening in your case. It's may be possible that the mtp chosen does not have an up routing path to the devices. To confirm this we will need cube debug ccsip message when cube mtp is disabled...that will tell us where media is being terminated

[ragz3000]

Hi thanks for your reply, I had to log TAC Case and below is resolution provided and it resolved audio issues.

One thing that you could try, without any MTP, is first setting the CallManager service parameter for “Duplex Streaming Enabled” to “True”.   I have sometimes seen similar issues with some ITSP’s that don’t like the RTP being set to Receive Only (as a Music on Hold server doesn’t need the RTP stream sent back from the ITSP to itself if it is only sending MoH).

[Ayodeji Okanlawon]

Thanks for the update. Looks like you are not using mtp for dtmf in your case. This is an old hack..glad it worked ( I believe there are other ways to solve this though without changing service parameters)...

[Anthony Holloway]

You do not need an MTP to convert between rtp-nte and an oob dtmf on CUBE. CUBE can interwork this no problem without cucm even knowing. Some people incorrectly limit CUBE to rtp-nte only on the inside, or set CUCM SIP trunk to rfc2833 to CUBE, but you should supply both inband and OOB on CUBE and set CUCM to No Pref.

[Ayodeji Okanlawon]

+5 ( Anthony), great point.

 CUBE specifically can interwork between rtp-nte, sip-kpml and sip-notify and sip-info( for high releases) hence recommended practice would be to have

++ inbound CUCM anchor dial-peer ++

     dtmf-relay rtp-nte sip-kpml

++ ITSP facing dial-peer ++

     dtmf-relay rtp-nte

In the order of DTMF preference, KPML is higher, hence KPML will be used for interactions with UCCX devices, consequently CUBE will convert the NSE RTP packets ( from ITSP) to SIP KPML messages that CUCM can forward to the CTI Port over QBE, eliminating the need for MTP completely