WebRTC media issues after M148

[Martin Nyström]

Hi,

I'm reaching after straws here. We appear to have starting having really odd issues with audio starting with the release of M148, both in Edge and Chrome.

Our WebRTC agents have suddenly, at random, lost their outgoing rtp stream. I have spent the entire week troubleshooting this, but I cannot find anything that would cause this.

Our backbone consist of recent releases of Asterisk 20, the frontend uses a SIP.JS setup. For codecs we use Opus.

I have attached our custom built logs that capture packets, audio level, device changes, ice negotiations etc. This example works well up until the last ~42 seconds where the microphone just go silent in the Asterisk, as if someone cut the media.

Now I would suspect local firewalls etc. but we're started seeing this on many different clients since the beginning of May.

Any suggestions or help would be greatly appreciated.

[Tsahi Levent-Levi]

Martin,

This file isn't "standard" so hard to use it on analysis tools properly.

Easiest thing you can do to figure out what's wrong is to take a regular webrtc-internals or rtcstats dump file and upload to rtcstats.com to see what's wrong.

Feel free to share the file once you upload with me and I'll be happy to take a look if you need.

BTW - as for anonymization - you can use https://rtcstats.github.io/rtcstats/dump-importer/anonymize on the dump file before uploading it to rtcstats.com :-)

Regards,

Tsahi

[Martin Nyström]

The problem is we cannot replicate it in a controlled environment and the issue is rather rare across the volumes we handle.

Sure we can attempt to get one of our impacted agents to run the webrtc internals. But that’s a long shot. I pray someone could confirm an issue in a recent chromium.

Sent from Outlook for iOS

---

From: discuss...@googlegroups.com <discuss...@googlegroups.com> on behalf of Tsahi Levent-Levi <tsahi.le...@gmail.com>
Sent: Friday, May 22, 2026 9:25:41 PM
To: discuss-webrtc <discuss...@googlegroups.com>
Subject: [discuss-webrtc] Re: WebRTC media issues after M148

 

CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

--
This list falls under the WebRTC Code of Conduct - https://webrtc.org/support/code-of-conduct.
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/fc26b199-05b2-428d-b259-877b675a98f4n%40googlegroups.com.

[Tsahi Levent-Levi]

Martin,

Given time, and as a long term solution, I'd suggest using rtcstats-js + rtcstats-server (both open source) to collect that data at scale across all sessions so that such an issue won't get lots across your volumes.

What you might be able to do rather faster is to follow the suggestions here: https://www.rtcstats.com/blog/never-miss-webrtc-internals-dump

Essentially, connect rtcstats-js and store the rtcstats file in the browser's indexedDB, and be able to retrieve the last one on demand from any browser in your deployment.

What you are currently collecting and the way you're collecting it isn't good enough to catch such issues.

Regards,

Tsahi

[Martin Nyström]

I may have found the issue, has not fully tested it yet. But it appears these calls switch to TURN mid call, because of a getUserMedia task, without restart ICE and sending a re-INVITE. This causes Asterisk strictrtp to block the new media source from the agent side which the asterisk logs support. Does this makes sense? I believe it does.

[Philipp Hancke]

Am Di., 26. Mai 2026 um 12:27 Uhr schrieb Martin Nyström <martin....@connectel.se>:

I may have found the issue, has not fully tested it yet. But it appears these calls switch to TURN mid call, because of a getUserMedia task, without restart ICE and sending a re-INVITE.

If this happens after a getUserMedia call then it may open up additional network routes but that by itself should not cause new candidates to be gathered or a switch to TURN.

And nothing should have changed in Chrome M148.

This causes Asterisk strictrtp to block the new media source from the agent side which the asterisk logs support. Does this makes sense? I believe it does.

Blocking the new media source isn't something Asterisk should do if it comes with a valid STUN  exchange. WebRTC never followed the "we must signal the candidate we picked to the remote side" theory but switching candidate-pairs mid-session does not sound exactly right either.

This starts to sound like a classic example of "you are doing it wrong! No *you* are doing it wrong".

Happy to take a look at a webrtc-internals or rtcstats dump if you have one, I still enjoy that ;-)

cheers

Philipp

To view this discussion visit https://groups.google.com/d/msgid/discuss-webrtc/e8f2f3ae-082f-4a28-b58f-5368f3003851n%40googlegroups.com.

[Martin Nyström]

Replying to myself with a registered Asterisk issue related to this https://github.com/asterisk/asterisk/issues/1955