Media Transport and Use of RTP in WebRTC
Extracted elements (28)
A new short-term persistent RTCP CNAME is generated per RTCPeerConnection (rather than reusing a long-term identifier) because long-term persistent identifiers are problematic from a privacy viewpoint — they can be used to track a user or device across different services.
Multi-unicast conferencing (multiple RTCPeerConnections) is RECOMMENDED to be implemented as several individual RTP sessions rather than a single RTP session spanning multiple transport connections, because separate sessions allow different media bitrates per peer and distinct session configurations, even though this prevents endpoints from seeing third-party RTCP reception quality reports.
RTP/SAVPF is required because the RTCP-based feedback extensions (RFC 4585) provide an improved RTCP timer model allowing more flexible, event-driven RTCP transmission essential for congestion signaling and media events, while SRTP provides encryption, integrity, replay protection, and limited source authentication.
A significant number of legacy RTP implementations, especially VoIP-only systems, do not support all required RTCP features and in some cases do not support RTCP at all. Implementers must consider graceful degradation requirements when interoperating with such legacy systems.
The enhanced RTCP timer model defined in RTP/AVPF is backwards compatible with legacy RTP/AVP or RTP/SAVP systems if the 'trr-int' parameter is set to a value representing 4 seconds when interworking via a gateway (see RFC 8108 Section 7.1.3).
A single RTP payload type number MUST NOT be assigned to different RTP payload formats, or different configurations of the same format, within a single RTP session. Payload type assignments MUST be unique across signaling contexts when used to associate RTP packet streams with those contexts.
Each RTP endpoint MUST have at least one unique RTCP CNAME within the RTCPeerConnection. A WebRTC endpoint MUST NOT use more than one RTCP CNAME in RTP sessions belonging to a single RTCPeerConnection, and MUST generate a new, unique, short-term persistent RTCP CNAME for each RTCPeerConnection following RFC 7022.
If RTP header extensions are used, they MUST be formatted and signaled following RFC 8285. Header extensions MUST only be used for data that can safely be ignored by the recipient without affecting interoperability.
Implementations are REQUIRED to implement and use symmetric RTP (RFC 4961) to ensure send and receive RTP packet streams and RTCP are bidirectional transport-layer flows, keeping NAT and firewall pinholes alive.
Implementations are REQUIRED to support multiplexing RTP data packets and RTCP control packets on a single transport-layer flow (RFC 5761). This multiplexing MUST be negotiated before use; if SDP is used, the mechanism defined in RFC 5761 MUST be used for negotiation.
Implementations are REQUIRED to support signaled SSRC identifiers using the 'a=ssrc:' SDP attribute (RFC 5576) and MUST support random SSRC assignment and SSRC collision detection per RFC 3550. Implementations MUST also be prepared to accept RTP/RTCP packets using SSRCs that have not been explicitly signaled.
Implementations MUST support sending and receiving noncompound RTCP feedback packets (RFC 5506), and this usage MUST be negotiated using the signaling channel. For backwards compatibility, compound RTCP feedback packets must also be supported if the remote endpoint does not agree to noncompound RTCP.
Implementations MUST use SRTP and Secure RTCP (SRTCP). The RTP/SAVPF profile MUST be configured using the cipher suites, DTLS-SRTP protection profiles, keying mechanisms, and other parameters described in RFC 8827.
RTP packet stream senders are REQUIRED to understand the generic NACK message (RFC 4585 Section 6.2.1). Receivers are REQUIRED to implement support for RTP retransmission packets (RFC 4588) sent using SSRC multiplexing.
RTP (RFC 3550) is REQUIRED as the media transport protocol for WebRTC, and RTCP is a fundamental and integral part of RTP that MUST be implemented and used in all WebRTC endpoints.
Signaled bandwidth limitations such as SDP 'b=AS:' or 'b=CT:' lines received from the peer MUST be followed when sending RTP packet streams. A WebRTC endpoint receiving media SHOULD signal its own bandwidth limitations.
The client-to-mixer audio level header extension (RFC 6464) MUST be implemented. Implementations are REQUIRED to be capable of encrypting this header extension per RFC 6904 because the audio level data is considered sensitive; use of encryption is RECOMMENDED.
The extended secure RTP profile for RTCP-based feedback (RTP/SAVPF, RFC 5124) as extended by RFC 7007 MUST be implemented. WebRTC endpoints MUST NOT send packets using the basic RTP/AVP or RTP/AVPF profiles; they MUST employ RTP/SAVPF for all RTP and RTCP packets.
WebRTC endpoints are REQUIRED to support both session multiplexing (separate RTP sessions per media type over different transport-layer flows) and SSRC multiplexing (all RTP packet streams in a single RTP session on a single transport-layer flow, per RFC 8860).
WebRTC endpoints MUST follow the recommendations for FEC use given in RFC 8854. WebRTC endpoints MAY support other types of FEC, but these MUST be negotiated before they are used.
WebRTC endpoints MUST implement the RTP circuit breaker algorithm described in RFC 8083 to recognize and react to extreme network congestion. Endpoints MUST also implement congestion control to adapt to changes in network capacity; the circuit breaker is not a substitute for congestion control.
WebRTC endpoints MUST support multiple simultaneous SSRC values in a single RTP session, including random SSRC choice on joining, collision detection and resolution, and processing of CSRC lists from RTP mixers.
WebRTC endpoints that are sending media are REQUIRED to implement support for TMMBR (Temporary Maximum Media Stream Bit Rate Request) messages and MUST follow bandwidth limitations set by a received TMMBR message for their SSRC.
WebRTC endpoints that are sending media MUST understand and react to Picture Loss Indication (PLI, RFC 4585) feedback messages as a loss-tolerance mechanism; receivers MAY send PLI messages.
WebRTC endpoints that send or receive video MUST implement the Coordination of Video Orientation (CVO) RTP header extension as described in Section 4 of RFC 7742.
Long-term persistent RTCP CNAMEs can be used to track a user or device across different services. WebRTC endpoints MUST generate a new short-term persistent CNAME per RTCPeerConnection (RFC 7022), and different CNAMEs MUST be used for different RTCPeerConnection instances unless same-origin context explicitly enables reuse.
Despite SRTP media encryption, the first 12 bytes of the RTP header remain unencrypted, enabling deep packet inspectors to identify RTP streams via SSRC, correlate packet sizes and inter-spacing, and classify media types. Per-packet DiffServ marking or packet size patterns reveal codec and stream details.
In RTP sessions where multiple endpoints are directly visible, all endpoints share knowledge of each other's master keys and could inject packets claiming to come from another endpoint. Cryptographic source authentication for multiparty sessions would require additional mechanisms (e.g., TESLA for SRTP) that are not part of base WebRTC standards.