cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2143
Views
4
Helpful
10
Replies

One-way audio after hold resume since migration to Webex

groupespinelli
Level 1
Level 1

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

 

10 Replies 10

Scott Leport
Level 7
Level 7

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:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-midcall-reinvite.html

 

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.

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

 

Hello,

It took us months to figure out the affected calls were calls coming from a third party used for call tracking (Twilio). Unfortunately we couldn’t just drop those numbers because they were published everywhere. And after multiple analysis we figured out the problem was with Bell Canada and not Twilio. Apparently they needed to update old equipments on their network to fix that issue (CS2Ks and C20s don’t know what it is exactly). They tried to patch it but it didn’t work and said it would take at least 2 years before they can fix it.

So for us the only solution was to move away from our on-site cubes and sip trunks and switch the lines over to Cisco PSTN.

Good luck

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.”

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.

For the moment just CISCO TAC CASE NUMBER

And updates about is comming…

[image0.png][image1.png]

@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!

It’s exactly what I said. It’s just a workaround, but we need to give our customer some proof that not only have we been working on this for months, but that there is progress, and for now, there is a workaround. We have customer with several operators and physical terminals, which often require the ON HOLD feature, and it was a real pain to deal with (this didn’t happen with our previous Cisco PBX…). We fully understand the advantages of ICE, but I can’t afford to lose customers by waiting months for a solution. 🤷🏻‍

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.)