Re: [webrtc-stats] Exposing audio interruption metrics to JavaScript (#770)

Hi,

I’m encountering an interesting issue where a user’s device is connected to a dual-band Wi-Fi network (2.4 GHz and 5 GHz). Due to poor signal stability, the laptop frequently switches between bands—roughly every one or two minutes. Each switch causes several seconds of audio loss on both ends of the call.

From analyzing Chrome’s internal logs, it appears that at the transport level, data reception temporarily stops during these transitions. Interestingly, the sending (writing) direction generally remains active (CRWS → C-WI). Occasionally, the writable state drops to 0, which transitions the ICE connection state and the overall connection state to 5. However, in most cases, these interruptions are not detected (no state changes), and the application remains unaware that audio is being lost.

While digging into Chrome’s RTC event log dumps, I noticed two very useful statistics:
 • **interruptionCount**
 • **totalInterruptionDuration**

These metrics clearly illustrate the problem and correlate well with the periods of audio loss, as shown in the screenshot below:

<img width="2451" height="406" alt="Image" src="https://github.com/user-attachments/assets/426d2fb9-a382-4836-8afb-2348b826d7a3" />

Metrics such as audio level, concealed samples, and bytes received might suggest issues, but they can lead to incorrect conclusions too.

I’d like to suggest reconsidering exposing these audio-related metrics to JavaScript developers via the WebRTC stats API. This would allow applications to detect media flow interruptions improving overall call quality monitoring and user experience.
Thanks,
Olivier

-- 
GitHub Notification of comment by oanguenot
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/770#issuecomment-3082741637 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 17 July 2025 06:26:08 UTC