← Back to Knowledge Base

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
On this page4 sections
inboundaudiovideonetworkstalledBeforeCapturetype

Stalled before capture

Last updated Applies tortcstats-enrichmentrtcstats.com

This inbound stream was already stalled when the call started. The last packet was received before the capture began.

Description

This observation detects an inbound media stream (audio or video) that never received a single RTP packet during the capture: the stream was already stalled when the recording started.

When does it trigger?

The last packet on the stream was received before the first statistics sample of the capture. It can be caused by several factors, any of them equally likely:

  • Server-side pause: In SFU scenarios, the server stopped forwarding this stream, which is legitimate for muted or off-screen participants
  • Sender pause: The remote participant paused their camera or microphone before the capture started
  • Network interruption on the sender side: The sender lost connectivity before the capture started

It often means the capture was started after the user noticed the problem, so the beginning of the incident is not in the recording.

What do we do here?

We look at the value of lastPacketReceivedTimestamp from any inbound stream. When the value is frozen over the entire capture and points to a moment before the first statistics sample (and at most 12 hours earlier, to reject implausible clocks), we mark this Observation instead of Stalled stream. The timestamp of the Observation is the time of that last received packet, and it always affects 100% of the stream.

Since it covers the whole capture, this is always the only Observation reported for the stream: the little data left is not enough to say anything meaningful about jitter, loss, or audio/video quality.

See also