12-14-2022 12:45 PM
Hello,
Since migrating to Webex we are experiencing one-way audio issues on some calls (not all) after the callee puts an external caller on hold and resumes the call. Then the callee can't hear the caller but the caller can hear the callee fine.
We still have dial-peers directing some calls to our on-premise CUCM and we are not experiencing the problem on CUCM only on Webex.
We ran some tests with numbers on the Cisco PSTN and we were not able to replicate the issue so we suspect a misconfiguration in our cube could be the problem.
Any suggestions?
Thanks
12-15-2022 02:14 AM
Complete shot in the dark here, but do you have either of the following commands configured on your CUBE:
- midcall signaling passthru
- midcall signaling passthru media-change
Some info in the link below about what it does and where you can apply it, either globally or on dial-peers:
12-15-2022 05:45 AM
Hi Scott, thanks for your reply. Yes Cisco support had me add midcall signaling passthru media-change globally but it did not fix the problem.
When looking at the packet captures of those calls we noticed that when resuming the call the SEQ number changes but the SSRC stays the same. When it changes to an inferior number that is when we are getting one-way audio. It looks like the cube is dropping the packets for being out of sequence.
But again we never have this problem when the calls are forwarded to CUCM. It looks like the problem could be related to using SRTP with Webex but I am no expert.
11-21-2023 02:27 PM - edited 11-22-2023 06:59 AM
We are having this EXACT same problem? We are using a local telco. We were having one-way audio issues on all calls intermittently as well until i forced the codec on the Telco legs to G711 ulaw as a re-invite right at the beginning of the call was trying to add G711 alaw to the call...this would cause the RTP packets to be rejected due to sequencing as well. Forcing to G711 seemed to fix the problem for basica calls...however the issue still remains when we place calls on hold and then resume...one-way audio. Were you ever able to resolve the issue?
I have also tried setting
- midcall signaling passthru
- midcall signaling passthru media-change
globally with no affect
11-22-2023 06:04 AM
08-22-2024 12:05 AM
Better late than never, but I wanted to update you that we still have the case open with Engineering and CISCO, and it’s been about four months now. We captured packets related to this issue and were able to isolate several things. Among them, we found that the One-way Audio only occurred when placing a call on hold. Sometimes it happened quickly, but eventually, after leaving the call on hold for a few minutes, we would experience the problem. A firmware update for the phones was implemented, which allowed us to restore voice if One-way Audio occurred after recovering from hold by putting the call on hold again and then recovering it. But as we all know how users are, aside from attributing these issues to WEBEX (and that this didn’t happen with CME before...), they didn’t remember the workaround.
Anyway, about a week and a half ago, they contacted us to say that after our numerous labs, captures, and sending the exact time of the drop, they discovered that the issue was related to ICE (Interactive Connectivity Establishment). Like with other technologies (e.g., Cisco Meraki cams), ICE allows devices to attempt to communicate internally without generating traffic to the internet. However, during this negotiation/check, it seems that voice was being lost. We tested it by disabling the ICE feature in our physical phone profiles, and since then, the calls no longer drop. It’s clear that this feature helps and optimizes WAN traffic usage, but knowing how much our calls consume and that many users are using the Webex Client (not a physical phone), it seems 100% worth it to eliminate this issue by applying the mentioned workaround. Once we’re notified that the solution has been applied in new upgrades, we’ll test it, but for now, it’s working, and we’re very clear about it, given that we simulated and conducted a thorough follow-up with both CISCO and our operator, reaching the clear conclusion that the only solution was on the CISCO SIDE... Therefore, “disable ICE on the devices until further notice.”
08-28-2024 11:23 AM
Thanks for the update! Did Cisco provide a BugID, a "feature name" or target version for the fix so we can track it from our end, too?
Regards.
08-28-2024 12:36 PM
08-28-2024 04:10 PM
@Maximo Dominguez I sure hope you're continuing to press your TAC case for a real root cause, defect ID(s), and eventual ability to re-enable ICE. It's an important feature that can meaningfully improve call quality. The G.114 end-to-end delay budget (i.e., from the speaker's lips to the listener's ear) of 150ms remains a valid design target. Hairpinning media through Cisco's data center adds a bunch of delay that will increase the chance of annoying talk-over events. It also greatly increases the opportunity for jitter as packets cross the internet two additional times. All of this is exacerbated by modern day SIP connections: carriers are also backhauling traffic to central locations instead of landing the ISDN circuit locally in your city's central office. This isn't a game of snake; the goal is not to make the call path as long as possible.
For anyone that finds this in search results: disabling ICE should be a short term workaround only. Do not adopt this as your standard!
08-28-2024 11:26 PM
08-29-2024 05:57 AM
Glad to hear it.
Anyone on this thread that has previously opened a TAC case for this issue: please reply with your SR number. The business unit is now aware of this thread and are starting to dig in behind the scenes. (This isn't normal. TAC cases should have been escalated, but the product managers understand the impact ICE can have and want it to work.)
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