PSTN calls for UCCX - No audio

[KarolineSoares76078]

Hi everyone,

We've been having issues with PSTN calls to UCCX.

This is the scenario

PSTN --- E1 --- CUBE --- SIP Trunk --- CUCM --- UCCX

For incoming calls from PSTN to UCCX trigger, the greeting message plays and caller selects an option of the menu that gets redirected to end user on CUCM, the ringback plays OK.
Once the call is established between PSTN caller and the end user, both ends don't hear each other.

We can make outbound calls from phones/softphones registered to Call Manager and there is audio both ways.
Inbound calls directly to CUCM extensions works well too, audio works for both sides.

But everytime a call comes to the UCCX application and the caller makes a selection or dials the desired extension, the call
is directed to CUCM and plays the ringback, but when the agent answers, the call goes no way audio.

This UCCX application has two different triggers, which comes from two PSTN numbers (but same provider) through two different gateways. So, one UCCX application has triggers 4300 and 7300. Calls that come through 7300 work fine for audio, and calls that come through 4300 are presenting the issue I mentioned. So I think the application configuration is correct.

I compared configuration for both gateways and configurations on CUCM for the two sites, and they are similar. Each one uses their respective Device Pool, Partition, CSS, MRGL and so on, but they are similar.

Looking at the logs for both calls, I could see that they both need to use MTP for DTMF mismatch. While the OK call uses hardware MTP from gateway, the NOT OK call uses Software MTP from CUCM subscriber (the call comes from Publisher).

I don't know if this is related to the issue, but the coincidence is that I found another site that uses SW MTP from CUCM Subscriber and it's not working either. And this was the only odd thing I could notice on the logs, because the packet captures for working and non-working calls shows that the end user sends RTP to the gateway and the gateway sends RTP to the end user.

All sites have all resources available: hardware resources from the respective gateways and software resources from CUCM publisher and subscriber). But they allocate different resources.

Did you guys have any similar issue? 

Thank you in advance.

[TechLvr]

You always need to reset the SIP Trunk after applying changes to it as Dymytro also mentioned. 

Share traces of the call after resetting the trunk.

[TechLvr]

@KarolineSoares76078 I just noticed something else in your call traces. When the call initially connects to UCCX, the audio ports advertised by CUCM are within the default range of 16384-32766. But after that, CUCM advertises port numbers outside the default range for the audio after the call connects to the agent. 
Below are two examples.

m=audio 16042 RTP/AVP 18 101
Or 
m=audio 8150 RTP/AVP 18 101

Have you created a custom port range? This could also be causing issues.

Could you please check the SIP profile assigned to the agent's device and verify the audio port range it uses?

If there are firewalls involved, and they do not allow these custom ports, then that would cause audio issues.

In CUCM, go to Device > Device Setting > SIP Profile
Open the SIP profile in question and provide screenshot of the “Media Port Ranges” section.

See below example.

[KarolineSoares76078]

Thanks for the answer. I did reset the trunk after applying those changes, but still it didn't work. I will share the traces in a while.

About the audio ports being advertised, I don't have custom ports configured on CUCM. The SIP profiles assigned to the trunk and the agent's device are using the default range 16384 - 32766.

But I gathered logs from CUCM and saw that CUCM advertises correctly a port within the range and tells the gateway to send media traffic to IP address of the CSF device. But when the gateway receives the message, it's showing another port, outside of the range, and IP address has changed to CUCM IP.

Sent from CUCM
ACK sip:1121364500@10.10.20.5:5060 SIP/2.0
o=CiscoSystemsCCM-SIP 1501682 5 IN IP4 192.168.10.10
s=SIP Call
c=IN IP4 10.89.130.31
m=audio 23078 RTP/AVP 18 101
a=rtpmap:18 G729/8000

Received on the gateway
Received:
ACK sip:1121364500@10.10.20.5:5060 SIP/2.0
o=CiscoSystemsCCM-SIP 1501682 5 IN IP4 192.168.10.10
c=IN IP4 192.168.10.10
m=audio 16042 RTP/AVP 18 101
a=rtpmap:18 G729/8000

I made other test calls and they all have the same scenario, CUCM is advertising port within the range, but gateway receives another port and IP address on the message.

[Dmytro Benda]

Hi Karoline, 

Didn't you try to configure dtmf-relay sip-kpml (so that leave only sip-kpml method and remove sip-notify) in the dial-peers? The trunk side should be "OOB and RFC2833" or "No Preference"

My Cisco Unified Communications Blog 

[KarolineSoares76078]

Hello Dmytro,

Yes, I configured dtmf-relay sip-kpml and changed the trunk to "OOB and RFC2833". In this case, the digits were recognized, thanks for the help! But still CUCM is dinamically allocating a MTP resource. Can't really tell what's going on.

After changing the configuration, I called and the issue happened again. I can hear prompts and ringback, but once the call connects, there's no audio. 

The log of this call is attached, but it shows again that CUCM tells the gateway to send media traffic to CUCM, instead of the endpoint. And on CUCM, the message is correct, it advertises the endpoint address.

[Dmytro Benda]

Hello Karoline, 

Try to set on the SIP Trunk "No Preference" as @TechLvr advised. This should eliminate MTPs at all. Let's see what happens then.

My Cisco Unified Communications Blog 

[TechLvr]

Then I guess that's fine because CUCM inserts software MTP into the calls to extension 6219, and  apparently, MTP uses a different port range. But the calls to 6219 does not need MTP in this scenario.

The reason CUCM inserts MTP is because the SIP Trunk "DTMF Singling Method" is NOT set to "No Preference". As soon as you introduce a preference, then the calls always use MTP. Please change it to "No Preference", save, reset the trunk, and test again. 

If for some reason, a software MTPs are still used, in CUCM, go to Media Resource > Media Termination Point, and make sure all software MTPs show registered. Regardless of the results, navigate to the Cisco Unified Serviceability page, then go to Tool > Control Center - Feature Services, and restart Cisco IP Voice Media Streaming App on the nodes where this service is activated. Check back on the MTPs and ensure they are registered. Test your calls again.

If the above steps does not make any difference, try putting "CSF6219" in a device pool that has a region relationship of 64kbps with your SIP trunk and test again.

The device pool it is currently using has a region setting that only allows 8kbps for the calls over the SIP Trunk thus g729. This should not be an issue, but it wouldn't hurt trying with a different codec just to see the results. 

[slawek ziobro]

That is great info

[Roger Kallberg]

Not related directly to your issue as such but your setup is not technical a SBC (Cube), as you have an E1 connection with PSTN it’s a TDM gateway, aka a traditional time devision multiplex type of connection with the public telephony network.

[TechLvr]

@KarolineSoares76078  On "CSF6219" device configuration page, make sure Media Termination Point related boxes are unchecked (There should be two boxes). This is another reason MTP is inserted into the calls to extension 6219.

[KarolineSoares76078]

Hello @TechLvr and @Dmytro Benda, thank you for the answers.

I changed the DTMF method to "No preference" on the SIP Trunk, and dial-peers have the command dtmf-relay sip-kpml. I called and pressed digits but they were not recognized again. I tried with command dtmf-relay rtp-nte sip-kpml too, but same result. The log is attached.
DTMF is only working when I change to RFC 2833 on the trunk. 

On the device configuration page I made sure that the MTP box is unchecked.
Also did the test after resetting Cisco IP Voice Media Streaming App, got the results that the media call works fine until the ringback, and goes silent when connects to agent.

I tested with a device that's on a region which allows 64kbps, but the results were the same.

I had contacted TAC and after analyzing logs, they told me to check with network team the reason why CUCM is sending the endpoint IP and a port, but when the gateway receives the message, it's CUCM IP and a different port. 
Team confirmed that there's nothing on the path blocking communication between endpoints and gateway and we don't have SIP inspection enabled. 

[Dmytro Benda]

Hi Karoline, 

May I please ask you to share the log of this call from CUCM RTMT? It will be fine to see the reason why the CUCM insert the MTP into the call. 

This is what Cisco says about dial-peer and SIP trunk config for the UCCX:

"you can configure the dial peers facing the CUCM that correspond to the UCCX application trigger number to
negotiate an out-of-band method of DTMF relay with CUCM.

These methods include SIP KPML and/or SIP NOTIFY. Below is a configuration snippet of two dial peers created to negotiate SIP KPML and SIP NOTIFY with the CUCM.
Note: Ensure the sip trunk towards the CUBE and CUCM is set to DTMF as “no preference” and let the two end points negotiate it end to end. 

Dial Peer Facing CUCM example:
dial-peer voice 10 voip
dtmf-relay sip-kpml sip-notify

CUBE negotiates and subsequently relays DTMF out-of-band through SIP NOTIFY messages to the CUCM with the above configuration. CUCM can then convert these SIP messages to JTAPI signaling before relaying to UCCX. There is no requirement for an MTP to be configured and invoked for the call."

So, from my prospective setting DTMF out-of-band should help, but I have still no idea why the CUCM inserts MTPs. May be we can see it in the CUCM log trace.

My Cisco Unified Communications Blog 

[KarolineSoares76078]

Hello Dmytro,

For the scenario that I set trunk to "no preference" and dial-peer with "dtmf-relay sip-kpml" it didn't invoke the MTP, but also didn't accept the digits I pressed, so the option of the IVR didn't get selected. The call never reached an agent, it only played the greetings prompt and I could not make a selection on the menu.
I pressed four digits and on the gateway traces, I see four messages received from CUCM "SIP/2.0 481 Subscription does not exist". 
Are these the logs you'd like to see?

[TechLvr]

@KarolineSoares76078 Remove all Software/Hardware MTP resources from the MRGL of the user's endpoints. You can leave other resources in there such as Annunciator, MOH etc. This way CSF devices do no have access to MTPs at all.

Also, Keep in mind that media resources will be accessible to all devices if they are not assigned to any groups. So if you have any MTPs that are not part of any groups, just assign them to a group even if the group is not in use. In this case, MTPs are to MRGs what Partitions are to CSSs. 

[Dmytro Benda]

Hello Karoline, 

No, I was speaking about the logs from CUCM itself. You can receive it with Real-Time Monitoring Tool. It will be good to see the log for the call, when it reaches the agent and you have silence. In this log we can see the moment when MTP is allocated. 

You already tried dtmf-relay sip-notify sip-kpml and dtmf-relay sip-kpml. Can you also try dtmf-relay sip-kpml sip-notify and "no preference" as it is described in Cisco doc?