WebRTC Metrics

A comprehensive overview of WebRTC statistics, derived calculations, extracted features, and observable signals, to better understand call quality, connectivity, and user experience in rtcStats

Back

outboundaudiovideonetworkstalledBeforeCaptureOut^type

Stalled outbound before capture

This outbound stream was already stalled when the call started. No packet was sent during the whole recording.

Description

This observation detects an outbound media stream (audio or video) that did not send a single RTP packet during the capture: the stream was already stalled when the recording started.

When does it trigger?

The stream sent media at some point before the capture (bytes were sent on it), but the packet counter never moved during the whole recording. It can be caused by several factors:

Track ended or replaced: The application stopped the capture track or switched the sender to another track before the capture started
Transport down: The connection carrying this stream went down before the capture started
Application stopped the sender: The application stopped or removed the sender without closing the connection
Deactivated simulcast layer: The encoder stopped feeding this simulcast layer (bandwidth adaptation, or no subscriber needed it) before the capture started

Note that a muted microphone or a disabled camera track is not a cause: muted tracks keep sending packets (silence or black frames). A frozen counter means the sender really stopped transmitting.

It often means the capture was started after the user noticed the problem, so the beginning of the incident is not in the recording. A stream that never sent anything at all is reported as an unused stream instead.

What do we do here?

We look at the cumulative packetsSent counter of any outbound stream that carried media. When the value is frozen over the entire capture, we mark this Observation instead of Stalled outbound stream. The timestamp of the Observation is the first statistics sample of the capture.