RFC 8834

Media Transport and Use of RTP in WebRTC

📅 published January 2021, from ietf

RFC 8834: Media Transport and Use of RTP in WebRTC 🎀

okay bestie, this is RFC 8834, and it's basically the rulebook for how RTP gets used inside WebRTC 💅

Authors: C. Perkins (University of Glasgow), M. Westerlund (Ericsson), and J. Ott (Technical University Munich)
Category: Standards Track
Date: January 2021
Obsoletes / Updates: nothing listed in the header 🫶
ISSN: 2070-1721, published by the IETF

Abstract ✨

so the WebRTC framework lets two peers' web browsers do direct, interactive, rich communication 🦋 we're talking audio, video, text, collaboration, games, etc. 🎮 this memo covers the media transport side of WebRTC. it explains how the Real-time Transport Protocol (RTP) gets used in the WebRTC context, and it lays out which RTP features, profiles, and extensions need to be supported 💜

Status of This Memo 📜

this is an Internet Standards Track document 🌈

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 7841 🍓

for the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8834 ✨

Copyright Notice 💌

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please actually read these, bestie, because they're literally about your rights and restrictions for this doc 👀

also, any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. they come without warranty, same as the Simplified BSD License says 💖

Table of Contents 📚

   1.  Introduction
   2.  Rationale
   3.  Terminology
   4.  WebRTC Use of RTP: Core Protocols
     4.1.  RTP and RTCP
     4.2.  Choice of the RTP Profile
     4.3.  Choice of RTP Payload Formats
     4.4.  Use of RTP Sessions
     4.5.  RTP and RTCP Multiplexing
     4.6.  Reduced Size RTCP
     4.7.  Symmetric RTP/RTCP
     4.8.  Choice of RTP Synchronization Source (SSRC)
     4.9.  Generation of the RTCP Canonical Name (CNAME)
     4.10. Handling of Leap Seconds
   5.  WebRTC Use of RTP: Extensions
     5.1.  Conferencing Extensions and Topologies
       5.1.1.  Full Intra Request (FIR)
       5.1.2.  Picture Loss Indication (PLI)
       5.1.3.  Slice Loss Indication (SLI)
       5.1.4.  Reference Picture Selection Indication (RPSI)
       5.1.5.  Temporal-Spatial Trade-Off Request (TSTR)
       5.1.6.  Temporary Maximum Media Stream Bit Rate Request (TMMBR)
     5.2.  Header Extensions
       5.2.1.  Rapid Synchronization
       5.2.2.  Client-to-Mixer Audio Level
       5.2.3.  Mixer-to-Client Audio Level
       5.2.4.  Media Stream Identification
       5.2.5.  Coordination of Video Orientation
   6.  WebRTC Use of RTP: Improving Transport Robustness
     6.1.  Negative Acknowledgements and RTP Retransmission
     6.2.  Forward Error Correction (FEC)
   7.  WebRTC Use of RTP: Rate Control and Media Adaptation
     7.1.  Boundary Conditions and Circuit Breakers
     7.2.  Congestion Control Interoperability and Legacy Systems
   8.  WebRTC Use of RTP: Performance Monitoring
   9.  WebRTC Use of RTP: Future Extensions
   10. Signaling Considerations
   11. WebRTC API Considerations
   12. RTP Implementation Considerations
     12.1.  Configuration and Use of RTP Sessions
       12.1.1.  Use of Multiple Media Sources within an RTP Session
       12.1.2.  Use of Multiple RTP Sessions
       12.1.3.  Differentiated Treatment of RTP Streams
     12.2.  Media Source, RTP Streams, and Participant Identification
       12.2.1.  Media Source Identification
       12.2.2.  SSRC Collision Detection
       12.2.3.  Media Synchronization Context
   13. Security Considerations
   14. IANA Considerations
   15. References
     15.1.  Normative References
     15.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

okay so the Real-time Transport Protocol (RTP) [RFC3550] gives us a framework for delivering audio and video teleconferencing data and other real-time media apps 🎬 people have already defined the RTP protocol, plus tons of profiles, payload formats, and other extensions on top of it. combine those with the right signaling and boom, they become the foundation for a bunch of teleconferencing systems 🔥

then there's the Web Real-Time Communication (WebRTC) framework, which gives us the protocol building blocks for direct, interactive, real-time communication using audio, video, collaboration, games, etc., between two peers' web browsers 💖 this memo explains how the RTP framework is meant to be used in WebRTC. it proposes a baseline set of RTP features that every WebRTC endpoint is to implement, plus suggested extensions for extra functionality 🌸

this memo specifies a protocol meant for WebRTC, but it isn't locked to that context 🦋 you can get an overview of the WebRTC framework in [RFC8825].

here's how the doc is laid out 🗺️ Section 2 is our rationale for writing this memo and picking these RTP features. Section 3 defines terminology. the requirements for core RTP protocols are in Section 4, and the suggested RTP extensions are in Section 5. Section 6 covers mechanisms that boost robustness against network problems, and Section 7 describes congestion control and rate adaptation. the mandated RTP mechanisms wrap up in Section 8, which reviews performance monitoring and network management tools. Section 9 gives some guidelines for bringing other RTP and RTP Control Protocol (RTCP) extensions into this framework later. Section 10 describes the requirements placed on the signaling channel. Section 11 talks about how RTP framework features relate to the WebRTC application programming interface (API), and Section 12 covers RTP implementation considerations. the memo finishes with security considerations (Section 13) and IANA considerations (Section 14) 💅

2. Rationale 🌸

the RTP framework is made of the RTP data transfer protocol, the RTP control protocol, and a ton of RTP payload formats, profiles, and extensions 🧚 all those add-ons let RTP handle needs the original designers never imagined, and support lots of new media encodings. but it raises a real question: which extensions should new implementations support? ✨ the WebRTC framework gives us a chance to review the available RTP features and extensions, then define one common baseline RTP feature set for all WebRTC endpoints 👑 it builds on 20 years of RTP development. it mandates extensions that have proven widely useful, while still staying compatible with the huge installed base of RTP implementations wherever that's possible 🫶

RTP and RTCP extensions that aren't discussed in this document can still be implemented by WebRTC endpoints if they're useful for new use cases 💜 they aren't needed to address the WebRTC use cases and requirements identified in [RFC7478], though.

the baseline set of RTP features and extensions in this memo is aimed at WebRTC's requirements, but it's expected to be broadly useful for other conferencing-related uses of RTP 🎀 in particular, this set will probably be a good fit for other desktop or mobile video-conferencing systems, or for room-based high-quality telepresence apps 📹

3. Terminology 📖

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. lower- or mixed-case uses of these key words don't carry any special significance in this memo 🙈

we also define the following extra terms 🌈

WebRTC MediaStream: the MediaStream concept that the W3C defines in the WebRTC API [W3C.WD-mediacapture-streams]. a MediaStream is made up of zero or more MediaStreamTracks 🎞️
MediaStreamTrack: part of the MediaStream concept the W3C defines in the WebRTC API [W3C.WD-mediacapture-streams]. a MediaStreamTrack is one individual stream of media from any kind of media source, like a microphone or a camera. conceptual sources, like an audio mix or a video composition, are also possible 🎤
Transport-layer flow: a unidirectional flow of transport packets that are identified by one particular 5-tuple: source IP address, source port, destination IP address, destination port, and transport protocol 🛣️
Bidirectional transport-layer flow: a transport-layer flow that is symmetric. the transport-layer flow in the reverse direction has a 5-tuple where the source and destination address and ports are swapped compared to the forward path transport-layer flow, and the transport protocol is the same 🔁

this document uses the terminology from [RFC7656] and [RFC8825]. other terms follow their definitions from the RTP specification [RFC3550]. in particular, keep an eye on these frequently used terms: RTP stream, RTP session, and endpoint 👀

4. WebRTC Use of RTP: Core Protocols 💎

the following sections describe the core features of RTP and RTCP that need to be implemented, along with the mandated RTP profiles 💜 they also describe the core extensions that give all WebRTC endpoints the essential features they need to function well on today's networks 🌐

4.1. RTP and RTCP ✨

okay bestie, RTP is the Real-time Transport Protocol [RFC3550], and it is REQUIRED to be implemented as the media transport protocol for WebRTC 🎀. RTP has two parts: the data transfer protocol and the RTP Control Protocol (RTCP). RTCP is a fundamental, integral part of RTP, so it MUST be implemented and used in all WebRTC endpoints 💖

These RTP and RTCP features sometimes get skipped in limited-function implementations, but they are REQUIRED in every WebRTC endpoint 💅

Support for multiple simultaneous synchronization source (SSRC) values in a single RTP session, including endpoints that send many SSRC values at once, following [RFC3550] and [RFC8108]. The RTCP optimizations for multi-SSRC sessions defined in [RFC8861] MAY be supported. If they are supported, the usage MUST be signaled 🧚
Random choice of SSRC when joining a session, plus collision detection and resolution for SSRC values (see also Section 4.8) 🦋
Support for receiving RTP data packets that contain contributing source (CSRC) lists, as generated by RTP mixers, and for RTCP packets relating to CSRCs 🌸
Sending correct synchronization information in the RTCP Sender Reports, so receivers can do lip synchronization. See Section 5.2.1 for the rapid RTP synchronization extensions 👑
Support for multiple synchronization contexts. Participants sending multiple simultaneous RTP packet streams SHOULD do that as part of a single synchronization context, using one RTCP CNAME for all streams so receivers can play them out in sync ✨ Receivers MUST support multiple synchronization contexts, shown by using multiple RTCP CNAMEs in an RTP session, for future versions of this spec or for interop with non-WebRTC devices through a gateway 🫶 This spec does require a single CNAME when sending RTP streams in some circumstances. See Section 4.9 🍓
Support for sending and receiving RTCP Sender Report (SR), Receiver Report (RR), Source Description (SDES), and BYE packet types. Support for other RTCP packet types is OPTIONAL unless another part of this spec mandates it. Additional RTCP packet types are used by the RTP/SAVPF profile (Section 4.2) and the other RTCP extensions (Section 5) 💜 WebRTC endpoints that implement the Session Description Protocol (SDP) bundle negotiation extension will use the SDP Grouping Framework "mid" attribute to identify media streams. Those endpoints MUST implement the RTCP SDES media identification (MID) item described in [RFC8843] 🔥
Support for multiple endpoints in a single RTP session, and for scaling the RTCP transmission interval based on the number of participants. Support for randomized RTCP transmission intervals so reports don't sync up, and for RTCP timer reconsideration (Section 6.3.6 of [RFC3550]) and reverse reconsideration (Section 6.3.4 of [RFC3550]) 🌈
Support for configuring the RTCP bandwidth as a fraction of the media bandwidth, and for configuring the fraction of RTCP bandwidth given to senders. For example, using the SDP b= line [RFC4566] [RFC3556] 🎀
Support for the reduced minimum RTCP reporting interval described in Section 6.2 of [RFC3550]. When using the reduced minimum interval, the fixed (nonreduced) minimum interval MUST be used when calculating the participant timeout interval (see Sections 6.2 and 6.3.5 of [RFC3550]). The delay before sending the initial compound RTCP packet can be set to zero (see Section 6.2 of [RFC3550] as updated by [RFC8108]) ⭐
Support for discontinuous transmission. RTP lets endpoints pause and resume transmission at any time. When resuming, the RTP sequence number goes up by one as usual, while the RTP timestamp increase depends on how long the pause was. This is most common with some audio payload formats, but it isn't audio-specific and works with any RTP payload format 🦋
Ignore unknown RTCP packet types and RTP header extensions. This keeps things robust for future extensions, middlebox behaviors, and so on, which can lead to receiving RTP header extensions or RTCP packet types that were never signaled 🙈 If a compound RTCP packet has a mix of known and unknown packet types, the known types get processed as usual, and only the unknown ones get discarded 💅

It's known that a lot of legacy RTP implementations, especially ones built for Voice over IP (VoIP) only, don't support all of the above. Some don't support RTCP at all 💀 Implementers are advised to think about graceful degradation when interoperating with legacy implementations 🫶

Other implementation considerations are discussed in Section 12 🌸

4.2. Choice of the RTP Profile 🎀

An RTP profile has to be chosen before RTP can be fully specified for a given application domain. For WebRTC, the extended secure RTP profile for RTCP-based feedback (RTP/SAVPF) [RFC5124], as extended by [RFC7007], MUST be implemented. RTP/SAVPF combines the basic RTP/AVP profile [RFC3551], the RTP profile for RTCP-based feedback (RTP/AVPF) [RFC4585], and the secure RTP profile (RTP/SAVP) [RFC3711] 👑

The RTCP-based feedback extensions [RFC4585] are needed for the improved RTCP timer model. This lets RTCP packets go out in response to events, not just strictly according to bandwidth, which is vital for reporting congestion signals as well as media events 🔥 These extensions also save RTCP bandwidth. An endpoint will usually only use its full RTCP bandwidth allocation if there are lots of events needing feedback 🦋 The timer rules are also needed to use the RTP conferencing extensions discussed in Section 5.1 ✨

Note: The enhanced RTCP timer model defined in the RTP/AVPF profile is backwards compatible with legacy systems that implement only the RTP/AVP or RTP/SAVP profile, given some constraints on parameter configuration such as the RTCP bandwidth value and "trr-int". The most important factor for interworking with RTP/(S)AVP endpoints via a gateway is to set the "trr-int" parameter to a value representing 4 seconds; see Section 7.1.3 of [RFC8108].

The secure RTP (SRTP) profile extensions [RFC3711] are needed to provide media encryption, integrity protection, replay protection, and a limited form of source authentication 🔐 WebRTC endpoints MUST NOT send packets using the basic RTP/AVP profile or the RTP/AVPF profile. They MUST use the full RTP/SAVPF profile to protect all RTP and RTCP packets they generate 💖 In other words, 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 [RFC8827] 🌈

4.3. Choice of RTP Payload Formats 🧚

The mandatory-to-implement audio codecs and RTP payload formats for WebRTC endpoints are defined in [RFC7874]. The mandatory-to-implement video codecs and RTP payload formats are defined in [RFC7742] 🎀 WebRTC endpoints MAY also implement any other codec that has an RTP payload format and associated signaling defined ✨

WebRTC endpoints cannot assume the other participants in an RTP session understand any RTP payload format, no matter how common it is 🙈 The mapping between RTP payload type numbers and specific configurations of particular RTP payload formats MUST be agreed before those payload types or formats are used. In SDP, this can be done with the a=rtpmap: and a=fmtp: attributes attached to an m= line, plus any other SDP attributes needed to configure the payload format 💜

Endpoints can signal support for multiple RTP payload formats, or multiple configurations of one format, as long as each unique configuration uses a different RTP payload type number. As Section 4.8 explains, the RTP payload type number is sometimes used to link an RTP packet stream to a signaling context. That linking works as long as unique payload type numbers are used in each context 🍓 For example, an RTP packet stream can be linked to an SDP m= line by comparing the payload type numbers it uses with the payload types signaled in the a=rtpmap: lines of the media sections. That leads to these considerations:

If RTP packet streams are being associated with signaling contexts based on the RTP payload type, then the assignment of RTP payload type numbers MUST be unique across signaling contexts.

If the same RTP payload format configuration is used in multiple contexts, then a different RTP payload type number has to be assigned in each context to ensure uniqueness.

If the RTP payload type number is not being used to associate RTP packet streams with a signaling context, then the same RTP payload type number can be used to indicate the exact same RTP payload format configuration in multiple contexts.

A single RTP payload type number MUST NOT be assigned to different RTP payload formats, or to different configurations of the same format, within a single RTP session. (The m= lines in an SDP BUNDLE group [RFC8843] form a single RTP session, so keep that in mind 🌸)

An endpoint that has signaled support for multiple RTP payload formats MUST be able to accept data in any of them at any time, unless it has already signaled limits on its decoding capability 👑 This gets constrained when several types of media, like audio and video, are sent in the same RTP session. Then a source (SSRC) can only switch between the RTP payload formats signaled for the type of media that source is sending. See Section 4.4 🦋 To support rapid rate adaptation by changing codecs, RTP doesn't require advance signaling for changes between RTP payload formats used by a single SSRC, as long as those formats were signaled during session setup ✨

If you're switching between two RTP payload types that use different RTP clock rates, an RTP sender MUST follow the recommendations in Section 4.1 of [RFC7160]. RTP receivers MUST follow the recommendations in Section 4.3 of [RFC7160] so they can support sources that switch clock rates in an RTP session 🔥 These receiver recommendations are backwards compatible with senders that use only a single clock rate 🫶

4.4. Use of RTP Sessions 🎀

Okay so an RTP session is what you get when a set of endpoints are talking RTP to each other [RFC3550] 🦋. An endpoint can be in several RTP sessions at once, no cap. In a multimedia session, each media type usually gets its own RTP session, like one session for the audio and a separate one on a different transport-layer flow for the video 🌸. WebRTC endpoints are REQUIRED to do multimedia this way too, with each RTP session on its own transport-layer flow so it stays compatible with legacy systems. This is sometimes called session multiplexing 💅.

But ngl, NATs, NAPTs and firewalls are a whole mood now 🙈, so fewer transport-layer flows is way more desirable. You can send every RTP packet stream in one single RTP session, which means one transport-layer flow. The tradeoff is that this blocks some quality-of-service mechanisms (see Section 12.1.3) 💀. So implementations are also REQUIRED to support sending all RTP packet streams, no matter the media type, in a single RTP session on a single transport-layer flow, following [RFC8860]. This one's sometimes called SSRC multiplexing ✨. If you're putting multiple types of media in one RTP session, every participant in that session MUST agree to it 🫶. In SDP land, the mechanisms in [RFC8843] can signal that bundle of RTP packet streams as one RTP session.

If you want more on which session structures and multiplexing methods fit which scenarios, check out [RFC8872] 📚.

4.5. RTP and RTCP Multiplexing 🌈

Historically, RTP and RTCP ran on separate transport-layer flows, like two UDP ports per RTP session, one for RTP and one for RTCP 😭. With NAT/NAPT everywhere, that got messy, because keeping multiple NAT bindings alive is pricey and firewall admins had to open multiple ports just for RTP traffic. To cut those costs and speed up session setup, implementations are REQUIRED to support multiplexing RTP data packets and RTCP control packets on a single transport-layer flow [RFC5761]. This RTP and RTCP multiplexing MUST be negotiated in the signaling channel before it's used. If SDP is your signaling, that negotiation MUST use the mechanism defined in [RFC5761]. Implementations can also support sending RTP and RTCP on separate transport-layer flows, but this is OPTIONAL to implement 🍓. If an implementation doesn't support RTP and RTCP on separate flows, it MUST indicate that using the mechanism defined in [RFC8858].

Note that RTP and RTCP on one flow means there's occasional traffic on that port even when there's no active media traffic 🧚. That can be useful for keeping NAT bindings alive [RFC6263].

4.6. Reduced Size RTCP 💜

RTCP packets are usually sent as compound RTCP packets, and [RFC3550] requires those compound packets to start with an SR or RR packet. When you're sending frequent RTCP feedback messages under the RTP/AVPF profile [RFC4585], those stats aren't needed in every packet, and they unnecessarily bloat the mean RTCP packet size. That can limit how often RTCP packets can go out within the RTCP bandwidth share 😤.

To fix that, [RFC5506] specifies how to reduce the mean RTCP message size and allow for more frequent feedback. Frequent feedback matters because it's essential for real-time apps to quickly notice changing network conditions and adapt their transmission and encoding behavior 👑. Implementations MUST support sending and receiving noncompound RTCP feedback packets [RFC5506]. Use of noncompound RTCP packets MUST be negotiated using the signaling channel. If SDP is used for signaling, this negotiation MUST use the attributes defined in [RFC5506]. For backwards compatibility, implementations are also REQUIRED to support the use of compound RTCP feedback packets if the remote endpoint doesn't agree to noncompound RTCP in the signaling exchange 🫠.

4.7. Symmetric RTP/RTCP 🔥

To ease traversal of NAT and firewall devices, implementations are REQUIRED to implement and use symmetric RTP [RFC4961]. The whole point is to avoid NAT and firewall drama by making sure the send and receive RTP packet streams, plus RTCP, are actually bidirectional transport-layer flows. That keeps the NAT and firewall pinholes alive and helps indicate consent that the receive direction is a transport-layer flow the intended recipient actually wants 🦋. Bonus: you save ports at the endpoints, and in the network too, since the NAT mappings or firewall state don't get unnecessarily bloated, and there's less per-flow QoS state kept in the network 🌸.

4.8. Choice of RTP Synchronization Source (SSRC) 🧩

Implementations are REQUIRED to support signaled RTP synchronization source (SSRC) identifiers. If SDP is used, this MUST be done using the "a=ssrc:" SDP attribute defined in Sections 4.1 and 5 of [RFC5576] and the "previous-ssrc" source attribute defined in Section 6.2 of [RFC5576]; other per-SSRC attributes defined in [RFC5576] MAY be supported.

While support for signaled SSRC identifiers is mandated, their use in an RTP session is OPTIONAL 🎯. Implementations MUST be prepared to accept RTP and RTCP packets using SSRCs that have not been explicitly signaled ahead of time. Implementations MUST support random SSRC assignment and MUST support SSRC collision detection and resolution, according to [RFC3550]. When using signaled SSRC values, collision detection MUST be performed as described in Section 5 of [RFC5576].

It's often desirable to link an RTP packet stream to a non-RTP context 🔗. For users of the WebRTC API, a mapping between SSRCs and MediaStreamTracks is provided per Section 11. For gateways or other usages, you can associate an RTP packet stream with an "m=" line in a session description formatted using SDP. If SSRCs are signaled, this is super straightforward (in SDP, the "a=ssrc:" line is at the media level, so it lets you directly associate with an "m=" line). If SSRCs aren't signaled, the RTP payload type numbers used in an RTP packet stream are often enough to associate that stream with a signaling context 🧠. For example, if RTP payload type numbers are assigned as described in Section 4.3 of this memo, the RTP payload types used by an RTP packet stream can be compared with values in SDP "a=rtpmap:" lines, which are at the media level in SDP and so map to an "m=" line 💖.

4.9. Generation of the RTCP Canonical Name (CNAME) 🪪

The RTCP Canonical Name (CNAME) provides a persistent transport-level identifier for an RTP endpoint 🌟. The SSRC can change if a collision is detected or when the RTP application restarts, but the RTCP CNAME is meant to stay unchanged for the duration of an RTCPeerConnection [W3C.WebRTC], so RTP endpoints can be uniquely identified and associated with their RTP packet streams within a set of related RTP sessions.

Each RTP endpoint MUST have at least one RTCP CNAME, and that RTCP CNAME MUST be unique within the RTCPeerConnection. RTCP CNAMEs identify a particular synchronization context, meaning all SSRCs associated with a single RTCP CNAME share a common reference clock 🕰️. If an endpoint has SSRCs associated with several unsynchronized reference clocks, and hence different synchronization contexts, it will need multiple RTCP CNAMEs, one for each synchronization context.

Taking the discussion in Section 11 into account, a WebRTC endpoint MUST NOT use more than one RTCP CNAME in the RTP sessions belonging to a single RTCPeerConnection (so an RTCPeerConnection forms a synchronization context) 👑. RTP middleboxes MAY generate RTP packet streams associated with more than one RTCP CNAME, so they can avoid having to resynchronize media from multiple different endpoints that are part of a multiparty RTP session 🙌.

The RTP specification [RFC3550] includes guidelines for choosing a unique RTP CNAME, but those aren't sufficient in the presence of NAT devices 🙈. Long-term persistent identifiers can also be problematic from a privacy viewpoint (Section 13). So a WebRTC endpoint MUST generate a new, unique, short-term persistent RTCP CNAME for each RTCPeerConnection, following [RFC7022], with a single exception: if explicitly requested at creation, an RTCPeerConnection MAY use the same CNAME as an existing RTCPeerConnection within their common same-origin context 🔐.

A WebRTC endpoint MUST support reception of any CNAME that matches the syntax limitations specified by the RTP specification [RFC3550], and it can't assume that any CNAME will be chosen according to the form suggested above 🫶.

4.10. Handling of Leap Seconds ⏱️

The guidelines given in [RFC7164] regarding handling of leap seconds to limit their impact on RTP media play-out and synchronization SHOULD be followed 🕰️.

5. WebRTC Use of RTP: Extensions ✨

There are a number of RTP extensions that are either needed to obtain full functionality, or extremely useful for improving baseline performance in the WebRTC context 🎀. One set of these is related to conferencing, while others are more generic in nature. The subsections that follow describe the various RTP extensions mandated or suggested for use within WebRTC 💅.

5.1. Conferencing Extensions and Topologies 📞✨

Okay bestie, RTP is literally built for group calls 🫶. You can set up a group by having every endpoint send its RTP packet streams to an RTP middlebox that redistributes the traffic, by making a mesh of unicast RTP packet streams between endpoints, or by using an IP multicast group to distribute the streams. Each of these can be built a bunch of different ways, all covered in [RFC7667] 🧚

IP multicast is super popular in IPTV systems, but middlebox topologies are the main character in interactive video-conferencing 💅. Meshes built from unicast transport-layer flows that share one RTP session haven't really caught on yet. So WebRTC endpoints are not expected to support IP multicast topologies or mesh-based topologies, like a point-to-multipoint mesh configured as a single RTP session ("Topo-Mesh" in the terminology of [RFC7667]). BUT a point-to-multipoint mesh built from several RTP sessions, implemented in WebRTC using independent RTCPeerConnections [W3C.WebRTC], can be expected to be used in WebRTC and needs to be supported 🦋

WebRTC endpoints that follow this memo are expected to support all the topologies in [RFC7667] where the RTP endpoints send and receive unicast RTP packet streams to and from some peer device, as long as that peer can take part in performing congestion control on those streams 🔥. The peer could be another RTP endpoint, or an RTP middlebox that redistributes the streams to other RTP endpoints. This means some of the RTP middlebox topologies just aren't suitable for WebRTC 🙈 Specifically:

Video-switching Multipoint Control Units (MCUs) (Topo-Video-switch-MCU) SHOULD NOT be used, since they make the use of RTCP for congestion control and quality-of-service reports problematic (see Section 3.8 of [RFC7667]) 💀
The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology SHOULD NOT be used, because its safe use requires a congestion control algorithm or RTP circuit breaker that handles point to multipoint, which has not yet been standardized 😭

The following topology can be used, however it has some issues worth noting 👀

Content-modifying MCUs with RTCP termination (Topo-RTCP-terminating-MCU) MAY be used. Note that in this RTP topology, RTP loop detection and identification of active senders is the responsibility of the WebRTC application. Since the clients are isolated from each other at the RTP layer, RTP cannot assist with these functions (see Section 3.9 of [RFC7667]) 🌸

The RTP extensions described in Sections 5.1.1 to 5.1.6 are designed to be used with centralized conferencing, where an RTP middlebox (e.g., a conference bridge) receives a participant's RTP packet streams and distributes them to the other participants 🎀. These extensions are not necessary for interoperability. An RTP endpoint that doesn't implement them will still work correctly, but it might offer poor performance. Supporting them will greatly improve the quality of experience, so to give a reasonable baseline quality, some of these extensions are mandatory to be supported by WebRTC endpoints ✨

The RTCP conferencing extensions are defined in "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585] and "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)" [RFC5104]. They're fully usable by the secure variant of this profile (RTP/SAVPF) [RFC5124] 🔐💜

5.1.1. Full Intra Request (FIR) 🎬

The Full Intra Request message is defined in Sections 3.5.1 and 4.3.1 of Codec Control Messages [RFC5104]. It's used to make the mixer request a new Intra picture from a participant in the session. This happens when switching between sources, so that receivers can decode video or other predictive media encoding with long prediction chains 🧠. WebRTC endpoints that are sending media MUST understand and react to FIR feedback messages they receive, because this greatly improves the user experience in centralized mixer-based conferencing 🙌. Support for sending FIR messages is OPTIONAL.

5.1.2. Picture Loss Indication (PLI) 🖼️

The Picture Loss Indication message is defined in Section 6.3.1 of the RTP/AVPF profile [RFC4585]. A receiver uses it to tell the sending encoder that it lost the decoder context and would like it repaired somehow 🛠️ This is semantically different from the Full Intra Request above, since there could be multiple ways to fulfill the request. WebRTC endpoints that are sending media MUST understand and react to PLI feedback messages as a loss-tolerance mechanism. Receivers MAY send PLI messages 💖

5.1.3. Slice Loss Indication (SLI) 🍰

The Slice Loss Indication message is defined in Section 6.3.2 of the RTP/AVPF profile [RFC4585]. A receiver uses it to tell the encoder that it has detected the loss or corruption of one or more consecutive macro blocks, and would like those repaired somehow 🧩 It is RECOMMENDED that receivers generate SLI feedback messages if slices are lost when using a codec that supports the concept of macro blocks. A sender that receives an SLI feedback message SHOULD attempt to repair the lost slice(s) 🔧

5.1.4. Reference Picture Selection Indication (RPSI) 🖍️

Reference Picture Selection Indication (RPSI) messages are defined in Section 6.3.3 of the RTP/AVPF profile [RFC4585]. Some video-encoding standards let you use older reference pictures than the most recent one for predictive coding 🕰️ If that kind of codec is in use, and the encoder has learned that encoder-decoder synchronization has been lost, then a known-as-correct reference picture can be used as the base for future coding. The RPSI message is how that gets signaled 📣 Receivers that detect that encoder-decoder synchronization has been lost SHOULD generate an RPSI feedback message if the codec being used supports reference-picture selection. An RTP packet-stream sender that receives such an RPSI message SHOULD act on it to change the reference picture, if it's possible to do so within the available bandwidth constraints and with the codec being used 🦋

5.1.5. Temporal-Spatial Trade-Off Request (TSTR) ⚖️

The temporal-spatial trade-off request and notification are defined in Sections 3.5.2 and 4.3.2 of [RFC5104]. This request can ask the video encoder to change the trade-off it makes between temporal and spatial resolution, for example to prefer high spatial image quality but a low frame rate 🎞️ Support for TSTR requests and notifications is OPTIONAL.

5.1.6. Temporary Maximum Media Stream Bit Rate Request (TMMBR) 📶

The Temporary Maximum Media Stream Bit Rate Request (TMMBR) feedback message is defined in Sections 3.5.4 and 4.2.1 of Codec Control Messages [RFC5104]. This request, and its corresponding Temporary Maximum Media Stream Bit Rate Notification (TMMBN) message [RFC5104], are used by a media receiver to tell the sending party that there's a current limit on how much bandwidth is available to this receiver 🚦 There can be various reasons for this. For example, an RTP mixer can use this message to limit the media rate of a sender being forwarded by the mixer (without doing media transcoding) so it fits the bottlenecks towards the other session participants. WebRTC endpoints that are sending media are REQUIRED to implement support for TMMBR messages and MUST follow bandwidth limitations set by a TMMBR message received for their SSRC. The sending of TMMBR messages is OPTIONAL 💜

5.2. Header Extensions 🧩

The RTP specification [RFC3550] lets you include RTP header extensions containing in-band data, but the format and semantics of those extensions are poorly specified 😩 The use of header extensions is OPTIONAL in WebRTC. But if they are used, they MUST be formatted and signaled following the general mechanism for RTP header extensions defined in [RFC8285], since that gives RTP header extensions well-defined semantics 🎀

As noted in [RFC8285], the requirement from the RTP specification that header extensions are "designed so that the header extension may be ignored" [RFC3550] still stands ✨. To be specific, header extensions MUST only be used for data that can safely be ignored by the recipient without affecting interoperability. They MUST NOT be used when the presence of the extension has changed the form or nature of the rest of the packet in a way that isn't compatible with how the stream is signaled (e.g., as defined by the payload type) 🚫. Valid examples of RTP header extensions might include metadata that's additional to the usual RTP information, but that can safely be ignored without compromising interoperability 🌈

5.2.1. Rapid Synchronization ⚡

Many RTP sessions need synchronization between audio, video, and other content. This synchronization is performed by receivers, using information in RTCP SR packets, as described in the RTP specification [RFC3550]. This basic mechanism can be slow, though, so it is RECOMMENDED that the rapid RTP synchronization extensions described in [RFC6051] be implemented in addition to RTCP SR-based synchronization 🏃‍♀️

This header extension uses the generic header extension framework described in [RFC8285], so it needs to be negotiated before it can be used 🤝

5.2.2. Client-to-Mixer Audio Level 🔊

The client-to-mixer audio level extension [RFC6464] is an RTP header extension that an endpoint uses to tell a mixer how much audio activity is in the packet the header is attached to 🎙️ This lets an RTP middlebox make mixing or selection decisions without decoding or detailed inspection of the payload, which cuts down complexity in some types of mixers. It can also save decoding resources in receivers, who can choose to decode only the most relevant RTP packet streams based on audio activity levels 🧃

The client-to-mixer audio level header extension [RFC6464] MUST be implemented. It is REQUIRED that implementations be capable of encrypting the header extension according to [RFC6904], since the information in these header extensions can be considered sensitive 🔒 The use of this encryption is RECOMMENDED. However, usage of the encryption can be explicitly disabled through API or signaling 💅

This header extension uses the generic header extension framework described in [RFC8285], so it needs to be negotiated before it can be used 🫶

5.2.3. Mixer-to-Client Audio Level ✨

okay so the mixer-to-client audio level header extension [RFC6465] tells an endpoint how loud each source is that an RTP mixer blended into one common source stream 🎚️ 🗣️. That's the magic bit, bestie, because a UI can show who's actually talking instead of just whether someone's CSRC shows up or not 👀✨. This is a pure optimization of non-critical functions and is hence OPTIONAL to implement 💅. If you DO implement it, it is REQUIRED that implementations be capable of encrypting the header extension according to [RFC6904], because the info in these header extensions can be considered sensitive 🔒😭. It is further RECOMMENDED that this encryption be used, unless it has been explicitly disabled through API or signaling 🫶.

This header extension uses the generic header extension framework described in [RFC8285], so it needs to be negotiated before anyone can use it 🎀.

5.2.4. Media Stream Identification 🦋

WebRTC endpoints that implement the SDP bundle negotiation extension will use the SDP Grouping Framework "mid" attribute to identify media streams 🧚. Such endpoints MUST implement the RTP MID header extension described in [RFC8843] 💖.

This header extension uses the generic header extension framework described in [RFC8285], so it needs to be negotiated before it can be used 🌸.

5.2.5. Coordination of Video Orientation 📸

WebRTC endpoints that send or receive video MUST implement the coordination of video orientation (CVO) RTP header extension as described in Section 4 of [RFC7742] 🍓✨. Video that knows which way is up? Iconic 👑.

This header extension uses the generic header extension framework described in [RFC8285], so it needs to be negotiated before it can be used 🫶.

6. WebRTC Use of RTP: Improving Transport Robustness 🛡️✨

There are tools that can make RTP packet streams robust against packet loss and reduce how much loss hurts media quality 🩹. BUT (and this is a big but 😭) they usually add some overhead compared to a non-robust stream. You have to account for that overhead, and the aggregate bitrate MUST be rate controlled so it doesn't cause network congestion (see Section 7) 🚦. So improving robustness might mean a lower base encoding quality, but it has the potential to deliver that quality with fewer errors 💅. The mechanisms in the following subsections can help improve tolerance to packet loss 🌈.

6.1. Negative Acknowledgements and RTP Retransmission 🔁

Okay, so this is giving feedback loop energy 💜. As a consequence of supporting the RTP/SAVPF profile, implementations can send negative acknowledgements (NACKs) for RTP data packets [RFC4585] 📨. This feedback tells a sender which RTP packets got lost, subject to the capacity limits of the RTCP feedback channel 📉. A sender can use that info to level up the user experience by adapting the media encoding to compensate for known lost packets 🧠✨.

RTP packet stream senders are REQUIRED to understand the generic NACK message defined in Section 6.2.1 of [RFC4585], but they MAY choose to ignore some or all of this feedback (following Section 4.2 of [RFC4585]) 🙈. Receivers MAY send NACKs for missing RTP packets 🍓. There are guidelines on when to send NACKs in [RFC4585]. It is not expected that a receiver will send a NACK for every lost RTP packet 💀. Instead, it needs to weigh the cost of sending NACK feedback against how important the lost packet is, so it can make an informed decision about whether telling the sender about a packet-loss event is worth it 🧐💖.

The RTP retransmission payload format [RFC4588] offers the ability to retransmit lost packets based on NACK feedback 🔄. Retransmission needs to be used with care in interactive real-time apps, so the retransmitted packet arrives in time to be useful. It can be super effective in environments with relatively low network RTT ⚡. (An RTP sender can estimate the RTT to the receivers using the information in RTCP SR and RR packets, as described at the end of Section 6.4.1 of [RFC3550] 🧮.) Retransmissions can also increase the forward RTP bandwidth, and they can potentially cause increased packet loss if the original loss was caused by network congestion 😬. Also, retransmitting an important lost packet to repair decoder state can cost less than sending a full intra frame 🧠✨. It is not appropriate to blindly retransmit RTP packets in response to a NACK 🚫. The importance of lost packets and the likelihood of them arriving in time to be useful both need to be considered before RTP retransmission is used 🫶.

Receivers are REQUIRED to implement support for RTP retransmission packets [RFC4588] sent using SSRC multiplexing, and they MAY also support RTP retransmission packets sent using session multiplexing 🎀. Senders MAY send RTP retransmission packets in response to NACKs, if support for the RTP retransmission payload format has been negotiated and the sender believes it's useful to resend the packet(s) referenced in the NACK 🌸. Senders do not need to retransmit every NACKed packet 💅.

6.2. Forward Error Correction (FEC) 🧩

Forward Error Correction (FEC) can provide effective protection against some degree of packet loss, at the cost of steady bandwidth overhead 🛡️. There are several FEC schemes defined for use with RTP 🧠. Some are specific to a particular RTP payload format, and others operate across RTP packets and can be used with any payload format 🌈. Heads up though: using redundant encoding or FEC leads to increased play-out delay, which needs to be considered when choosing FEC schemes and their parameters ⏳😭.

WebRTC endpoints MUST follow the recommendations for FEC use given in [RFC8854] 📜✨. WebRTC endpoints MAY support other types of FEC, but these MUST be negotiated before they are used 🤝💜.

7. WebRTC Use of RTP: Rate Control and Media Adaptation 🌊🦋

WebRTC is going to be used in heterogeneous network environments, with a variety of link technologies, both wired and wireless, to connect potentially large groups of users all over the world 🌍✨. So the network paths between users can have wildly different one-way delays, available bitrates, load levels, and traffic mixtures 🎢. Individual endpoints can send one or more RTP packet streams to each participant, and there can be several participants 👯‍♀️. Each stream can carry different types of media, and the media type, bitrate, and number of RTP packet streams, plus transport-layer flows, can be highly asymmetric 📊. Non-RTP traffic can share the network paths with RTP transport-layer flows too 🚗. Since the network environment is neither predictable nor stable, WebRTC endpoints MUST ensure that the RTP traffic they generate can adapt to match changes in the available network capacity 🫶💖.

The quality of experience for WebRTC users depends a LOT on how well media adapts to the network's limits 🥹. Endpoints have to be designed so they don't transmit significantly more data than the network path can support, except for very short time periods. Otherwise, high levels of packet loss or delay spikes will happen, and the media quality takes a hit 📉💀. The limiting factor on the network path's capacity might be the link bandwidth, or it might be competition with other traffic on the link. That competition can be non-WebRTC traffic, traffic from other WebRTC flows, or even other WebRTC flows in the same session 🙃.

So an effective media congestion control algorithm is an essential part of the WebRTC framework 🔑✨. Unfortunately, at the time of this writing, there is no standard congestion control algorithm that can be used for interactive media applications like WebRTC's flows 😭. Some requirements for congestion control algorithms for RTCPeerConnections are discussed in [RFC8836] 📝. If a standardized congestion control algorithm that satisfies these requirements is developed in the future, this memo will need to be updated to mandate its use 🔮.

7.1. Boundary Conditions and Circuit Breakers 🚨⚡

WebRTC endpoints MUST implement the RTP circuit breaker algorithm described in [RFC8083] 🔌. The RTP circuit breaker is designed to help applications recognize and react to situations of extreme network congestion 🧯. But the circuit breaker might not trigger until congestion gets extreme, so it can't be a substitute for congestion control 🙅‍♀️. That's why applications MUST also implement congestion control, so they can adapt to changes in network capacity 💅. The congestion control algorithm will have to be proprietary until a standardized one is available. Any future RTP congestion control algorithms are expected to operate within the envelope allowed by the circuit breaker 🌸.

Session-establishment signaling also necessarily sets boundaries that the media bitrate has to conform to 📏. The codec choice provides upper and lower bounds on the supported bitrates the app can use to deliver useful quality, along with the packetization options that exist 🎞️. The signaling channel can also set maximum media bitrate boundaries using, for example, the SDP b=AS: or b=CT: lines and the RTP/AVPF TMMBR messages (see Section 5.1.6 of this memo) 🧾✨. 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 bandwidth limitations 💜. These limitations have to be based on known bandwidth limits, like the capacity of the edge links 🌈.

7.2. Congestion Control Interoperability and Legacy Systems 🦋

okay so every endpoint that wants to interwork with WebRTC MUST implement RTCP and provide congestion feedback through the defined RTCP reporting mechanisms. no skipping this bestie 💅

when you're interworking with legacy stuff that does RTCP using the RTP/AVP profile [RFC3551], congestion feedback shows up in RTCP RR packets every few seconds. implementations that have to talk to those endpoints MUST ensure they keep within the RTP circuit breaker [RFC8083] constraints, so they don't cause too much congestion 🙈

if a legacy endpoint supports RTP/AVPF, that unlocks negotiation of important parameters for frequent reporting, like the trr-int parameter, plus the chance that the endpoint supports a useful feedback format for congestion control, such as TMMBR [RFC5104]. implementations that have to interwork with those endpoints MUST stay within the RTP circuit breaker [RFC8083] constraints to limit the congestion they can cause, but they might find they get better congestion response depending on how much feedback is available ✨

with proprietary congestion control algorithms, things can get messy fr fr. when different implementations pick different types of adaptation, like one sender based and one receiver based, one direction can end up dual controlled while the other direction isn't controlled at all 😭 this memo cannot mandate behavior for proprietary congestion control algorithms, but implementations that use them ought to be aware of this issue and try to make sure effective congestion control is negotiated for media flowing in both directions. and if the IETF ever standardizes both sender- and receiver-based congestion control algorithms for WebRTC traffic, interoperability, control, and making sure both directions of media are congestion controlled would also need to be considered 👑

8. WebRTC Use of RTP: Performance Monitoring 📊✨

as described in Section 4.1, implementations are REQUIRED to generate RTCP Sender Report (SR) and Receiver Report (RR) packets for the RTP packet streams they send and receive. these reports can be used for performance monitoring, since they include basic packet-loss and jitter statistics 🎀

there's a whole bunch of extra performance metrics supported by the RTCP Extended Reports (XR) framework; see [RFC3611] and [RFC6792]. at the time of writing, it's not clear which extended metrics are suitable for WebRTC, so there is no requirement that implementations generate RTCP XR packets. however, implementations that can use detailed performance monitoring data MAY generate RTCP XR packets as appropriate. the use of RTCP XR packets SHOULD be signaled, and implementations MUST ignore RTCP XR packets that are unexpected or not understood 🧚

9. WebRTC Use of RTP: Future Extensions 🔮

it's possible the core set of RTP protocols and RTP extensions in this memo will prove insufficient for WebRTC's future needs. if that happens, future updates to this memo have to be made following "Guidelines for Writers of RTP Payload Format Specifications" [RFC2736], "How to Write an RTP Payload Format" [RFC8088], and "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968]. they also SHOULD take into account any future guidelines for extending RTP and related protocols that have been developed 🌈

authors of future extensions are urged to think about the wide range of environments RTP gets used in, since an extension that works great in some scenarios can be problematic in others. where possible, the WebRTC framework will adopt RTP extensions of general utility, so it's easy to build a gateway to other applications using RTP, rather than adopting mechanisms narrowly targeted at specific WebRTC use cases. main character energy for the whole ecosystem 💜

10. Signaling Considerations 💌

okay so RTP is built on the assumption that an external signaling channel exists and can be used to configure RTP sessions and their features. the basic configuration of an RTP session has these parameters:

RTP profile: the name of the RTP profile used in the session. the RTP/AVP [RFC3551] and RTP/AVPF [RFC4585] profiles can interoperate on a basic level, and so can their secure variants, RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124]. the secure variants do not directly interoperate with the nonsecure ones, because SRTP packets have extra header fields for authentication and the payload gets cryptographic transformation. WebRTC requires the use of the RTP/SAVPF profile, and this MUST be signaled. interworking functions might transform this into the RTP/SAVP profile for a legacy use case by telling the WebRTC endpoint that RTP/SAVPF is used and configuring a trr-int value of 4 seconds 🦋
Transport information: source and destination IP address(es) and ports for RTP and RTCP MUST be signaled for each RTP session. in WebRTC, these transport addresses come from Interactive Connectivity Establishment (ICE) [RFC8445], which signals candidates and arrives at nominated candidate address pairs. if RTP and RTCP multiplexing [RFC5761] is used so that a single port (i.e., transport-layer flow) carries both RTP and RTCP flows, this MUST be signaled (see Section 4.5) 🌸
RTP payload types, media formats, and format parameters: the mapping between media type names (and therefore the RTP payload formats to be used) and the RTP payload type numbers MUST be signaled. each media type MAY also have a number of media type parameters, and these MUST also be signaled to configure the codec and RTP payload format (the a=fmtp: line from SDP). Section 4.3 of this memo discusses requirements for uniqueness of payload types 🍓
RTP extensions: the use of any additional RTP header extensions and RTCP packet types, including any necessary parameters, MUST be signaled. this signaling makes sure a WebRTC endpoint's behavior, especially when sending, is predictable and consistent. for robustness and compatibility with non-WebRTC systems that might be connected to a WebRTC session via a gateway, implementations are REQUIRED to ignore unknown RTCP packets and RTP header extensions (see also Section 4.1) 🫶
RTCP bandwidth: support for exchanging RTCP bandwidth values with the endpoints will be necessary. this SHALL be done as described in "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or something semantically equivalent. this also makes sure the endpoints have a common view of the RTCP bandwidth. a common view is important, because differences in RTCP packet timing and timeout intervals could cause interoperability problems 💀

these parameters are often expressed in SDP messages conveyed within an offer/answer exchange. RTP doesn't depend on SDP or the offer/answer model, but it does require all the necessary parameters to be agreed upon and provided to the RTP implementation. note that in WebRTC, how these parameters need to be configured depends on the signaling model and API. they'll need to either be set in the API or explicitly signaled between the peers ✨

11. WebRTC API Considerations ✨

okay so the WebRTC API [W3C.WebRTC] and the Media Capture and Streams API [W3C.WD-mediacapture-streams] both use a concept called a MediaStream, which holds zero or more MediaStreamTracks 🎀. A MediaStreamTrack is one individual stream of media from any kind of source, like a microphone or a camera. Conceptual sources work too, like an audio mix or a video composition 🎶. The MediaStreamTracks inside one MediaStream might need to stay in sync during playback 👯‍♀️.

A MediaStreamTrack shows up in RTP (inside an RTCPeerConnection) as a source packet stream, which is identified by an SSRC and sent within an RTP session that belongs to the RTCPeerConnection 🦋. One track can also create extra packet streams, and therefore extra SSRCs, in that same RTP session. These can be dependent packet streams from scalable encoding of the source stream, if a scalable media encoder is being used 🧚. They can also be redundancy packet streams, which get created when Forward Error Correction (Section 6.2) or RTP retransmission (Section 6.1) is applied to the source packet stream 🛡️.

It is important to note that the same media source can feed multiple MediaStreamTracks 💅. Different sets of constraints or other parameters can be applied to each MediaStreamTrack, so each MediaStreamTrack instance added to an RTCPeerConnection SHALL result in an independent source packet stream with its own set of associated packet streams and therefore different SSRC(s). Whether the source stream and the encoding configuration end up identical between MediaStreamTracks sharing the same media source depends on the constraints and parameters that were applied. If the encoding parameters and constraints are the same, an implementation could choose to use only one encoded stream to create the different RTP packet streams. Be careful though, because such optimizations need to account for the fact that the constraints for one of the MediaStreamTracks can change at any moment. The encoding configurations might then no longer be identical, and two different encoder instances would be needed 😬.

The same MediaStreamTrack can also be included in multiple MediaStreams, so several sets of MediaStreams can implicitly need to use the same synchronization base 🌈. To make sure this works in every case, and that an endpoint never has to disrupt media by changing its synchronization base and CNAME while packet streams are being delivered, all MediaStreamTracks and their associated SSRCs originating from the same endpoint need to be sent using the same CNAME within one RTCPeerConnection. This is what motivates the use of a single CNAME in Section 4.9 💖.

The requirement to use the same CNAME for all SSRCs that originate from the same endpoint does not require a middlebox that forwards traffic from multiple endpoints to only use a single CNAME.

Different CNAMEs normally need to be used for different RTCPeerConnection instances, as specified in Section 4.9 🔐. Having two communication sessions with the same CNAME could enable tracking of a user or device across different services (see Section 4.4.1 of [RFC8826] for details). A web application can request that the CNAMEs used in different RTCPeerConnections (within a same-origin context) be the same. This allows the endpoint's RTP packet streams to be synchronized across those different RTCPeerConnections ✨.

Note: This doesn't result in a tracking issue, since the creation of matching CNAMEs depends on existing tracking within a single origin.

Right now, the above forces a WebRTC endpoint that receives a MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing track on any RTCPeerConnection to perform resynchronization of the stream 🔄. Since the sending party has to change the CNAME to the one it uses, it has to use a local system clock as the timebase for the synchronization ⏰. That means the relative relation between the timebase of the incoming stream and the timebase of the system sending out needs to be defined. This relation also needs monitoring for clock drift and likely adjustments of the synchronization. The sending entity is also responsible for congestion control for its sent streams 🚦. In cases of packet loss, the loss of incoming data also needs to be handled 🙈.

So the method that is least likely to cause issues or interruptions in the outgoing source packet stream is a model of full decoding, including repair, followed by encoding of the media again into the outgoing packet stream 👑. Optimizations of this method are clearly possible and implementation specific 💜.

A WebRTC endpoint MUST support receiving multiple MediaStreamTracks, where each of the different MediaStreamTracks (and its sets of associated packet streams) uses different CNAMEs 🎀. However, MediaStreamTracks that are received with different CNAMEs have no defined synchronization 😭.

Note: The motivation for supporting reception of multiple CNAMEs is to allow for forward compatibility with any future changes that enable more efficient stream handling when endpoints relay/forward streams. It also ensures that endpoints can interoperate with certain types of multistream middleboxes or endpoints that are not WebRTC.

"JavaScript Session Establishment Protocol (JSEP)" [RFC8829] specifies that the binding between the WebRTC MediaStreams, MediaStreamTracks, and the SSRC is done as specified in "WebRTC MediaStream Identification in the Session Description Protocol" [RFC8830] 🔗. Section 4.1 of the MediaStream Identification (MSID) document [RFC8830] also defines how to map source packet streams with unknown SSRCs to MediaStreamTracks and MediaStreams. This later part is relevant for handling some cases of legacy interoperability 🕰️. Commonly, the RTP payload type of any incoming packets reveals whether the packet stream is a source stream or a redundancy or dependent packet stream. The association to the correct source packet stream depends on the payload format in use for the packet stream 🧩.

Finally, this specification puts a requirement on the WebRTC API to realize a method for determining the CSRC list (Section 4.1) as well as the mixer-to-client audio levels (Section 5.2.3) (when supported). The basic requirements for this are further discussed in Section 12.2.1 📋.

12. RTP Implementation Considerations

The following discussion gives some guidance on implementing the RTP features described in this memo 🛠️. The focus is on a WebRTC endpoint implementation perspective. While some mention is made of the behavior of middleboxes, that is not the focus of this memo 🙃.

12.1. Configuration and Use of RTP Sessions

A WebRTC endpoint will be a simultaneous participant in one or more RTP sessions 🌸. Each RTP session can convey multiple media sources and include media data from multiple endpoints. Below, we outline some ways in which WebRTC endpoints can configure and use RTP sessions 📝.

12.1.1. Use of Multiple Media Sources within an RTP Session

RTP is a group communication protocol, and every RTP session can potentially contain multiple RTP packet streams 👯. There are several reasons why this might be desirable:

Multiple media types:

Outside of WebRTC, it is common to use one RTP session for each type of media source (e.g., one RTP session for audio sources and one for video sources, each sent over different transport-layer flows) 📞. However, to reduce the number of UDP ports used, the default in WebRTC is to send all types of media in a single RTP session, as described in Section 4.4, using RTP and RTCP multiplexing (Section 4.5) to further reduce the number of UDP ports needed 🔌. This RTP session then uses only one bidirectional transport-layer flow but will contain multiple RTP packet streams, each containing a different type of media. A common example might be an endpoint with a camera and microphone that sends two RTP packet streams, one video and one audio, into a single RTP session 🎥🎙️.

Multiple capture devices:

A WebRTC endpoint might have multiple cameras, microphones, or other media capture devices, so it might want to generate several RTP packet streams of the same media type 📷. Alternatively, it might want to send media from a single capture device in several different formats or quality settings at once. Both can result in a single endpoint sending multiple RTP packet streams of the same media type into a single RTP session at the same time 💫.

Associated repair data:

An endpoint might send an RTP packet stream that is somehow associated with another stream 🩹. For example, it might send an RTP packet stream that contains FEC or retransmission data relating to another stream. Some RTP payload formats send this sort of associated repair data as part of the source packet stream, while others send it as a separate packet stream 🧵.

Layered or multiple-description coding:

Within a single RTP session, an endpoint can use a layered media codec (for example, H.264 Scalable Video Coding (SVC)) or a multiple-description codec that generates multiple RTP packet streams, each with a distinct RTP SSRC 🍰.

RTP mixers, translators, and other middleboxes:

An RTP session, in the WebRTC context, is a point-to-point association between an endpoint and some other peer device, where those devices share a common SSRC space 🤝. The peer device might be another WebRTC endpoint, or it might be an RTP mixer, translator, or some other form of media-processing middlebox. In the latter cases, the middlebox might send mixed or relayed RTP streams from several participants, which the WebRTC endpoint will need to render 🎭. Thus, even though a WebRTC endpoint might only be a member of a single RTP session, the peer device might be extending that RTP session to incorporate other endpoints. WebRTC is a group communication environment, so endpoints need to be capable of receiving, decoding, and playing out multiple RTP packet streams at once, even in a single RTP session 🥳.

12.1.2. Use of Multiple RTP Sessions ✨

okay so a WebRTC endpoint doesn't have to stick to just one RTP session. In addition to sending and receiving multiple RTP packet streams inside a single session, it can also join multiple RTP sessions 💅 There are a few reasons it might do that:

To interoperate with legacy devices: 🎀 The usual move in the non-WebRTC world is to send different types of media in separate RTP sessions. Think one session for audio and another session on its own transport-layer flow for video. Every WebRTC endpoint needs to support sending different media types on different RTP sessions so it can work with those legacy devices. More on this in Section 4.4 🫶
To provide enhanced quality of service: 🔥 Some network quality-of-service mechanisms work at the level of transport-layer flows. So if you want those mechanisms to give certain RTP packet streams better treatment, those streams need their own RTP session on a different transport-layer flow, with the right quality-of-service marking. Section 12.1.3 has the details 💖
To separate media with different purposes: 🦋 Sometimes an endpoint wants to send RTP packet streams with different jobs on different RTP sessions, so the peer can tell them apart easily. For example, some centralized multiparty conferencing systems show the active speaker in high resolution and everyone else as low-resolution "thumbnails." Those systems might have endpoints send simulcast high- and low-resolution video over separate RTP sessions, which makes life easier for the RTP middlebox. In WebRTC, you can already do this by creating multiple MediaStreamTracks that share the same media source within one (or more) RTCPeerConnection. Each track gets set up for a particular quality and bitrate, and it produces its own independently encoded version using the codec parameters agreed for that RTCPeerConnection. The RTP middlebox can tell the low- and high-resolution streams apart by looking at their SSRC, RTP payload type, or other info in the RTP payload, RTP header extension, or RTCP packets. Still, it's often simpler if those streams arrive on separate RTP sessions over separate transport-layer flows 🌸
To directly connect with multiple peers: 🧚 A multiparty call doesn't have to use an RTP middlebox. You can build a multi-unicast mesh instead, made of several separate RTP sessions. Each participant sends its RTP traffic over its own RTP session (so, its own independent RTCPeerConnection object) to every other participant, like this:

+---+     +---+
| A |<--->| B |
+---+     +---+
  ^         ^
   \       /
    \     /
     v   v
     +---+
     | C |
     +---+

        Figure 1: Multi-unicast Using Several RTP Sessions

The big perk here is that you don't need a middlebox you have to trust with the media data 🙈 The catch is that each sender's bandwidth goes up, because it needs one copy of the RTP packet streams for every other participant in the session.

The multi-unicast topology could also run as one RTP session spanning several peer-to-peer transport-layer connections, or as a bunch of pairwise RTP sessions, one for each pair of peers. To keep the relationship between RTP sessions and RTCPeerConnection objects clean and easy to follow, it is RECOMMENDED to implement it as several individual RTP sessions. The one downside: endpoint A won't find out how the B-to-C transmission is doing, because it never sees the RTCP reports for the B-to-C session. If all three were in one RTP session, it would 👀 Back in the late 1990s, the Mbone tools (experimental RTP-based multicast conferencing tools) showed that RTCP reception quality reports from third parties can help people understand asymmetric network problems. Separate RTP sessions block that view. The upside, though, is that separate sessions let each pair use different media bitrates and RTP session configurations. So B doesn't have to suffer the same quality drops C does when the transport from A to C is limited. The belief is that these benefits outweigh the loss of debugging power 💜

To indirectly connect with multiple peers: 👑 A super common approach in multiparty conferencing is to connect to several peers indirectly, through an RTP mixer, translator, or some other kind of RTP middlebox. Figure 2 shows a simple layout you might use for a four-person centralized conference. The middlebox tweaks the RTP packet streams to make things run better. It might send each receiver only some of the streams it got, or combine a set of contributing streams into one stream:

+---+      +-------------+      +---+
| A |<---->|             |<---->| B |
+---+      | RTP mixer,  |      +---+
           | translator, |
           | or other    |
+---+      | middlebox   |      +---+
| C |<---->|             |<---->| D |
+---+      +-------------+      +---+

           Figure 2: RTP Mixer with Only Unicast Paths

There are lots of ways to build the middlebox. If it's a standard RTP mixer or translator, one RTP session runs across the middlebox and covers all the endpoints in the multiparty session. Other middleboxes might use a separate RTP session between each endpoint and the middlebox. What they have in common is that they can use a bunch of tools to control the media encoding from a WebRTC endpoint. That includes asking the encoding chain to break and having the encoder produce a so-called Intra frame. Another common move is capping a stream's bitrate so it better fits the mixed output. They can also steer the frame rate, picture resolution, and the trade-off between frame rate and spatial quality 🎬 The middlebox is responsible for doing congestion control correctly, identifying sources, and managing synchronization, all while giving the application the media optimizations it needs. It also has to be a trusted node security-wise, since it changes the RTP header, the media itself, or both before passing them to the endpoint(s). So it needs to decrypt and then re-encrypt the RTP packet stream before sending it on.

Mixers aren't supposed to forward RTCP reports about RTP packet streams across themselves 🙅‍♀️ The reason is that each receiver gets a different RTP packet stream. The original media source has no idea what the mixer changed before sending the media to each receiver. Feedback or requests from an endpoint also end up at the mixer. If the mixer can't handle a request on its own, it has to go back to the original media source to get the receiver what it asked for. None of this necessarily shows up in RTP or RTCP traffic, but the interactions and how long they take will reveal those dependencies.

Source authentication in multiparty setups is tricky 😭 With mixer-based topologies, an endpoint's source authentication relies on, first, cryptographically verifying that the media came from the mixer, and second, trusting the mixer to correctly identify any source toward the endpoint. In RTP sessions where an endpoint can directly see several other endpoints, every one of those endpoints knows the others' master keys. That means any of them can inject packets pretending to come from another endpoint in the session. Any node doing relay can apply a noncryptographic mitigation: stop forwarding packets whose SSRC fields came from other endpoints earlier. For cryptographic verification of the source, SRTP would need extra security mechanisms, such as Timed Efficient Stream Loss-Tolerant Authentication (TESLA) for SRTP [RFC4383]. Those mechanisms aren't part of the base WebRTC standards.

To forward media between multiple peers: 🌈 Sometimes an endpoint that receives an RTP packet stream needs to forward it on to a third party. There are some obvious security and privacy implications, but there are also useful things you can do with it. The W3C API supports this by taking the received, decoded media and using it as a media source, which then gets re-encoded and sent out as a new stream.

At the RTP layer, forwarding acts as a back-to-back RTP receiver and RTP sender. The receiving side ends the RTP session and decodes the media. The sending side re-encodes the media and transmits it in a totally separate RTP session. The original sender only sees one receiver, and it can't tell forwarding is happening from RTP-layer info, because the session used for the forwarded media isn't connected to the session where the forwarding node received the media.

The forwarding endpoint is in charge of producing an RTP packet stream that's suitable for sending onward. The outgoing RTP session is completely separate from the one the media came in on. To get a suitable bitrate for the outgoing session, you'll need media transcoding for congestion control purposes. That lowers media quality and makes the forwarding endpoint spend resources on transcoding. Still, transcoding separates the two legs, which removes almost all dependencies and lets the forwarding endpoint optimize its transcoding. The cost is much higher computational complexity on the forwarding node. Receivers of the forwarded stream see the forwarding device as the sender. From the RTP layer, they can't tell whether they're getting a forwarded stream or a brand-new RTP packet stream generated by the forwarding device 🦋

12.1.3. Differentiated Treatment of RTP Streams ✨

okay so there are totally use cases for treating RTP packet streams differently 💅 and that can happen in a few different places in the system. First up is prioritization inside the endpoint that's sending the media. That's what decides which RTP packet streams get sent, and how much of the current available aggregate bitrate each one gets, as determined by the congestion control 🎀

It's expected that the WebRTC API [W3C.WebRTC] will let the application indicate relative priorities for different MediaStreamTracks 🦋 Those priorities can then be used to influence the local RTP processing, especially when it comes to dividing the available bandwidth between the RTP packet streams for the sake of congestion control. Any changes in relative priority will also need to be considered for RTP packet streams that are associated with the main RTP packet streams, like redundant streams for RTP retransmission and FEC. How important those redundant streams are depends on the media type and codec used, with regard to how robust that codec is against packet loss. Still, a default policy might be to give a redundant RTP packet stream the same priority as its source RTP packet stream 🫶

Secondly, the network can prioritize transport-layer flows and subflows, including RTP packet streams 🌸 Typically, differential treatment has two steps. The first is identifying whether an IP packet belongs to a class that has to be treated differently, and the second is the actual mechanism for prioritizing packets. There are three common methods for classifying IP packets:

DiffServ: The endpoint marks a packet with a DiffServ code point to indicate to the network that the packet belongs to a particular class.
Flow based: Packets that need to be given a particular treatment are identified using a combination of IP and port address.
Deep packet inspection: A network classifier (DPI) inspects the packet and tries to determine if the packet represents a particular application and type that is to be prioritized.

Flow-based differentiation gives the same treatment to all packets within a transport-layer flow, so relative prioritization isn't possible 😭 And if resources are limited, it might not be possible to provide differential treatment compared to best effort for all the RTP packet streams used in a WebRTC session. Using flow-based differentiation needs to be coordinated between the WebRTC system and the network(s). The WebRTC endpoint needs to know that flow-based differentiation might be used to separate the RTP packet streams onto different UDP flows, which allows a more granular use of flow-based differentiation 🧚 The flows that are used, their 5-tuples, and their prioritization need to be communicated to the network so it can identify the flows correctly and prioritize them. No specific protocol support for this is specified 💜

DiffServ assumes that either the endpoint or a classifier can mark the packets with an appropriate Differentiated Services Code Point (DSCP), so the packets get treated according to that marking. If the endpoint is the one doing the marking, two requirements come up in the WebRTC context: 1) The WebRTC endpoint has to know which DSCPs to use and know that it can use them on some set of RTP packet streams. 2) The information needs to be passed down to the operating system when the packet is transmitted. The details of this process are outside the scope of this memo and are further discussed in "Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS" [RFC8837] 🌈

Even with SRTP media encryption, deep packet inspectors are still pretty capable of classifying the RTP streams 👑 The reason is that SRTP leaves the first 12 bytes of the RTP header unencrypted. That makes it easy to identify an RTP stream using the SSRC, and it gives the classifier useful information that can be correlated to determine, for example, the stream's media type. Using packet sizes, reception times, packet inter-spacing, RTP timestamp increments, and sequence numbers, fairly reliable classifications can be achieved 🔥

For packet-based marking schemes, it might be possible to mark individual RTP packets differently based on the relative priority of the RTP payload. For example, video codecs that have I, P, and B pictures could give lower priority to any payloads carrying only B frames, since losing those is less damaging. But depending on the QoS mechanism and which markings are applied, this can result in not only different packet-drop probabilities but also packet reordering. See [RFC8837] and [RFC7657] for further discussion 🙈 As a default policy, all RTP packets related to an RTP packet stream ought to get the same prioritization. Per-packet prioritization is outside the scope of this memo but might be specified elsewhere in the future ⭐

It's also important to think about how the RTCP packets associated with a particular RTP packet stream get marked 🍓 RTCP compound packets with Sender Reports (SRs) ought to be marked with the same priority as the RTP packet stream itself, so the RTCP-based round-trip time (RTT) measurements use the same transport-layer flow priority that the RTP packet stream experiences. RTCP compound packets containing an RR packet ought to be sent with the priority used by the majority of the RTP packet streams being reported on. And RTCP packets containing time-critical feedback packets can use a higher priority to improve the timeliness and likelihood of delivery of that feedback 💖

12.2. Media Source, RTP Streams, and Participant Identification 🦋

12.2.1. Media Source Identification 🌸

Each RTP packet stream is identified by a unique synchronization source (SSRC) identifier. The SSRC identifier is carried in each of the RTP packets that make up an RTP packet stream, and it's also used to identify that stream in the corresponding RTCP reports. The SSRC is chosen as discussed in Section 4.8. The first stage in demultiplexing RTP and RTCP packets received on a single transport-layer flow at a WebRTC endpoint is to separate the RTP packet streams based on their SSRC value. Once that's done, additional demultiplexing steps can determine how and where to render the media 🎀

RTP lets a mixer, or other RTP-layer middlebox, combine encoded streams from multiple media sources to form a new encoded stream from a new media source (the mixer) 🧚 The RTP packets in that new RTP packet stream can include a contributing source (CSRC) list, which indicates which original SSRCs contributed to the combined source stream. As described in Section 4.1, implementations need to support reception of RTP data packets containing a CSRC list, and RTCP packets that relate to sources present in the CSRC list. The CSRC list can change on a packet-by-packet basis, depending on the mixing operation being performed. Knowing which media sources contributed to a particular RTP packet can be important if the user interface shows which participants are active in the session 👑 Changes in the CSRC list included in packets need to be exposed to the WebRTC application using some API if the application is going to track changes in session participation. It's desirable to map CSRC values back into WebRTC MediaStream identities as they cross this API, so the SSRC/CSRC namespace doesn't get exposed to WebRTC applications 💅

If the mixer-to-client audio level extension [RFC6465] is being used in the session (see Section 5.2.3), the information in the CSRC list is augmented by audio-level information for each contributing source. It's desirable to expose this information to the WebRTC application using some API, after mapping the CSRC values to WebRTC MediaStream identities, so it can be shown in the user interface 🫶

12.2.2. SSRC Collision Detection 💀

The RTP standard requires RTP implementations to have support for detecting and handling SSRC collisions, i.e., being able to resolve the conflict when two different endpoints use the same SSRC value (see Section 8.2 of [RFC3550]). This requirement also applies to WebRTC endpoints. There are several scenarios where SSRC collisions can happen:

In a point-to-point session where each SSRC is associated with either of the two endpoints, and the main media-carrying SSRC identifier will be announced in the signaling channel, a collision is less likely to occur because of the information about used SSRCs. If SDP is used, this information is provided by source-specific SDP attributes [RFC5576]. Still, collisions can happen if both endpoints start using a new SSRC identifier before they've signaled it to the peer and received an acknowledgement on the signaling message. "Source-Specific Media Attributes in the Session Description Protocol (SDP)" [RFC5576] contains a mechanism to signal how the endpoint resolved the SSRC collision 😭
SSRC values that haven't been signaled could also appear in an RTP session. This is more likely than it sounds, since some RTP functions use extra SSRCs to provide their functionality. For example, retransmission data might be sent using a separate RTP packet stream that requires its own SSRC, separate from the SSRC of the source RTP packet stream [RFC4588]. In those cases, an endpoint can create a new SSRC that strictly doesn't need to be announced over the signaling channel to function correctly on both RTP and RTCPeerConnection level 🙈
Multiple endpoints in a multiparty conference can create new sources and signal those towards the RTP middlebox. In cases where the SSRC/CSRC values are propagated between the different endpoints from the RTP middlebox, collisions can occur 🍓
An RTP middlebox could connect an endpoint's RTCPeerConnection to another RTCPeerConnection from the same endpoint, forming a loop where the endpoint receives its own traffic. While it's clearly considered a bug, it's important that the endpoint can recognize and handle the case when it happens. This case gets even more problematic when media mixers and such are involved, because the stream received is a different stream but still contains this client's input 🔥

These SSRC/CSRC collisions can only be handled on the RTP level when the same RTP session is extended across multiple RTCPeerConnections by an RTP middlebox. To resolve the more generic case where multiple RTCPeerConnections are interconnected, the identification of the media source or sources that are part of a MediaStreamTrack being propagated across those interconnected RTCPeerConnections needs to be preserved across these interconnections 💖

12.2.3. Media Synchronization Context 🎀

Okay so bestie, when an endpoint sends media from more than one media source, it has to figure out whether (and which of) those sources need to be synchronized 🧚. In RTP/RTCP, sync works by marking a bunch of RTP packet streams as coming from the same synchronization context and logical endpoint, and you do that by using the same RTCP CNAME identifier 💖.

Next up, the internal clocks of all the media sources (the things that drive the RTP timestamp) can be correlated to a system clock. That system clock shows up in RTCP Sender Reports, encoded in NTP format ⏰. If you line up every RTP timestamp against one shared system clock for all the sources, the receiver can work out how the different RTP packet streams relate in time, even across multiple RTP sessions. Then it can sync them up if it wants 🦋. The media sender is the one who has to provide that correlation info, but whether the receiver actually uses it is totally up to them 💅.

13. Security Considerations 🔐

The overall security architecture for WebRTC is covered in [RFC8827], and the security considerations for the WebRTC framework are in [RFC8826]. Those considerations apply to this memo too 💜.

The security considerations of the RTP specification, the RTP/SAVPF profile, and the various RTP/RTCP extensions and RTP payload formats that make up the full protocol suite in this memo all apply as well 🫶. It is believed that there are no new security considerations from combining these protocol extensions, so no new drama there (for now) ✨.

"Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] handles the fundamental issues by offering confidentiality, integrity, and partial source authentication 🔒. If you combine this secured RTP profile with DTLS-SRTP keying [RFC5764], as defined by Section 5.5 of [RFC8827], you get a media-security solution that is mandatory to implement and use. Iconic, right? 👑

RTCP packets carry a Canonical Name (CNAME) identifier, which is used to associate RTP packet streams that need to be synchronized across related RTP sessions. Picking CNAME values carelessly can be a privacy concern, because long-term persistent CNAME identifiers can be used to track users across multiple WebRTC calls 👀. Section 4.9 of this memo mandates generating short-term persistent RTCP CNAMEs, as specified in RFC 7022. That gives you untraceable CNAME values, which takes care of this risk 🙈.

Some denial-of-service attacks are possible if the RTCP reporting interval is configured to an inappropriate value. Someone could set the RTCP bandwidth fraction to an excessively large or small value using the SDP b=RR: or b=RS: lines [RFC3556] or some similar mechanism. They could also pick an excessively large or small value for the RTP/AVPF minimal receiver report interval (if you're using SDP, that's the a=rtcp-fb:... trr-int parameter) [RFC4585]. Here's the drama, bestie 😭:

The RTCP bandwidth could be configured so the regular reporting interval gets so large that effective congestion control can't be maintained. That could lead to denial of service from congestion caused by the media traffic 💀.
The RTCP interval could be configured to a very small value, so endpoints generate high-rate RTCP traffic. That could lead to denial of service because RTCP traffic isn't congestion controlled 🚨.
RTCP parameters could be configured differently for each endpoint, with some endpoints using a large reporting interval and others using a smaller one. That could cause denial of service through premature participant timeouts, because the timeout periods are based on the reporting interval and they don't match. This is a big concern if endpoints use a small but nonzero value for the RTP/AVPF minimal receiver report interval (trr-int) [RFC4585], as discussed in Section 6.1 of [RFC8108] 😤.

Premature participant timeouts can be avoided by using the fixed (nonreduced) minimum interval when calculating the participant timeout (see Section 4.1 of this memo and Section 7.1.2 of [RFC8108]) 🧠. To deal with the other concerns, endpoints SHOULD ignore parameters that configure the RTCP reporting interval to be significantly longer than the default five-second interval specified in [RFC3550]. The exception is when the media data rate is so low that the longer interval roughly corresponds to 5% of the media data rate 🐢. Endpoints SHOULD also ignore parameters that configure the RTCP reporting interval small enough that the RTCP bandwidth would exceed the media bandwidth 📉.

The guidelines in [RFC6562] apply when you use variable bitrate (VBR) audio codecs such as Opus (see Section 4.3 for the discussion of mandated audio codecs) 🎶. They also apply, though they matter less, when you use the client-to-mixer audio level header extensions (Section 5.2.2) or the mixer-to-client audio level header extensions (Section 5.2.3) 💫. Encrypting the header extensions is RECOMMENDED, unless there are known reasons for not doing it. An example would be RTP middleboxes doing voice-activity-based source selection, or third-party monitoring that would really benefit from the information, and that's been expressed using the API or signaling 🙌. If further evidence shows that information leakage from audio-level indications is significant, then encryption will need to be mandated at that point 🚩.

In multiparty communication scenarios that use RTP middleboxes, a lot of trust is placed in those middleboxes to keep the session secure 🥺. The middlebox needs to maintain confidentiality and integrity and to perform source authentication. As discussed in Section 12.1.1, the middlebox can run checks that stop any endpoint in a conference from impersonating another, which is very main character energy 🦸‍♀️. Some additional security considerations for multiparty topologies can be found in [RFC7667] 📚.

14. IANA Considerations 🌸

Okay, quick one: this document has no IANA actions, so there's nothing to register or request. Zero paperwork, full vibes 💅.

15. References 📖

15.1. Normative References ✨

okay bestie, these are the docs the spec leans on the hardest 📚 every one of these is needed to read this one properly 💖

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of RTP Payload Format Specifications", BCP 36, RFC 2736, DOI 10.17487/RFC2736, December 1999, <https://www.rfc-editor.org/info/rfc2736>.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.

[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <https://www.rfc-editor.org/info/rfc3551>.

[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, <https://www.rfc-editor.org/info/rfc3556>.

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.

[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <https://www.rfc-editor.org/info/rfc4585>.

[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <https://www.rfc-editor.org/info/rfc4588>.

[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, <https://www.rfc-editor.org/info/rfc4961>.

[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <https://www.rfc-editor.org/info/rfc5104>.

[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <https://www.rfc-editor.org/info/rfc5124>.

[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, <https://www.rfc-editor.org/info/rfc5506>.

[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <https://www.rfc-editor.org/info/rfc5761>.

[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.

[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, <https://www.rfc-editor.org/info/rfc6051>.

[RFC6464] Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication", RFC 6464, DOI 10.17487/RFC6464, December 2011, <https://www.rfc-editor.org/info/rfc6464>.

[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication", RFC 6465, DOI 10.17487/RFC6465, December 2011, <https://www.rfc-editor.org/info/rfc6465>.

[RFC6562] Perkins, C. and JM. Valin, "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP", RFC 6562, DOI 10.17487/RFC6562, March 2012, <https://www.rfc-editor.org/info/rfc6562>.

[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)", RFC 6904, DOI 10.17487/RFC6904, April 2013, <https://www.rfc-editor.org/info/rfc6904>.

[RFC7007] Terriberry, T., "Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)", RFC 7007, DOI 10.17487/RFC7007, August 2013, <https://www.rfc-editor.org/info/rfc7007>.

[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, <https://www.rfc-editor.org/info/rfc7022>.

[RFC7160] Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple Clock Rates in an RTP Session", RFC 7160, DOI 10.17487/RFC7160, April 2014, <https://www.rfc-editor.org/info/rfc7160>.

[RFC7164] Gross, K. and R. Brandenburg, "RTP and Leap Seconds", RFC 7164, DOI 10.17487/RFC7164, March 2014, <https://www.rfc-editor.org/info/rfc7164>.

[RFC7742] Roach, A.B., "WebRTC Video Processing and Codec Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016, <https://www.rfc-editor.org/info/rfc7742>.

[RFC7874] Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016, <https://www.rfc-editor.org/info/rfc7874>.

[RFC8083] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", RFC 8083, DOI 10.17487/RFC8083, March 2017, <https://www.rfc-editor.org/info/rfc8083>.

[RFC8108] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session", RFC 8108, DOI 10.17487/RFC8108, March 2017, <https://www.rfc-editor.org/info/rfc8108>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General Mechanism for RTP Header Extensions", RFC 8285, DOI 10.17487/RFC8285, October 2017, <https://www.rfc-editor.org/info/rfc8285>.

[RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, January 2021, <https://www.rfc-editor.org/info/rfc8825>.

[RFC8826] Rescorla, E., "Security Considerations for WebRTC", RFC 8826, DOI 10.17487/RFC8826, January 2021, <https://www.rfc-editor.org/info/rfc8826>.

[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, January 2021, <https://www.rfc-editor.org/info/rfc8827>.

[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021, <https://www.rfc-editor.org/info/rfc8843>.

[RFC8854] Uberti, J., "WebRTC Forward Error Correction Requirements", RFC 8854, DOI 10.17487/RFC8854, January 2021, <https://www.rfc-editor.org/info/rfc8854>.

[RFC8858] Holmberg, C., "Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)", RFC 8858, DOI 10.17487/RFC8858, January 2021, <https://www.rfc-editor.org/info/rfc8858>.

[RFC8860] Westerlund, M., Perkins, C., and J. Lennox, "Sending Multiple Types of Media in a Single RTP Session", RFC 8860, DOI 10.17487/RFC8860, January 2021, <https://www.rfc-editor.org/info/rfc8860>.

[RFC8861] Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, "Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback", RFC 8861, DOI 10.17487/RFC8861, January 2021, <https://www.rfc-editor.org/info/rfc8861>.

[W3C.WD-mediacapture-streams] Jennings, C., Aboba, B., Bruaroey, J-I., and H. Boström, "Media Capture and Streams", W3C Candidate Recommendation, <https://www.w3.org/TR/mediacapture-streams/>.

[W3C.WebRTC] Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0: Real-time Communication Between Browsers", W3C Proposed Recommendation, <https://www.w3.org/TR/webrtc/>.

that's the whole normative list, babe 🫶 every one of these is load-bearing 💅

15.2. Informative References 📚

okay so this is the reading list for the optional-but-useful stuff 🤓 nothing here is strictly required to implement the spec, but these are the docs the authors pointed to, so bookmark them bestie 🔖

[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <https://www.rfc-editor.org/info/rfc3611>.

[RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, DOI 10.17487/RFC4383, February 2006, <https://www.rfc-editor.org/info/rfc4383>.

[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <https://www.rfc-editor.org/info/rfc5576>.

[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP Control Protocol (RTCP)", RFC 5968, DOI 10.17487/RFC5968, September 2010, <https://www.rfc-editor.org/info/rfc5968>.

[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, DOI 10.17487/RFC6263, June 2011, <https://www.rfc-editor.org/info/rfc6263>.

[RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use of the RTP Monitoring Framework", RFC 6792, DOI 10.17487/RFC6792, November 2012, <https://www.rfc-editor.org/info/rfc6792>.

[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-Time Communication Use Cases and Requirements", RFC 7478, DOI 10.17487/RFC7478, March 2015, <https://www.rfc-editor.org/info/rfc7478>.

[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <https://www.rfc-editor.org/info/rfc7656>.

[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.

[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <https://www.rfc-editor.org/info/rfc7667>.

[RFC8088] Westerlund, M., "How to Write an RTP Payload Format", RFC 8088, DOI 10.17487/RFC8088, May 2017, <https://www.rfc-editor.org/info/rfc8088>.

[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.

[RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., "JavaScript Session Establishment Protocol (JSEP)", RFC 8829, DOI 10.17487/RFC8829, January 2021, <https://www.rfc-editor.org/info/rfc8829>.

[RFC8830] Alvestrand, H., "WebRTC MediaStream Identification in the Session Description Protocol", RFC 8830, DOI 10.17487/RFC8830, January 2021, <https://www.rfc-editor.org/info/rfc8830>.

[RFC8836] Jesup, R. and Z. Sarker, Ed., "Congestion Control Requirements for Interactive Real-Time Media", RFC 8836, DOI 10.17487/RFC8836, January 2021, <https://www.rfc-editor.org/info/rfc8836>.

[RFC8837] Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, January 2021, <https://www.rfc-editor.org/info/rfc8837>.

[RFC8872] Westerlund, M., Burman, B., Perkins, C., Alvestrand, H., and R. Even, "Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams", RFC 8872, DOI 10.17487/RFC8872, January 2021, <https://www.rfc-editor.org/info/rfc8872>.

Acknowledgements 🫶

the authors wanna give a huge shoutout 📣 to Bernard Aboba, Harald Alvestrand, Cary Bran, Ben Campbell, Alissa Cooper, Spencer Dawkins, Charles Eckel, Alex Eleftheriadis, Christian Groves, Chris Inacio, Cullen Jennings, Olle Johansson, Suhas Nandakumar, Dan Romascanu, Jim Spring, Martin Thomson, and the rest of the IETF RTCWEB working group for their super valuable feedback 💖 the whole group really showed up 👑

Authors' Addresses 🦋

Colin Perkins
University of Glasgow
School of Computing Science
Glasgow
G12 8QQ
United Kingdom

Email: csp@csperkins.org
URI:   https://csperkins.org/

Magnus Westerlund
Ericsson
Torshamnsgatan 23
SE-164 80 Kista
Sweden

Email: magnus.westerlund@ericsson.com

Jörg Ott
Technical University Munich
Department of Informatics
Chair of Connected Mobility
Boltzmannstrasse 3
85748 Garching
Germany

Email: ott@in.tum.de

📦 where this page comes from

ietf: rfc8834 2021-01
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms