v141 · javascript

[WebRTC getStats] Align implementations on when RTP stats should be created

RTP stats objects, of type "outbound-rtp" or "inbound-rtp" in this case, represents a WebRTC stream. The identifier of this stream is the SSRC (a number). We should collect stats for streams that "exist", but implementations and spec has disagreed on when the stream should exist: if the SSRC information is conveyed via SDP, does the stream still exist before

concepts

  1. RTP Stats Timing

    Chrome's WebRTC stats now create RTP entries at the spec-required negotiation point. Cross-browser stats parity for RUM tools.

  2. Stats Lifecycle

    Matrix of when an outbound-rtp row appears across five connection events, before-and-after 141, against the W3C spec answer.

  3. Zero-Byte Row

    The operational follow-on: rows now exist with packetsSent=0 for the first poll cycles. Bitrate UIs flash 0kbps unless you skip those rows. One-line fix shown.

  4. RTP Stats Explorer

    Loopback RTCPeerConnection that polls getStats() every 500 ms. An interactive table shows every outbound-rtp and inbound-rtp row with key fields — SSRC, packetsSent, bytesSent, timestamp. A timeline chart plots when each row first appeared relative to SDP negotiation so you can see the Chrome 141 alignment in real time.

why it shipped

RTP stats objects, of type "outbound-rtp" or "inbound-rtp" in this case, represents a WebRTC stream. The identifier of this stream is the SSRC (a number). We should collect stats for streams that "exist", but implementations and spec has disagreed on when the stream should exist: if the SSRC information is conveyed via SDP, does the stream still exist before

references