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
On this page5 sections
No packets received
Last updated Applies tortcstats-enrichmentrtcstats.com
A receiving stream was set up but no packet ever arrived during the whole capture.
Description
This observation detects an inbound audio or video stream that was set up and negotiated (its codec was resolved) but that never received a single packet during the whole capture. Nothing at all arrived on this stream.
Because inbound-rtp.packetsReceived already includes retransmissions, a count of zero means truly nothing arrived, not even a retransmitted (RTX) packet.
Is it a problem?
It depends on the cause. A receive stream that never gets a packet can be benign or can point at a real bug:
- The subscription was never honoured: in SFU scenarios the client negotiated the stream but the server never started forwarding it. This is the most common cause and usually points at a subscribe or a slot assignment bug.
- The sender never produced media: the remote participant joined muted or with the camera off and never enabled it, and the server forwards a live but empty stream.
- Transceiver misuse: the application called
addTransceiver()and negotiated a receiving m-line that no remote source was ever attached to. - Media blocked while the transport was up: ICE and DTLS completed, so the connection looks healthy, but no RTP ever traversed the path.
It is only a genuine fault when media was expected on this stream and never came, which shows up as one-way audio or a participant whose video never appears.
When does it trigger?
The stream has a resolved codec, its packetsReceived total is zero, and no lastPacketReceivedTimestamp was ever reported (so no packet arrived even briefly). The observation covers the whole capture and its timestamp is the first statistics sample of the stream.
This is the "codec present, nothing arrived" case. It is distinct from its neighbors:
- If the stream has no codec at all, it is reported as Unused media stream instead.
- If the stream did receive packets and then went silent, it is a Stalled stream or, when the last packet predates the capture, Stalled before capture.
What do we do here?
We look at inbound streams whose codec was resolved but whose packetsReceived total stayed at zero with no lastPacketReceivedTimestamp ever reported, and we report them once for the whole capture. A stream that received even one packet is handled by the stalled-stream observations, never by this one.
See also
- Unused media stream (a stream with no codec that never carried media)
- Stalled stream (packets arrived, then stopped mid-capture)
- Stalled before capture (packets arrived before the capture started, then stopped)
- Empty connection (a peer connection that exchanged no media at all)
- inbound-rtp->packetsReceived
- WebRTC Statistics Specification - RTCReceivedRtpStreamStats
