← 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 page5 sections
inboundaudiovideobuginboundMediaNotDeliveredtype

Inbound Media not delivered

Last updated Applies tortcstats-enrichmentrtcstats.com

The media reached the transport but was not delivered to the stream. It can point to an SRTP decryption or authentication failure, or an SSRC or MID demultiplexing mismatch.

Description

This observation detects a peer connection whose selected network path kept receiving traffic at a media-like rate while its single inbound stream recorded no packets over the same period. The media reached the transport but never showed up on the receiving stream.

It reads two independent signals at once and correlates them in time: the selected candidate pair keeps counting received bytes (candidate-pair.bytesReceived) at a bitrate typical of live media, while the inbound stream's packetsReceived and bytesReceived counters stay flat. Something arrived on the wire that the receiver could not turn into stream packets.

Is it a problem?

Usually yes. It is experienced as one-way media on a call that otherwise looks connected: ICE and DTLS completed, the path is live, bytes keep flowing, yet the participant is not heard or not seen. The most consistent explanations are:

  • An SRTP decryption or authentication failure: the packets arrive but fail to decrypt or authenticate, so they are dropped before they can be counted on the stream.
  • An SSRC or MID demultiplexing mismatch: the packets arrive on the transport but do not match the SSRC or MID the receiver expects, so they are never routed to this stream.

It is a strong hint rather than proof. Other traffic also flows on the selected pair, in particular RTCP feedback, so a high pair bitrate is not on its own a guarantee that undelivered media is the cause. This is why the floor is set well above the feedback envelope before the observation fires.

When does it trigger?

The peer connection must first qualify: exactly one inbound RTP media stream, a single media kind across all its RTP streams (all audio or all video), and no data channel. Then, using the transport's stable selected candidate pair, the analyzer looks for a sustained window of at least 5 seconds where, for every sampling interval:

  • the inbound stream received zero bytes and zero packets, and
  • the selected pair kept receiving above a media-like floor of about 50 kbps.

The window is segmented on any change of the selected candidate pair, so an ICE handover (which starts a fresh pair with reset counters) never fabricates a rate. The observation is medium severity and its timestamp is the first sample of the qualifying window.

When it fires, it is the more specific, transport-evidenced diagnosis for that stream, so the benign siblings No packets received and Stalled stream are suppressed on the same stream to avoid contradictory readings.

flowchart TD A["Peer connection"] --> B{"Exactly one inbound
RTP media stream?"} B -->|"No"| S["Skip"] B -->|"Yes"| C{"Single media kind across all
RTP streams, and no data channel?"} C -->|"No"| S C -->|"Yes"| D{"On the stable selected pair, a window
of 5 s or more where the stream stays flat
while the pair keeps receiving above 50 kbps?"} D -->|"No"| S D -->|"Yes"| E["Fire: inbound media not delivered
(suppress noPacketsIn, stalledStream,
stalledBeforeCapture on this stream)"]

What do we do here?

We qualify the peer connection, then walk the single inbound stream sample by sample against the selected pair's received bitrate, requiring a flat stream and above-floor media on the pair across a sustained window before reporting once. A muted or held remote, whose pair only carries low-rate feedback, stays below the floor and does not fire.

See also