WebRTC media issues after M148

46 views
Skip to first unread message

Martin Nyström

unread,
May 22, 2026, 12:08:19 PM (2 days ago) May 22
to discuss-webrtc
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.
sanitized_webrtc_logs_v2.txt

Tsahi Levent-Levi

unread,
May 22, 2026, 3:25:41 PM (2 days ago) May 22
to discuss-webrtc
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

unread,
May 22, 2026, 3:53:34 PM (2 days ago) May 22
to discuss...@googlegroups.com
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

unread,
May 22, 2026, 4:02:14 PM (2 days ago) May 22
to discuss-webrtc
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
Reply all
Reply to author
Forward
0 new messages