cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
3972
Views
0
Helpful
5
Replies

UCCX One-Way Audio

scooter817
Level 2
Level 2

Hi Everyone

I have a group of 10 users who were taking calls using a hunt pilot configuration. The manager didn't like all those lines ringing at once so he asked me to move them to UCCX and Finesse. I did this last November and initially it was working fine, now they are calling me saying that they are having one-way audio issues with callers. They are saying that the call comes in and when an agent picks it up they can't hear the customer but the customer can hear them. So they hang up and call back and then the call works correctly. I have 3 other locations using UCCX and Finesse and none of them are having this issue. If anyone has seen this before I would greatly appreciate it if you could give me some insight on what would cause this. Thank you all in advance for the replies and have a great day. 

1 Accepted Solution

Accepted Solutions

Issues that can't be replicated are troublesome to diagnose. Have the agents start documenting the time and calling number of the calls. Once you get a few use UCM CDR's to figure out what what gateway they are connecting to. Since this is CCX you'll have a few call legs to follow.

Look for  the origIpAddr field. This will tell you where the call enter the system. It should be you PSTN gateway. If they are all the same you have a starting place. 

From there follow the path. The first hop goes to CCX. Are there any audio issues reported with CCX menus or greetings? If so problem is between the gateway and there. If not, then move on the phones.

 

CCX will hand the call off to the phone once the agent answers. It is no longer part of the call flow. Unless there is a media resource like a transcoder or MTP in between, the call path should be from the gateway to the phone. Connectivity to the phone is fine because the agent can hear the caller. Its connectivity from the phone to the gateway you want to trace and test.

 

It can take some effort to figure out issues like this.
Initial tests I'd run are:
From the vlan the phone is on, ping the gateway the calls come in on
Check your regions and see what codec these calls should be using. CCX is probably using G711. If phone is using something different for these inbound calls there is a transcoder. Figure out what it(they) i and the ping from phone vlan to it.

Hopefully you'll find a device you can not ping from the phone vlan. That is your issue. If not, gonna have to dig deeper in to things and that can go a number of ways.

 

 

 

 

Thanks,
James Coffey

View solution in original post

5 Replies 5

Sean Lynch
Level 7
Level 7

Have you reviewed the call traces from the SDL logs of the call manager? Since this was working previously without issues before, can you determine if there have been any changes or new additions to the enterprise/network? Any new voice gateways? New routes established in the network infrastructure?
In my experience, one way audio issues are typically a default gateway in the path of the path of the call not having a route back to the network/subnet of the endpoint in question. This happens frequently on VPN connections where the routes or protocols get restricted due to security requirements.  Look closely at your routing and make sure something is not being blocked because of a missing route in the audio/stream/path in the network.
That's where I'd start.
Hope this helps.
-Sean

arcaidy
Level 1
Level 1

I agree. One way audio is almost always network related.
Something I'd add is to check the media resources and note any transcoder or MTP's. See if they are reachable from the phone network.
Are these happening during busy call volumes? Could the problem calls be coming in another gateway because capacity has been reached on the primary?
Are there more than one DID to reach the queue?  If so, do the numbers connect through the same PSTN gateway or different?

Thanks,
James Coffey

HI James

The location is question is always busy and all of my calls are routing through one cube router and yes I have 10 DID that point to the UCCX trigger.

Issues that can't be replicated are troublesome to diagnose. Have the agents start documenting the time and calling number of the calls. Once you get a few use UCM CDR's to figure out what what gateway they are connecting to. Since this is CCX you'll have a few call legs to follow.

Look for  the origIpAddr field. This will tell you where the call enter the system. It should be you PSTN gateway. If they are all the same you have a starting place. 

From there follow the path. The first hop goes to CCX. Are there any audio issues reported with CCX menus or greetings? If so problem is between the gateway and there. If not, then move on the phones.

 

CCX will hand the call off to the phone once the agent answers. It is no longer part of the call flow. Unless there is a media resource like a transcoder or MTP in between, the call path should be from the gateway to the phone. Connectivity to the phone is fine because the agent can hear the caller. Its connectivity from the phone to the gateway you want to trace and test.

 

It can take some effort to figure out issues like this.
Initial tests I'd run are:
From the vlan the phone is on, ping the gateway the calls come in on
Check your regions and see what codec these calls should be using. CCX is probably using G711. If phone is using something different for these inbound calls there is a transcoder. Figure out what it(they) i and the ping from phone vlan to it.

Hopefully you'll find a device you can not ping from the phone vlan. That is your issue. If not, gonna have to dig deeper in to things and that can go a number of ways.

 

 

 

 

Thanks,
James Coffey

Thanks James I really appreciate the help