02-20-2020 09:25 AM
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.
Solved! Go to Solution.
02-21-2020 08:17 AM
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.
02-20-2020 01:28 PM - edited 02-20-2020 01:33 PM
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
02-20-2020 08:56 PM
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?
02-21-2020 06:30 AM
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.
02-21-2020 08:17 AM
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.
02-21-2020 12:00 PM
Thanks James I really appreciate the help
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide