RFC 6285
Unicast-Based Rapid Acquisition of Multicast RTP Sessions
Unicast-Based Rapid Acquisition of Multicast RTP Sessions 🦋
okay bestie, this is RFC 6285 💖 and it's a Standards Track doc 📜 with ISSN 2070-1721. It was published in June 2011. The authors are B. Ver Steeg and A. Begen from Cisco, T. Van Caenegem from Alcatel-Lucent, and Z. Vax from Magnum Semiconductor 🫶. Nothing is listed as obsoleted or updated in its header.
Abstract ✨
okay so picture this 🎀 when an RTP receiver joins a multicast session, it may need to grab and parse certain Reference Information before it can process any data in that session 😭. How long that takes depends on when it joined, how long the gap is between Reference Information repeats (or appearances), how big that info is, and the application and transport properties. The time lag before the receiver can actually use the multicast data is called the Acquisition Delay, and it can get really big 💀. Honestly this is not ideal for receivers that keep hopping between multicast sessions, like video broadcasts 🙈.
In this doc we describe a method that uses the RTP and RTP Control Protocol (RTCP) machinery we already have to cut down that Acquisition Delay ✨. An auxiliary unicast RTP session carries the Reference Information to the receiver and runs ahead of or alongside the multicast stream 🦋. This unicast RTP flow can be sent at a faster than natural bitrate to speed up acquisition even more 🚀.
The main use case here is multicast apps that carry real-time compressed audio and video 🎧. But this method can also be used in other kinds of multicast applications where the Acquisition Delay is long enough to be a problem 💅.
Status of This Memo 📜
This is an Internet Standards Track document.
It's a product of the Internet Engineering Task Force (IETF) 🌸. It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. You can read more about Internet Standards in Section 2 of RFC 5741.
Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6285 🔍.
Copyright Notice ©️
bestie, this part is the legal stuff, so I'm keeping it as close to the original as I can 🙈.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
⚠️ This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents 📋
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 6
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Elements of Delay in Multicast Applications . . . . . . . . . 8
5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 10
6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Synchronization of Primary Multicast Streams . . . . . . . 24
6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 25
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 34
7.3.1. Response Code Definitions . . . . . . . . . . . . . . 37
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 39
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 41
8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 41
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 44
10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 48
11.2. Registration of SDP Attribute Values . . . . . . . . . . . 48
11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 48
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 48
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 49
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 50
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Normative References . . . . . . . . . . . . . . . . . . . 52
14.2. Informative References . . . . . . . . . . . . . . . . . . 541. Introduction ✨
Okay so most multicast flows carry a stream of inter-related data 🌊. Receivers need to grab certain info before they can start processing anything sent in the multicast session. This doc calls that info Reference Information 📚. It's usually sent periodically in the session (although its content can change over time), and it usually includes things like a description of the schema for the rest of the data, references to which data to process, encryption info including keys, and any other info needed to process the data in the multicast stream [IC2009].
Real-time multicast apps make receivers buffer data 🫧. Receivers may need to buffer to smooth out network jitter, to let loss-repair methods like Forward Error Correction and retransmission recover missing packets, and to meet the data-processing needs of the application layer.
When a receiver joins a multicast session, it has zero control over what point in the flow is currently being sent 🙃. Sometimes it joins right before the Reference Information goes out, and then the wait is usually minimal. Other times it joins right after the Reference Information has already gone by, so it has to wait for it to show up again before it can process any multicast data. And in some cases the Reference Information isn't contiguous but spread out over a big stretch of time, which means the receiver has to wait for all of it to arrive before it can start on the rest of the data 😩.
The net effect of waiting for Reference Information plus waiting for buffers to fill up is that receivers can experience seriously big delays in data processing 💀. Here we call the difference between the time an RTP receiver wants to join the multicast session and the time it acquires all the necessary Reference Information the Acquisition Delay ⏳. It might not be the same for every receiver. It usually depends on the join time, the length of the Reference Information repetition (or appearance) interval, the size of the Reference Information, and the application and transport properties.
Acquisition delay is especially rough for receivers that frequently switch among multicast sessions 🔁. It applies to both any-source multicast (ASM) and source-specific multicast (SSM) apps, but in this spec we tackle it for SSM-based apps with a method that uses the fundamental tools offered by the existing RTP and RTCP protocols [RFC3550]. Here's the vibe: either the multicast source (or the distribution source in an SSM session) holds onto the Reference Information for a period after sending it, or an intermediary network element (we call it a Retransmission Server) joins the multicast session, continuously caches the Reference Information as it's sent, and acts as a feedback target (see [RFC5760]) for the session 🧚.
When an RTP receiver wants to join the same multicast session, it doesn't just send a Source Filtering Group Management Protocol (SFGMP) Join message 🙅♀️. Instead, it sends a request to the feedback target for the session and asks for the Reference Information. The retransmission server starts a new unicast RTP (retransmission) session and sends the Reference Information to the receiver over that session. If there's residual bandwidth, the retransmission server might burst the Reference Information faster than its natural rate 🏎️. As soon as the receiver acquires the Reference Information, it can join the multicast session and start processing the multicast data. Figure 1 shows this method through an intermediary network element 👇.
This method potentially reduces the acquisition delay 🎀. We call it Unicast-Based Rapid Acquisition of Multicast RTP Sessions. A primary use case is reducing channel-change times in IPTV networks, where compressed video streams are multicast in different SSM sessions and viewers randomly join these sessions 📺.
-----------------------
+--->| Intermediary |
| | Network Element |
| ...|(Retransmission Server)|
| : -----------------------
| :
| v
----------- ---------- ----------
| Multicast | | |---------->| Joining |
| Source |------->| Router |..........>| RTP |
| | | | | Receiver |
----------- ---------- ----------
|
| ----------
+---------------->| Existing |
| RTP |
| Receiver |
----------
-------> Multicast RTP Flow
.......> Unicast RTP FlowFigure 1: Rapid Acquisition through an Intermediary Network Element
A principle design goal here is to use the existing tools in the RTP/RTCP protocol family 🧰. That makes existing implementations more versatile and promotes faster deployment and better interoperability 🫶. To that end, we use the unicast retransmission support of RTP [RFC4588] and the capabilities of RTCP to handle the signaling needed to accomplish the acquisition.
A reasonable effort has been made in this spec to design a solution that reliably works in both engineered and best-effort networks 🛠️. However, proper congestion control combined with the desired behavior of this solution is difficult to achieve. Instead, this solution is designed on the assumption that the retransmission server and the RTP receivers have some knowledge about where the bottleneck between them is. That assumption doesn't generally hold unless both the retransmission server and the RTP receivers are in the same edge network. So this solution should not be used across any best-effort path of the Internet 🚫. Furthermore, this solution should only be used in networks that are already carrying non-congestion-responsive multicast traffic, and that have throttling mechanisms in the retransmission servers to ensure the (unicast) burst traffic is a known constant upper-bound multiplier on the multicast load ⚠️.
1.1. Acquisition of RTP Streams vs. RTP Sessions
In this memo, we describe a protocol that handles the rapid acquisition of a single multicast RTP session (called a primary multicast RTP session) carrying one or more RTP streams (called primary multicast streams) 💅. If desired, multiple instances of this protocol may be run in parallel to acquire multiple RTP sessions simultaneously ✨.
When an RTP receiver requests the Reference Information from the retransmission server, it can opt to rapidly acquire a specific subset of the available RTP streams in the primary multicast RTP session 🍓. Or it can request rapid acquisition of all of the RTP streams in that RTP session. Regardless of how many RTP streams the receiver requests, or how many will actually be sent by the retransmission server, only one unicast RTP session will be established by the retransmission server. This unicast RTP session is separate from the associated primary multicast RTP session. So there are always two different RTP sessions in a single instance of the rapid acquisition protocol: (i) the primary multicast RTP session with its associated unicast feedback, and (ii) the unicast RTP session 🦋.
If the RTP receiver wants to rapidly acquire multiple RTP sessions simultaneously, separate unicast RTP sessions will be established for each of them 🌈.
1.2. Outline
The rest of this spec goes like this 🗺️. Section 3 provides a list of the definitions frequently used in this document. In Section 4, we describe the delay components in generic multicast applications. Section 5 presents an overview of the protocol design considerations for rapid acquisition. We provide the protocol details of the rapid acquisition method in Sections 6 and 7. Sections 8 and 9 discuss the Session Description Protocol (SDP) signaling issues with examples and NAT-related issues, respectively. Finally, Section 10 discusses the security considerations, and Section 11 details the IANA considerations 🔐.
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💖.
3. Definitions 📖✨
okay bestie, let's get the vocab down first 💅 this doc uses a bunch of acronyms and terms over and over, so here's the glossary:
(Primary) SSM Session: the multicast session that RTP receivers can join at a random point in time 🦋 one primary SSM session can carry multiple RTP streams.
Primary Multicast RTP Session: the multicast RTP session that an RTP receiver is really hoping to acquire quickly 🏃♀️💨 from the receiver's point of view, it gets one associated unicast RTCP feedback stream going to a Feedback Target, plus the primary multicast RTP stream(s).
Primary Multicast (RTP) Streams: the RTP stream(s) carried in the primary multicast RTP session 🌸
Source Filtering Group Management Protocol (SFGMP): this one follows the definition in [RFC4604] 💜 SFGMP means the Internet Group Management Protocol (IGMP) version 3 [RFC3376] and the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810] for IPv4 and IPv6 networks, respectively. BUT (and this is the iconic part 👑) the rapid acquisition method in this doc does not depend on a specific version of either of those group management protocols. in the rest of the doc, SFGMP just means any group management protocol that has Join and Leave functionalities.
Feedback Target (FT): the unicast RTCP feedback target, as defined in [RFC5760] ✨ FT_Ap refers to one specific feedback target running on a particular address and port.
Retransmission (or Burst) Packet: an RTP packet formatted as defined in Section 4 of [RFC4588] 🎀 the payload of a retransmission or burst packet is the retransmission payload header followed by the payload of the original RTP packet.
Reference Information: the set of certain media content and metadata information that's enough for an RTP receiver to start usefully consuming a media stream 🧚 what it means, what format it takes, and how big it is are all specific to the application and out of scope for this document 🙈
Preamble Information: a more compact form of all or a subset of the Reference Information, sent out-of-band 🍓
(Unicast) Burst (or Retransmission) RTP Session: the unicast RTP session used to send one or more unicast burst RTP streams and their associated RTCP messages. "burst RTP session" and "retransmission RTP session" can be used interchangeably, so don't let that confuse you 💖
(Unicast) Burst (Stream): a unicast stream of RTP retransmission packets that lets an RTP receiver rapidly acquire the Reference Information associated with a primary multicast stream 🦋 each burst stream is identified by its Synchronization Source (SSRC) identifier, which must be unique in the primary multicast RTP session. following the session-multiplexing guidelines in [RFC4588], each unicast burst stream uses the same SSRC and Canonical Name (CNAME) as its primary multicast RTP stream 🫶
Retransmission Server (RS): the RTP/RTCP endpoint that can generate the retransmission packets and the burst streams 🔥 the RS may also generate other non-retransmission packets to help with rapid acquisition.
4. Elements of Delay in Multicast Applications ⏱️💅
okay so in a source-specific multicast (SSM) delivery system, there are three major things that add to the acquisition delay when an RTP receiver hops from one multicast session to another 😭 they are:
- Multicast-switching delay
- Reference Information latency
- Buffering delays
Multicast-switching delay is the delay you feel when leaving the current multicast session (if there is one) and joining the new one 🌈 in typical systems, a group management protocol handles the join and leave operations. for example, receivers and routers in a multicast session can use the Internet Group Management Protocol (IGMP) version 3 [RFC3376] or the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810]. with either one, when a receiver wants to join, it sends a message to its upstream router, and the routing infrastructure sets up the multicast forwarding state so the new receiver gets the session's packets ✨ join times depend on how close the upstream router is, the current state of the multicast tree, the load on the system, and the protocol implementation. current systems give join latencies that are usually less than 200 milliseconds (ms) 💜 if the receiver was already in another multicast session before joining the new one, it needs to send a Leave message to its upstream router to leave that session. in common multicast routing protocols, leave times are usually smaller than join times, BUT it's possible that the Leave and Join messages get lost, and then the multicast-switching delay inevitably goes up 💀
Reference Information latency is the time it takes the receiver to acquire the Reference Information 🧚 this one depends heavily on how close the moment the receiver joined is to the next time the Reference Information gets sent to receivers in the session, on whether or not the Reference Information is sent contiguously, and on how big it is 🍓 for some multicast flows there's little or no interdependency in the data, so the Reference Information latency is nil or negligible 🌸 for other flows there's a high degree of interdependency, and one big example is multicast flows carrying compressed audio/video 🎀 for those, the Reference Information latency can get quite large and be a major contributor to the overall delay 😭
Buffering delays are driven by the way the application layer processes the payload 🦋 in lots of multicast applications, an unreliable transport protocol such as UDP [RFC0768] is used to send the data packets, and reliability (if it's needed) is usually handled some other way, like Forward Error Correction (e.g., [RFC6015]) and retransmission 👑 these loss-repair methods need buffering on the receiver side to work properly. in many applications, it's also often necessary to de-jitter the incoming data packets before handing them to the application, and de-jittering adds to the buffering delays too 🌈 on top of those network-related buffering delays, individual applications have their own buffering needs. for example, standard video decoders typically need a certain amount of coded video data (sometimes up to a few seconds) sitting in the pre-decoding buffers before they start decoding the video bitstream 🥹💖
5. Protocol Design Considerations and Their Effect on Resource Management for Rapid Acquisition ✨
Okay bestie, this section is just for info 💅 It doesn't have any requirements for implementers, so relax a little 🫶
Rapid acquisition is an optimization, and the whole system has to keep working correctly even when the optimization doesn't work. That includes when control and feedback messages get lost, when there's congestion, or when something else goes wrong 😭 This is the core design goal for the protocol and for the resource management schemes used with it, like Quality of Service (QoS) machinery, server load management, and so on 🎀 There are a few constraints the system has to live within:
- First, a rapid acquisition operation must fail gracefully. If someone tries rapid acquisition and it fails, their experience shouldn't be much worse than just joining the multicast session directly 🌸
- Second, the optimizations must not cause collateral damage. That goes for the multicast session being joined, for other multicast sessions sharing resources, and for the rapid acquisition operation itself. The operation has to avoid interfering with the multicast session that other hosts might be receiving at the same time. It also has to avoid interfering with other multicast and non-multicast sessions on the same network resources. These properties are possible, but they're usually hard to get, so it's giving "tricky" 💀
One challenge is that there are several bandwidth bottlenecks between the receiver and the server(s) providing rapid acquisition. In commercial IPTV deployments, for example, bottlenecks often show up in the aggregation network between the IPTV servers and the network edge, in the access links (like DSL or Data Over Cable Service Interface Specification (DOCSIS)), and in the subscriber's home network 🧚 Some of these links only serve one subscriber, so congestion only hurts that one person's traffic. Others are shared links carrying the multicast sessions of lots of subscribers. The state of these links can also change over time 🦋 The receiver might know about part of this network, or only partly know about the whole thing. How devices gather that network state information is out of scope for this document. The receiver should be able to tell the server how much bandwidth it thinks it can handle 💖 The server also needs to be able to rate limit the flow so it stays inside the performance envelope it knows about. Both sides need a way to tell the other when the requested or delivered rates change 🔥 The protocol has to be robust even when packets get lost, so this signaling needs to include the right default behaviors 🫶
Another challenge is that for some uses (like high-bitrate video), the unicast burst bitrate is high while the burst lasts only a short time. That's because the whole point of the unicast burst is to let the RTP receiver join the multicast quickly, which keeps the total resources used by the burst low 🌈 High-bitrate, short-duration flows like this don't fit well with conventional admission-control techniques. For example, end-to-end, per-flow, signaled admission control like Resource Reservation Protocol (RSVP) has too much latency and control channel overhead to be a good fit for rapid acquisition 😭 Using a TCP (or TCP-like) approach with a 3-way handshake and slow-start, to avoid causing congestion, would undo the whole reason for rapid acquisition. It would add many round-trip times (RTTs) of delay 🙈
These observations lead to some requirements and goals that can't be avoided for a rapid acquisition protocol. They are:
- The protocol must be designed so there's a deterministic upper bound on the extra bandwidth used, compared to just joining the multicast session. A reasonable size bound is
e*B, whereBis the nominal bandwidth of the primary multicast streams andeis an excess-bandwidth coefficient 👑 The total duration of the unicast burst also needs a reasonable bound. Long unicast bursts turn into the bandwidth profile of multi-unicast for the whole system, and nobody wants that 💀 - The scheme should minimize (or ideally eliminate) the overlap between the unicast burst and the primary multicast stream. This shrinks the window where congestion could be caused on a bottleneck link, compared to sending only the multicast or only the unicast packets 🍓
- The scheme must minimize (or ideally eliminate) any gap between the unicast burst and the primary multicast stream. A gap has to be repaired later, or, if it isn't repaired, the application will experience loss 😭
On top of all that, there are a few other protocol design issues to think about 🎀 First, there's at least one RTT of "slop" in the control loop. When a rapid acquisition burst starts, this shows up as the time between the client requesting the unicast burst and the burst description and/or the first unicast burst packets arriving at the receiver. For managing and ending the unicast burst, there are two possible approaches for the control loop. In the first, the receiver adapts to the unicast burst as it arrives, converges based on what it observes, and then explicitly ends the burst with a second control loop exchange. That exchange takes at least one RTT, just like starting the burst does 💅 In the second, the server generating the unicast burst works out the burst parameters from the information in the initial request, then tells the receiver how long the burst will last ✨
The protocol described in the next section supports either of these methods for controlling the rapid acquisition unicast burst 🦋
6. Rapid Acquisition of Multicast RTP Sessions (RAMS) 🧚
We're starting this section with an overview of the Rapid Acquisition of Multicast RTP Sessions (RAMS) method 💖
6.1. Overview 🌸
[RFC5760] specifies an extension to the RTP Control Protocol (RTCP) for using unicast feedback in an SSM session. It introduces an architecture with the concept of a Distribution Source. In an SSM context, the Distribution Source distributes the RTP data and redistributes RTCP information to all RTP receivers. That RTCP information is retrieved from the Feedback Target, which is where RTCP unicast feedback traffic gets sent 🫶 One or more entities other than the Distribution Source MAY implement the feedback target functionality, and different RTP receivers MAY use different feedback targets 👑
This document builds on those concepts to reduce acquisition delay when an RTP receiver joins a multicast session at a random point in time. It does this by introducing the concept of the Burst Source and some new RTCP feedback messages 🔥 The Burst Source has a cache where the most recent packets from the primary multicast RTP session are continuously stored. When an RTP receiver wants to receive a primary multicast stream, it can first request a unicast burst from the Burst Source before it joins the SSM session. In this burst, the packets are formatted as RTP retransmission packets [RFC4588] and carry Reference Information. That information lets the RTP receiver start usefully consuming the RTP packets sent in the primary multicast RTP session 🌈
If the unicast burst uses an accelerated bitrate (compared to the nominal bitrate of the primary multicast stream), then at some point the payload in the unicast burst will match the payload in the associated multicast stream. In other words, the unicast burst catches up with the primary multicast stream 🍓 At that point, the RTP receiver no longer needs the unicast burst and can join the SSM session. This method is called Rapid Acquisition of Multicast RTP Sessions (RAMS) 💅
This document defines extensions to [RFC4585] so an RTP receiver can request a unicast burst, and it also defines additional control messaging that can be used during the acquisition process ✨
6.2. Message Flows 🦋
As shown in Figure 2, the main entities involved in rapid acquisition, and their message flows, are:
- Multicast Source
- Feedback Target (FT)
- Burst/Retransmission Source (BRS)
- RTP Receiver (RTP_Rx)
----------- --------------
| |------------------------------------>| |
| |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| |
| | | |
| Multicast | ---------------- | |
| Source | | Retransmission | | |
| |-------->| Server (RS) | | |
| |.-.-.-.->| | | |
| | | ------------ | | |
----------- | | Feedback | |<.=.=.=.=.| |
| | Target (FT)| |<~~~~~~~~~| RTP Receiver |
PRIMARY MULTICAST | ------------ | | (RTP_Rx) |
RTP SESSION with | | | |
UNICAST FEEDBACK | | | |
| | | |
- - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- -
| | | |
UNICAST BURST | ------------ | | |
(or RETRANSMISSION) | | Burst/ | |<~~~~~~~~>| |
RTP SESSION | | Retrans. | |.........>| |
| |Source (BRS)| |<.=.=.=.=>| |
| ------------ | | |
| | | |
---------------- --------------
-------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages
.......> Unicast RTP Flow
Figure 2: Flow Diagram for Unicast-Based Rapid AcquisitionAs defined in [RFC5760], the feedback target (FT) is the entity the RTP_Rx sends its RTCP feedback messages to. Those messages either report packet loss with an RTCP NACK message, or show that RTP_Rx wants to rapidly acquire the primary multicast RTP session using an RTCP feedback message defined in this document 🎀 The Burst/Retransmission Source (BRS) is responsible for responding to these messages and for further RTCP interaction with the RTP_Rx during a rapid acquisition. In the rest of this document, it's assumed that these two logical entities (FT and BRS) are combined into one physical entity that shares state 💜 From here on, the term Retransmission Server (RS) is used wherever it fits, to mean that single physical entity 👑
So the FT is hanging out in the primary multicast RTP session and getting unicast feedback for it, as in [RFC5760] 💖. The BRS is the one in the unicast burst (or retransmission) RTP session, sending burst and retransmission packets formatted as RTP retransmission packets [RFC4588] in a single separate unicast RTP session to each RTP_Rx ✨. In that unicast burst session, the BRS and RTP_Rx both keep sending their regular sender and receiver reports 🦋.
The unicast burst kicks off with an RTCP feedback message that this document defines, built on the common packet format from [RFC4585] 🎀. A retransmission gets triggered by an RTCP NACK message from [RFC4585] 🔁. Both of these go to the FT of the primary multicast RTP session, and either one can start the unicast burst/retransmission RTP session 🌸.
Now, the extended RTP profile for RTCP-based feedback (RTP/Audio-Visual Profile with Feedback (AVPF)) has rules about when these messages can be scheduled toward the FT in the primary multicast RTP session 📅. They're spelled out in Section 3.5 of [RFC4585]. One rule says that in a multi-party session like the SSM sessions this specification is about, an RTP_Rx can't send an RTCP feedback message until at least one second after it joins (that's Tmin=1.0 second) 🙈. Honestly, that rule exists to stop flash-crowd problems in typical multi-party sessions, but it totally defeats the whole point of rapid acquisition 😭. And even if receivers wait a fixed or random amount before asking for a burst, nothing changes, because those requests aren't related to each other and their timings are independent 💀. So this specification sets Tmin to zero and lets RTP receivers send a burst request right away at the very beginning 🚀. For later messages during rapid acquisition, like updated requests, the timing rules from [RFC4585] still apply ⏰.
Here's an example of the message flow for rapid acquisition, Figure 3 🗺️. The RTCP feedback messages get explained below. Optional messages are in parentheses, and they may or may not show up during rapid acquisition 🤷♀️. If the feedback target is sitting on the same box as the media sender, the same method and identical message flows still work 💅.
-------------------------
| Retransmission Server |
----------- | ------ ------------ | -------- ------------
| Multicast | | | FT | | Burst/Ret. | | | | | RTP |
| Source | | | | | Source | | | Router | | Receiver |
| | | ------ ------------ | | | | (RTP_Rx) |
----------- | | | | -------- ------------
| ------------------------- | |
| | | | |
|-- RTP Multicast ---------->--------------->| |
|-. RTCP Multicast -.-.-.-.->-.-.-.-.-.-.-.->| |
| | | | |
| | |********************************|
| | |* PORT MAPPING SETUP *|
| | |********************************|
| | | | |
| |<~~~~~~~~~~~~~~~~~~~~~~~~~ RTCP RAMS-R ~~~|
| | | | |
| | |********************************|
| | |* UNICAST SESSION ESTABLISHED *|
| | |********************************|
| | | | |
| | |~~~ RTCP RAMS-I ~~~~~~~~~~~~~~~>|
| | | | |
| | |... Unicast RTP Burst .........>|
| | | | |
| |<~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP RAMS-R) ~~|
| | | | |
| | |~~ (RTCP RAMS-I) ~~~~~~~~~~~~~~>|
| | | | |
| | | | |
| | | |<= SFGMP Join ==|
| | | | |
|-- RTP Multicast ------------------------------------------->|
|-. RTCP Multicast -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>|
| | | | |
| | | | |
| | |<~~~~~~~~~~~~~~~ RTCP RAMS-T ~~~|
| | | | |
: : : : :
| | |<.=.= Unicast RTCP Reports .=.=>|
: : : for the unicast session :
| | | | |
-------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages
=======> SFGMP Messages
.......> Unicast RTP FlowFigure 3: Message Flows for Unicast-Based Rapid Acquisition
This document spells out how the RS and RTP_Rx are expected to behave 🎭. It's super helpful to picture independent implementations on the RS and on the RTP_Rx that ask for the burst, describe it, start it, join the multicast session, and stop it 🧠. Those implementations message each other, but we need safety nets for when control messages get lost, arrive out of order, or never reach their destination 🫣.
The following steps walk through rapid acquisition in detail 👑:
- Port Mapping Setup: For the primary multicast RTP session, the RTP and RTCP destination ports are declared ahead of time (see Section 8 for SDP examples) 📝. But the
RTP_Rxhas to pick its own RTP and RTCP receive ports for the unicast burst RTP session 🔌. This unicast session only gets set up after theRTP_Rxhas sent a RAMS Request (RAMS-R) as unicast feedback in the primary multicast RTP session, so theRTP_RxMUST first set up the port mappings between the unicast and multicast sessions and send that mapping info to the FT along with the RAMS-R message, so the BRS knows how to reach it 🗺️. The details of that setup are in [RFC6284]. Other NAT-related stuff is saved for Section 9 so we can keep focused on the RAMS message flows 🙌. - Request: The
RTP_Rxsends a rapid acquisition request (RAMS-R) for the primary multicast RTP session to the unicast feedback target of that session 📬. The request carries the SSRC identifier of theRTP_Rx(aka SSRC of packet sender), and it can also include the media sender SSRC identifier(s) of the primary multicast stream(s) it wants (aka SSRC of media source) 🎯. The RAMS-R message can include parameters that limit the burst, like buffer and bandwidth limits 📏.
Before joining the SSM session, the RTP_Rx learns the addresses for the multicast source, group, and RS through out-of-band means 🕵️♀️. If the RTP_Rx only wants to rapidly acquire a subset of the primary multicast streams in the primary multicast RTP session, it MUST also get the SSRC identifiers for those desired RTP streams out-of-band 🔑. With that info, the RTP_Rx fills in the desired SSRC(s) in the RAMS-R message 💌.
When the FT successfully receives the RAMS-R message, the BRS responds by either accepting or rejecting the request 🥹. Right before the BRS sends any of the RTP or RTCP packets described below, it sets up the unicast burst RTP session 🚀.
- Response: The BRS sends RAMS Information (RAMS-I) message(s) to the
RTP_Rxto share the status of the burst(s) theRTP_Rxasked for 📨.
If the primary multicast RTP session tied to the FT_Ap (a specific feedback target running on a particular address and port) where the RAMS-R message arrived contains only one primary multicast stream, the BRS SHALL always use the SSRC of the RTP stream tied to the FT_Ap in the RAMS-I message(s), no matter what media sender SSRC the RAMS-R message asked for 🫶. In that case, the ssrc attribute MAY be left out of the media description. If the requested SSRC and the actual media sender SSRC don't match, the BRS MUST explicitly put the correct media sender SSRC in the initial RAMS-I message (see Section 7.3) 🔧.
The FT_Ap could also be tied to an RTP session carrying two or more primary multicast streams 🌈. If the RTP_Rx wants a collective request to receive the whole primary multicast RTP session, it doesn't need ssrc attributes described in the media description 💜.
If the FT_Ap is tied to two or more RTP sessions, the RTP_Rx's request would be ambiguous 😵💫. To avoid that confusion, each FT_Ap MUST be associated with only a single RTP session 🧁.
If the RTP_Rx only wants to rapidly acquire a subset of the primary multicast streams, the RTP_Rx MUST list all the media sender SSRC(s) for the streams it wants in the RAMS-R message 📋. When it gets such a message, the BRS MAY accept the request for all of those SSRC(s), or just a subset, as long as they match the RTP stream(s) it serves 🍓. The BRS MUST reject all other requests with an appropriate response code ❌.
- Reject Responses: The BRS MUST take into account any limitations the
RTP_Rxspecified in the RAMS-R message when deciding on the request 🧐. If theRTP_Rxasked for the whole primary multicast RTP session but the BRS can't provide rapid acquisition for any of the primary multicast streams, the BRS MUST reject the request with a single RAMS-I message carrying a collective reject response code, which is defined as 510 in Section 11.6, and whose media sender SSRC field is set to one of the SSRCs served by this FT_Ap 🙅♀️. When theRTP_Rxgets that RAMS-I message, it gives up on the rapid acquisition attempt and can immediately join the multicast session by sending an SFGMP Join message toward its upstream multicast router 🏃♀️💨.
In every other case, the BRS MUST send a separate RAMS-I message, with the appropriate 5xx-level response code (as defined in Section 11.6), for each primary multicast stream the RTP_Rx requested that the BRS can't serve 📮. There could be lots of reasons the BRS rejected the request, but the BRS picks the most appropriate response code to tell the RTP_Rx 🤓✨.
Okay bestie, picking up right where the reject responses left off 🎀
If the RTP_Rx gets a reject response that signals a transient problem, like insufficient BRS or network resources, and it wants to retry the same request, it MUST follow the RTCP timer rules of [RFC4585] so those transient problems have time to go away 🕰️✨ But if the reject response points to a non-transient problem (like the ones reported by response codes 504, 505, and 506), the RTP_Rx MUST NOT attempt a retry 🚫 Different response codes have different scopes, so check Section 7.3.1 for the deets 📚
The BRS can run a policing mechanism against broken RTP_Rx implementations that aren't following these rules 👀 See Section 10 for the tea ☕
- Accept Responses: The BRS MUST send at least one separate RAMS-I message with the right response code for each primary multicast stream that the RTP_Rx requested and the BRS will serve 💌 That's either
0(a private response) or200(success), as listed in Section 11.6 💖 These RAMS-I messages have fields that describe the individual unicast burst streams 🦋 If a RAMS-R request covers multiple primary multicast streams, the BRS MUST include all the individual RAMS-I messages for that RAMS-R request in the same compound RTCP packet, as long as they fit in one packet 📦✨ Also, if the BRS is only sending the preamble info and not the whole unicast burst stream, it won't accept the request. Instead it sends response code511, as defined in Section 11.6 🙅♀️
The RAMS-I message carries the RTP sequence number of the first packet sent in the respective RTP stream, so the RTP_Rx can spot any missing initial packet(s) 🔍 When the BRS accepts a request for a primary multicast stream, this field MUST always be populated in the RAMS-I message(s) sent for that stream 🫶 It is RECOMMENDED that the BRS sends a RAMS-I message at the start of the burst so the RTP_Rx can catch missing initial packet(s) quickly ⚡
It's possible that the RAMS-I message for a primary multicast stream gets delayed or lost, and the RTP_Rx can start receiving RTP packets before it gets a RAMS-I message 😭 An RTP_Rx implementation MUST NOT assume it'll quickly receive the initial RAMS-I message 🙅♀️ For redundancy, it is RECOMMENDED that the BRS repeats the RAMS-I messages multiple times, as long as it follows the RTCP timer rules defined in [RFC4585] 🔁💜
- Unicast Burst: For the primary multicast stream(s) whose request was accepted, the BRS starts sending the unicast burst(s), made of one or more RTP retransmission packets sent in the unicast burst RTP session 🚀 In some applications, the BRS can also send preamble information to the RTP_Rx, on top of the requested burst, to prime the media decoder(s) 🎬 But for the BRS to send preamble information in a particular format, the RTP_Rx has to explicitly signal it 🙋♀️ In other words, the BRS MUST NOT send preamble information in a particular format unless the RTP_Rx has signaled support for that format in the RAMS-R message, through a public or private extension as defined in Section 7.1 🧩
The format of this preamble data is RTP-payload specific and not specified here 🤷♀️
- Updated Request: The RTP_Rx MAY send an updated RAMS-R message (as unicast feedback in the primary multicast RTP session) with a different value for one or more fields of an earlier RAMS-R message 🔄 The BRS MUST be able to detect whether a burst is already planned for, or being transmitted to, this particular RTP_Rx for this particular media sender SSRC 🕵️♀️ If there's an existing burst planned or being transmitted, the newly arriving RAMS-R is an updated request. Otherwise, it's a new request 🆕 It's also possible the RTP_Rx sent an improperly formatted RAMS-R message or used an invalid value in it 🙈 If the BRS notifies it with a 4xx-level response code (as defined in Section 11.6), the RTP_Rx MAY resend its corrected request, but only after following the timing rules of [RFC4585] ⏰
The BRS figures out who's asking by looking at the canonical name identifier (the CNAME item in the source description (SDES)) 🪪 So the RTP_Rx MUST choose a method that ensures it uses a unique CNAME identifier 🔐 Such methods are provided in [RFC6222] 💅 Besides one or more fields with updated values, an updated RAMS-R message may also include fields whose values didn't change 🧁
When the BRS gets an updated request, it can use the updated values to send or shape the burst, or refine the values and use the refined ones instead 🎛️ After that, the BRS MAY send an updated RAMS-I message in the unicast burst RTP session to show the changes it made 📝
Whether and when an RTP_Rx sends an updated request is an implementation-dependent decision 🧠 But heads up: updated request messages can get delayed and arrive at the BRS after the initial unicast burst is already done 😬 In that case, the updated request can trigger a new unicast burst, and if the RTP_Rx has already started receiving multicast data by then, congestion is likely to happen 🚦 The RTP_Rx can only detect this after a delay, and then it can try to terminate the new burst. Meanwhile, the RTP_Rx can experience packet loss or other problems 😵💫 This and other similar corner cases SHOULD be carefully examined if updated requests are going to be used 🔍
- Updated Response: The BRS can send more than one RAMS-I message in the unicast burst RTP session, for example to update the value of one or more fields in an earlier RAMS-I message 📨 Those updated RAMS-I messages might or might not be a direct response to a RAMS-R message 🤷♀️ The BRS can also send updated RAMS-I messages to tell the RTP_Rx in real time to join the SSM session, even after it already sent an initial RAMS-I message (for example at the start of the burst) 🎯 The RTP_Rx depends on the BRS to learn the join time, which can be conveyed by the first RAMS-I message or sent or revised in a later RAMS-I message ⏱️ If the BRS can't determine the join time in the initial RAMS-I message, it MUST send another RAMS-I message with the join time information later 📬
- Multicast Join Signaling: The RAMS-I message lets the BRS explicitly signal when the RTP_Rx needs to send the SFGMP Join message 🛎️ The RTP_Rx SHOULD use this information from the most recent RAMS-I message, unless it has more accurate information 🎯 If the request is accepted, this information MUST be conveyed in at least one RAMS-I message, and its value MAY be updated by subsequent RAMS-I messages 🔁
Packets can go missing if the RTP_Rx joins the multicast session too early or too late 😱 For example, if the RTP_Rx starts receiving the primary multicast stream while it's still receiving the unicast burst at a high excess bitrate, that can raise the risk of packet loss 📉 Or, if the RTP_Rx joins the multicast session some time after the unicast burst finishes, there can be a gap between the burst and the multicast data (a number of RTP packets might be missing) 🕳️ In both cases, the RTP_Rx can issue retransmission requests (via RTCP NACK messages sent as unicast feedback in the primary multicast RTP session) [RFC4585] to the FT entity of the RS to fill the gap 🧷 The BRS might or might not respond to those requests. When it does respond, and the response causes significant changes in one or more values reported earlier to the RTP_Rx, an updated RAMS-I SHOULD be sent to the RTP_Rx 💌
- Multicast Receive: After the join, the RTP_Rx starts receiving the primary multicast stream(s) 🎶
- Terminate: The BRS can work out when it needs to stop the unicast burst based on its parameters 🧮 However, the RTP_Rx may need to ask the BRS to end the burst early, or at a specific sequence number 🛑 For that, the RTP_Rx uses the RAMS Termination (RAMS-T) message, sent as RTCP feedback in the unicast burst RTP session 📤 A separate RAMS-T message is sent for each primary multicast stream served by the BRS, unless an RTCP BYE message has been sent in the unicast burst RTP session as described in Step 10 🙌 For burst requests the BRS rejected, there's no need to send a RAMS-T message 🙅♀️
If the RTP_Rx wants to end a burst early, it MUST send a RAMS-T message for the SSRC of the primary multicast stream it wants to terminate 🛑 This message goes in the unicast burst RTP session 📨 When the BRS gets this message, it MUST terminate the unicast burst 💥 If the RTP_Rx requested the entire primary multicast RTP session but wants to cancel before it learns the individual media sender SSRC(s) through RAMS-I message(s) or RTP packets, it can't use RAMS-T messages, so it MUST send an RTCP BYE message in the unicast burst RTP session to terminate the request 🫠
Otherwise, the default behavior for the RTP_Rx is to send a RAMS-T message in the unicast burst RTP session right after it joins the multicast session and has started receiving multicast packets ✨ In that case, the RTP_Rx MUST send a RAMS-T message with the sequence number of the first RTP packet received in the primary multicast stream 🎯 Then the BRS MUST terminate the respective burst after it sends the unicast burst packet whose Original Sequence Number (OSN) field in the RTP retransmission payload header matches this number minus one 🧮 If the BRS has already sent that unicast burst packet when the RAMS-T message arrives, the BRS MUST terminate the respective burst immediately ⚡
If an RTCP BYE message hasn't been issued yet as described in Step 10, the RTP_Rx MUST send at least one RAMS-T message for each primary multicast stream served by the BRS 📬 The RAMS-T message(s) MUST be sent to the BRS in the unicast burst RTP session 📡 To guard against message loss, it is RECOMMENDED that the RTP_Rx repeats the RAMS-T messages multiple times, as long as it follows the RTCP timer rules defined in [RFC4585] 🔁💖
The binding between RAMS-T and ongoing bursts is achieved through the RTP_Rx's CNAME identifier, plus the packet sender and media sender SSRCs 🧷 Choosing a globally unique CNAME makes sure the RAMS-T messages get processed correctly 🌈
- Terminate with RTCP BYE 💌: okay so, when the RTP_Rx is receiving one or more burst streams and it's no longer interested in acquiring any of the primary multicast streams, the RTP_Rx SHALL issue an RTCP BYE message for the unicast burst RTP session and another RTCP BYE message for the primary multicast RTP session. These get sent to the BRS and FT logical entities, respectively. 🎀
Upon receiving an RTCP BYE message, the BRS MUST terminate the rapid acquisition operation and cease transmitting any further burst packets and retransmission packets. 🛑 If support for [RFC5506] has been signaled, the RTCP BYE message MAY be sent in a reduced-size RTCP packet. Otherwise, Section 6.1 of [RFC3550] mandates the RTCP BYE message always be sent with a sender or receiver report in a compound RTCP packet. If no data has been received, an empty receiver report MUST be still included. 📦 With the information in that receiver report, the RS can figure out how many duplicate RTP packets have been delivered to the RTP_Rx. This is an upper-bound estimate, since one or more packets might have been lost during the burst transmission. 🧮 The impact of duplicate packets, and the measures that can be taken to minimize that impact, will be addressed in Section 6.4. 🫶
Since an RTCP BYE message issued for the unicast burst RTP session terminates that session and ceases transmitting any further packets in it, there is no need for sending explicit RAMS-T messages. Those would only terminate their respective bursts, and the BYE already handles that. 💅
For the purpose of gathering detailed information about RTP_Rx's rapid acquisition experience, [MULTICAST-ACQ] defines an RTCP Extended Report (XR) Block. 📊 This report is designed to be payload-independent, so any multicast application that supports rapid acquisition can use it. 🌈
6.3. Synchronization of Primary Multicast Streams ✨
So when an RTP_RX acquires multiple primary multicast streams, it might need to synchronize them for playout. 🎶 This synchronization is achieved with the help of the RTCP sender reports [RFC3550]. If the playout will start before the RTP_Rx has joined the multicast session, the RTP_Rx needs to receive the information reflecting the synchronization among the primary multicast streams early enough, so it can play out the media in a synchronized fashion. ⏰
The suggested approach is to use the RTP header extension mechanism [RFC5285] and convey the synchronization information in a header extension as defined in [RFC6051]. 🧩 Per [RFC4588], "if the original RTP header carried an RTP header extension, the retransmission packet SHOULD carry the same header extension". 🔁 So as long as the multicast source emits a header extension with the synchronization information frequently enough, the BRS doesn't have any extra work to do. 🙌 The synchronization information will be sent to the RTP_Rx along with the burst packets. The frequent header extensions sent in the primary multicast RTP sessions also allow rapid synchronization of the RTP streams for RTP receivers that don't support RAMS or that join the multicast session directly without running RAMS. 🥰 So in RAMS applications, it is RECOMMENDED that the multicast sources frequently send synchronization information by using header extensions, following the rules presented in [RFC6051]. The regular sender reports are still sent in the unicast session, following the rules of [RFC3550]. 📨
6.4. Burst Shaping and Congestion Control in RAMS 🌊
This section provides informative guidelines about how the BRS can shape the transmission of the unicast burst, and how congestion can be dealt with in the RAMS process. 🧠 When the RTP_Rx detects that the unicast burst is causing severe congestion, it can prefer to send a RAMS-T message immediately to stop the unicast burst. 🚨
A higher bitrate for the unicast burst naturally gets the Reference Information and media content to the RTP_Rx faster. 🏎️ That way, the RTP_Rx can start consuming the data sooner, which results in a faster acquisition. A higher bitrate also means better utilization of the BRS resources. 💪 As the burst may continue until it catches up with the primary multicast stream, the higher the bursting bitrate, the less data the BRS needs to transmit. However, a higher bitrate for the burst also increases the chances of congestion-caused packet loss. 😬 So, as discussed in Section 5, there has to be an upper bound on the bandwidth used by the burst. 🚧
When the BRS transmits the unicast burst, it is expected to take into account all available information to prevent any packet loss that might happen during the bursting because of buffer overflow on the path between the RS and RTP_Rx, and at the RTP_Rx itself. 🫧 The bursting bitrate can be determined by taking into account the following information, when available:
- (a) Information obtained via the RAMS-R message, such as Max RAMS Buffer Fill Requirement and/or Max Receive Bitrate (see Section 7.2). 📬
- (b) Information obtained via RTCP receiver reports provided by the RTP_Rx in the retransmission session, allowing in-session bitrate adaptations for the burst. When these receiver reports indicate packet loss, this can indicate a certain congestion state in the path from the RS to the RTP_Rx. 📉
- (c) Information obtained via RTCP NACKs provided by the RTP_Rx in the primary multicast RTP session, allowing in-session bitrate adaptations for the burst. Such RTCP NACKs are transmitted by the RTP_Rx in response to packet loss detection in the burst. NACKs can indicate a certain congestion state on the path from the RS to RTP_Rx. 🙋♀️
- (d) There can be other feedback received from the RTP_Rx, e.g., in the form of Explicit Congestion Notification - Congestion Experienced (ECN-CE) markings [ECN-FOR-RTP] that can influence in-session bitrate adaptation. 🚦
- (e) Information obtained via updated RAMS-R messages, allowing in-session bitrate adaptations, if supported by the BRS. 🔄
- (f) Transport protocol-specific information. For example, when Datagram Congestion Control Protocol (DCCP) is used to transport the RTP burst, the ACKs from the DCCP client can be leveraged by the BRS / DCCP server for burst shaping and congestion control. 🧦
- (g) Preconfigured settings for each RTP_Rx, or a set of RTP_Rxs, that indicate the upper-bound bursting bitrates for which no packet loss will occur as a result of congestion along the path of the RS to RTP_Rx. For example, in managed IPTV networks, where the bottleneck bandwidth along the end-to-end path is known, and where the network between the RS and this link is provisioned and dimensioned to carry the burst streams, the bursting bitrate does not exceed the provisioned value. These settings can also be dynamically adapted using application-aware knowledge. 🎛️
The BRS chooses the initial burst bitrate as follows:
- When using RAMS in environments as described in (g), the BRS MUST transmit the burst packets at an initial bitrate higher than the nominal bitrate, but within the engineered or reserved bandwidth limit. 🚀
- When the BRS cannot determine a reliable bitrate value for the unicast burst (using (a) through (g)), it is desirable for the BRS to choose an appropriate initial bitrate not above the nominal bitrate, and increase it gradually unless congestion is detected. 🐢
In both cases, during the burst transmission, the BRS MUST continuously monitor for packet losses as a result of congestion, by means of one or more of the mechanisms described in (b) through (f). 👀 When the BRS relies on RTCP receiver reports, sufficient bandwidth needs to be provided to the RTP_Rx for RTCP transmission in the unicast burst RTP session. To achieve a reasonably fast adaptation against congestion, it is recommended that the RTP_Rx sends a receiver report at least once every two RTTs between the RS and RTP_Rx. ⏱️ Although the specific heuristics and algorithms that deduce a congestion state, and how the BRS acts subsequently, are outside the scope of this specification, the following two methods are the best practices:
- Upon detection of a significant amount of packet loss, which the BRS attributes to congestion, the BRS decreases the burst bitrate. The rate by which the BRS increases and decreases the bitrate for the burst can be determined by a TCP-friendly bitrate adaptation algorithm for RTP over UDP or, in the case of (f), by the congestion control algorithms defined in DCCP [RFC5762]. 📚
- If the congestion is persistent and the BRS has to reduce the burst bitrate to a point where the RTP_Rx buffer might underrun, or the burst will consume too many resources, the BRS terminates the burst and transmits a RAMS-I message to the RTP_Rx with the appropriate response code. It is then up to the RTP_Rx to decide when to join the multicast session. 🫡
Even though there is no congestion experienced during the burst, congestion may still arise near the end of the burst, as the RTP_Rx eventually needs to join the multicast session. During this brief period, both the burst packets and the multicast packets can be received simultaneously by the RTP_Rx, which raises the risk of congestion. 😵💫
Since the BRS signals the RTP_Rx when the BRS expects the RTP_Rx to send the SFGMP Join message, the BRS can have a rough estimate of when the RTP_Rx will start receiving multicast packets in the SSM session. 🔮 The BRS can keep sending burst packets, but reduces the bitrate accordingly at the appropriate instant by taking the bitrate of the whole SSM session into account. If the BRS ceases transmitting the burst packets before the burst catches up, any gap resulting from this imperfect switch-over by the RTP_Rx can later be repaired by requesting retransmissions for the missing packets from the RS. 🩹 The retransmissions can be shaped by the BRS to make sure they don't cause collateral loss in the primary multicast RTP session or the unicast burst RTP session. 🫶
6.5. Failure Cases 💔
Okay bestie, let's talk about when things go sideways 😭 In this section we look at what happens if the RAMS-R, RAMS-I, or RAMS-T messages get lost, plus a few other failure cases. The chaos is real, but it's all handled 💅
When the RTP_Rx sends a RAMS-R message to start a rapid acquisition and the message gets lost so the FT never receives it, the RTP_Rx won't get a RAMS-I message or a unicast burst. In that case the RTP_Rx MAY resend the request once it's allowed to, based on the RTCP timer rules in [RFC4585]. Or, after a reasonable amount of time, it can time out (based on the response times it saw earlier) and join the SSM session right away 🏃♀️
If the RTP_Rx starts receiving a unicast burst but doesn't get a matching RAMS-I message within a reasonable amount of time, it has two options. It can throw out the burst data, or it can leave the unicast burst alone and get ready to join the SSM session at a time it picks, or at whatever time a later RAMS-I message says (if one shows up) 🫶 Also, if the network has packet loss, it is RECOMMENDED that the BRS repeats the RAMS-I messages multiple times, based on the RTCP timer rules in [RFC4585] 🔁
When the RAMS-I message is lost, or the RAMS-R message is lost and the RTP_Rx gives up, the RTP_Rx MUST still terminate the burst(s) it requested by following the rules in Section 6.2. No ghosting the burst, periodt 🙅♀️
Now, if a RAMS-T message sent by the RTP_Rx never reaches its destination, the BRS can keep sending burst packets even though the RTP_Rx doesn't need them anymore. If an RTP_Rx is still getting burst packets it no longer needs after sending a RAMS-T message, it is RECOMMENDED that the RTP_Rx repeats the RAMS-T message multiple times, based on the RTCP timer rules in [RFC4585]. The BRS MUST be provisioned to terminate the burst once it can no longer send the burst packets faster than it receives the primary multicast stream packets 🛑
Section 6.3.5 of [RFC3550] explains the rules for timing out an SSRC. Once the BRS agrees to serve the requested burst(s) and sets up the retransmission session, it needs to check that the RTP_Rx is still alive using the RTCP messages and reports the RTP_Rx sends. The default rules in [RFC3550] apply in RAMS as well, so nothing new to memorize here ✨
7. Encoding of the Signaling Protocol in RTCP 🎀
This section defines the formats of the RTCP transport-layer feedback messages exchanged between the retransmission server (RS) and the RTP receiver (RTP_Rx) during rapid acquisition. These messages are called the RAMS Messages. They are payload-independent, and they MUST be used by all RTP-based multicast applications that support rapid acquisition, no matter what payload they carry 🦋
Payload-specific feedback messages are not defined in this document. That said, further optional payload-independent and payload-specific information can be included in the exchange 💜
The common packet format for the RTCP feedback messages is defined in Section 6.1 of [RFC4585], and it's sketched in Figure 4 below 👀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :Figure 4: The Common Packet Format for the RTCP Feedback Messages
Each feedback message has a fixed-length section with version, padding, feedback message type (FMT), packet type (PT), length, SSRC of packet sender, and SSRC of media source, plus a variable-length section for feedback control information (FCI) 🧩
In the RAMS messages, the PT field is set to RTPFB (205) and the FMT field is set to RAMS (6). Each individual RAMS message is identified by a sub-field called the sub-feedback message type (SFMT). Any Reserved field SHALL be set to zero and ignored 🔥
Depending on the scenario and how timely or important a RAMS message is, it can be useful to send it in a reduced-size RTCP packet [RFC5506]. But unless support for [RFC5506] has been signaled, compound RTCP packets MUST be used by following the [RFC3550] rules 📦
Following the rules in [RFC3550], all integer fields in the messages below are carried in network-byte order, meaning most significant byte (octet) first, also known as big-endian. Unless otherwise stated, numeric constants are in decimal (base 10) 🔢
7.1. Extensions 🌈
To improve the functionality of the RAMS method in certain applications, it can be useful to define new fields in the RAMS Request, Information, and Termination messages. Such fields MUST be encoded as Type-Length-Value (TLV) elements, described below and sketched in Figure 5 ✨
- Type: A single-octet identifier that defines the type of the parameter represented in this TLV element.
- Length: A two-octet field that indicates the length (in octets) of the TLV element, excluding the Type and Length fields and the 8-bit Reserved field between them. This length does not include any padding needed for alignment.
- Value: A variable-size set of octets that contains the specific value for the parameter.
In the extensions, the Reserved field SHALL be set to zero and ignored. If a TLV element doesn't fall on a 32-bit boundary, the last word MUST be padded to the boundary using further bits set to zero 🧸
An RTP_Rx or BRS MAY include vendor-neutral and private extensions in any RAMS message. The RTP_Rx or BRS MUST place such extensions after the mandatory fields and mandatory TLV elements (if any), and it MAY place such extensions in any order. The RTP_Rx or BRS MUST NOT include multiple TLV elements with the same Type value in a RAMS message 🚫
Support for extensions (unless specified otherwise) is OPTIONAL. An RTP_Rx or BRS that receives a vendor-neutral or private extension it doesn't understand MUST ignore that extension 🙈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: Structure of a TLV Element
7.1.1. Vendor-Neutral Extensions 🌸
If the goal of defining new TLV elements is to extend the functionality in a vendor-neutral way, they MUST be registered with IANA using the guidelines in Section 11.5 📋
The current document defines several vendor-neutral extensions in the subsequent sections 💖
7.1.2. Private Extensions 🕵️♀️
It's desirable to let vendors use private extensions in a TLV format. For interoperability, these extensions must not collide with each other 🤝
A certain range of TLV Types (between and including 128 and 254 ) is reserved for private extensions (refer to Section 11.5). IANA management of these extensions is unnecessary, and they are the responsibility of individual vendors 🧁
The structure that MUST be used for private extensions is shown in Figure 6. Here, the enterprise numbers are as listed on http://www.iana.org. This ensures the uniqueness of private extensions and avoids any collision 🔐
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: Structure of a Private Extension
7.2. RAMS Request ✨
Okay bestie, the RAMS Request (RAMS-R) message is identified by SFMT=1 💖. It gets sent as unicast feedback in the primary multicast RTP session by the RTP_Rx 🦋, and it asks for rapid acquisition of either a whole primary multicast RTP session or one or more primary multicast streams that belong to that same session. 🌸
In the RAMS-R message, the RTP_Rx MUST set both the packet sender SSRC and media sender SSRC fields to its own SSRC, since the media sender SSRC may not be known 🙈. The RTP_Rx MUST also provide explicit signaling, as described below, to request stream(s). This is lowkey genius because it minimizes the chances of accidentally requesting a wrong primary multicast stream 💅.
The FCI field MUST contain only one RAMS Request. The FCI field has the structure shown in Figure 7 🎀.
The semantics of the RAMS-R message do not depend on the payload type carried in the primary multicast RTP session. It's giving payload-agnostic energy ✨.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Requested Media Sender SSRC(s) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: FCI Field Syntax for the RAMS Request Message
Requested Media Sender SSRC(s): this one is a mandatory TLV element 🧚 that lists the media sender SSRC(s) the RTP_Rx is asking for. The BRS MUST ignore the media sender SSRC specified in the header of the RAMS-R message 👑.
If the Length field is set to zero (meaning no media sender SSRC is listed), the RTP_Rx is asking to rapidly acquire the entire primary multicast RTP session 🌈. Otherwise, the RTP_Rx lists the individual media sender SSRCs in this TLV element and sets the Length field of the TLV element to 4*n, where n is the number of SSRC entries.
Type: 1
Min RAMS Buffer Fill Requirement(32 bits): this is an optional TLV element 🍓 that shows the minimum number of milliseconds of data the RTP_Rx wants in its buffer before the application is allowed to consume it.
The RTP_Rx knows its own buffering requirements, and those can be application and/or device specific 💜. For example, the RTP_Rx might need a certain amount of data in its application buffer to handle transmission jitter and/or to support error-control methods 😭. If the BRS is told the minimum buffering requirement of the receiver, the BRS can tailor the burst(s) more precisely, for example by choosing an appropriate starting point ✨. The methods the RTP_Rx uses to figure out this value are application specific, so they're out of scope for this document 🙈.
If specified, the amount of backfill provided by the unicast bursts and any payload-specific information MUST NOT be smaller than the specified value. Otherwise, the backfill won't be able to build up the desired buffer level at the RTP_Rx, and that can cause buffer underruns 💀.
Type: 2
Max RAMS Buffer Fill Requirement(32 bits): this is an optional TLV element 🌸 that shows the maximum number of milliseconds of data the RTP_Rx can buffer without losing data to buffer overflow.
Again, the RTP_Rx knows its buffering limits, and those can be application or device specific 🦋. One receiver might have more physical memory than another, so it can buffer more data 💅. If the BRS knows the receiver's buffering ability, it can tailor the burst(s) more precisely. The methods the receiver uses to determine this value are application specific and out of scope for this document.
If specified, the amount of backfill provided by the unicast bursts and any payload-specific information MUST NOT be larger than this value. Otherwise, the backfill may cause buffer overflows at the RTP_Rx 😱.
Type: 3
Max Receive Bitrate(64 bits): this is an optional TLV element 🎀 that shows the maximum bitrate (in bits per second) at which the RTP_Rx can process the combined unicast burst(s) and any payload-specific information the BRS will provide. The limits can include local receiver limits as well as network limits the receiver knows about 🌈.
If specified, the total bitrate of the unicast burst(s) plus any payload-specific information MUST NOT be larger than this value. Otherwise, congestion and packet loss are more likely to happen 🔥.
Type: 4
Preamble-only Allowed(0 bits): this is an optional TLV element ⭐ that says the RTP_Rx is happy to receive only the preamble information for the desired primary multicast stream(s), in case the BRS can't send the unicast burst stream(s). (In those cases the BRS won't accept the request, and it will send a response code 511 in the RAMS-I message, as defined in Section 11.6 💀.) Note that the RTP_Rx signals the particular preamble format(s) it supports through a public or a private extension in the same RAMS-R message 🫶.
If this TLV element is not in the RAMS-R message, the BRS MUST NOT respond to the RAMS-R message by sending only the preamble information. Since this TLV element doesn't carry a Value field, the Length field MUST be set to zero 🙃.
Type: 5
Supported Enterprise Number(s): this is an optional TLV element 🧚 that shows the enterprise number(s) the RTP_Rx implementation supports. Like the private extensions, the enterprise numbers here are as listed on http://www.iana.org. If this TLV element exists, it gives the BRS a hint about which private extensions the RTP_Rx might be able to support. The RTP_Rx doesn't necessarily support every private extension under a particular enterprise number 🙈.
Unless the BRS explicitly knows which private extensions an RTP_Rx supports (through this element or some out-of-band means), the BRS SHOULD NOT use private extensions in the RAMS-I messages. The BRS SHOULD rather use only vendor-neutral extensions 🌸. The Length field of this TLV element is set to 4*n, where n is the number of enterprise number entries.
Type: 6
7.3. RAMS Information ✨
okay bestie, so the RAMS Information (RAMS-I) message is identified by SFMT=2 🦋. This is the message the BRS uses to describe the unicast burst it's about to send for rapid acquisition, and it also packs in some other useful info the RTP_Rx needs 💅.
A separate RAMS-I message with the appropriate response code gets sent in the unicast burst RTP session by the BRS for each primary multicast stream the RTP_Rx asked for 💌. In every one of these, the media sender SSRC and packet sender SSRC fields are both set to the SSRC of the BRS, which is the same as the SSRC of that primary multicast stream 🫶.
The FCI field MUST contain only one RAMS Information message. The FCI field has the structure shown in Figure 8 🎀.
The semantics of the RAMS-I message don't depend on the payload type carried in the primary multicast RTP session. It's payload-agnostic and honestly iconic for it 👑.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=2 | MSN | Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: FCI Field Syntax for the RAMS Information Message
A RAMS-I message has the following fields:
- Message Sequence Number (MSN) (8 bits) 🍓: This one's mandatory, and it's the sequence number of the RAMS-I message for the particular media sender SSRC in the message header. The MSN value SHALL be set to zero when a new RAMS request is received. During rapid acquisition, the same RAMS-I message MAY be repeated for redundancy purposes without incrementing the MSN value. If an updated RAMS-I message will be sent (with new or updated info), the MSN value SHALL be incremented by one. The regular wrapping rules apply to the MSN field. Also, if the RTP_Rx has sent an updated request, it MUST check every RAMS-I message entirely, regardless of whether or not the MSN value has changed 🙈.
- Response (16 bits) 💖: This is mandatory and carries the response code for this RAMS-I message. This document defines several initial response codes in Section 7.3.1 and registers them with IANA in Section 11.6. If a new vendor-neutral response code will be defined, it MUST be registered with IANA through the guidelines in Section 11.6. If a new response code is only meant for private use by a vendor, there's no need for IANA management. Instead, the vendor MUST use the private extension mechanism (Section 7.1.2) to convey its message, and MUST indicate this by putting zero in the Response field. Super specific, but it matters 🧚.
When the RTP_Rx receives a RAMS-I message with a response code it doesn't understand, the RTP_Rx MUST send a RAMS-T message immediately to the BRS 🚨.
The following TLV elements have been defined for the RAMS-I messages ✨:
- Media Sender SSRC (32 bits): This is an optional TLV element that specifies the media sender SSRC of the unicast burst stream. If the FT_Ap that received the RAMS-R message is associated with a single primary multicast stream but the requested media sender SSRC doesn't match the SSRC of the RTP stream associated with this FT_Ap, the BRS includes this TLV element in the initial RAMS-I message to let the RTP_Rx know the media sender SSRC has changed. If the two SSRCs match, there's no need to include this TLV element.
- Type:
31
- Type:
- RTP Seqnum of the First Packet (16 bits) 🦋: This TLV element specifies the RTP sequence number of the first packet that will be sent in the respective unicast RTP stream. It lets the RTP_Rx figure out whether one or more packets the BRS sent got dropped at the start of the stream. If the BRS accepts the RAMS request, this element exists. If the BRS rejects the RAMS request, this element SHALL NOT exist.
- Type:
32
- Type:
- Earliest Multicast Join Time (32 bits) ⏰: This TLV element specifies the delta time (in ms) between the arrival of the first RTP packet in the unicast RTP stream (which could be a burst packet or a payload-specific packet) and the earliest time instant when an RTP_Rx MAY send an SFGMP Join message to join the multicast session. A zero value in this element means the RTP_Rx MAY send the SFGMP Join message right away. If the RTP_Rx doesn't want to wait until the earliest multicast join time, it MAY send a RAMS-T message, and after a reasonable amount of time, it MAY join the SSM session.
If the RAMS request has been accepted, the BRS sends this element at least once so the RTP_Rx knows when to join the multicast session. If the burst request has been rejected as indicated in the Response field, this element MUST indicate a zero value. In that case, it's up to the RTP_Rx when or whether to join the multicast session.
When the BRS serves two or more bursts and sends a separate RAMS-I message for each burst, the join times in these RAMS-I messages SHOULD correspond to more or less the same time instant, and the RTP_Rx sends the SFGMP Join message based on the earliest join time 🥹.
- Type:
33
- Burst Duration (32 bits) ⌛: This is an optional TLV element that denotes the time the burst will last (in ms), i.e., the difference between the expected transmission times of the first and last burst packets the BRS is planning to send in the respective unicast RTP stream. Without any additional stimulus, the BRS will send a burst of this duration. However, the burst duration can be changed by subsequent events, including changes in the primary multicast stream and reception of RAMS-T messages.
The BRS MUST terminate the flow within the timeframe indicated by this burst duration (or the duration set by those subsequent events) even if it doesn't get a RAMS-T or a BYE message from the RTP_Rx. It is OPTIONAL to send this element in a RAMS-I message when the burst request is accepted. If the burst request has been rejected as indicated in the Response field, this element MAY be omitted or indicate a zero value.
- Type:
34
- Max Transmit Bitrate (64 bits) 🚀: This is an optional TLV element that denotes the maximum bitrate (in bits per second) the BRS will use for the RTP stream associated with this RAMS-I message.
- Type:
35
- Type:
7.3.1. Response Code Definitions 🌸
1xx-Level Response Codes: These are sent for informational purposes 📣.
100: The BRS uses this when it wants to update a value that was sent earlier to the RTP_Rx.
2xx-Level Response Codes: These are sent to indicate success 🎉.
200: The server uses this when it accepts the RAMS request.201: The BRS uses this when the unicast burst has been completed and it wants to let the RTP_Rx know.
4xx-Level Response Codes: These are sent to indicate that the message the RTP_Rx sent is either improperly formatted or contains an invalid value 🙅♀️. The rules the RTP_Rx needs to follow upon receiving one of these are outlined in Step 5 in Section 6.2. The 4xx-level response codes are also used as status codes in the Multicast Acquisition Report Block [MULTICAST-ACQ] to collect RTP_Rx-based error conditions.
400: The BRS uses this when the RAMS-R message is improperly formatted.401: The BRS uses this when the minimum RAMS buffer fill requirement value in the RAMS-R message is invalid.402: The BRS uses this when the maximum RAMS buffer fill requirement value in the RAMS-R message is invalid.403: The BRS uses this when the maximum receive bitrate value in the RAMS-R message is insufficient.404: The BRS uses this when the RAMS-T message is improperly formatted.
5xx-Level Response Codes: These are sent to indicate an error on the BRS side 😬. The rules the RTP_Rx needs to follow upon receiving one of these are outlined in Step 3 in Section 6.2. The 5xx-level response codes are also used as status codes in the Multicast Acquisition Report Block [MULTICAST-ACQ] to collect BRS-based error conditions.
500: The BRS uses this when it has experienced an internal error and cannot accept the RAMS request.501: The BRS uses this when it doesn't have enough bandwidth to send the unicast burst stream.502: The BRS uses this when it terminates the unicast burst stream due to network congestion.503: The BRS uses this when it doesn't have enough CPU resources to send the unicast burst stream.504: The BRS uses this when it doesn't support sending a unicast burst stream.505: The BRS uses this when the requesting RTP_Rx isn't eligible to receive a unicast burst stream.506: The BRS uses this when RAMS functionality isn't enabled for the requested multicast stream.507: The BRS uses this when it can't find a valid starting point for the unicast burst stream that satisfies the RTP_Rx's requirements.508: The BRS uses this when it can't find the essential reference information for the requested multicast stream.509: The BRS uses this when it can't match the requested SSRC to any of the streams it's serving.510: The BRS uses this when it can't serve the requested entire session.511: The BRS uses this when it sends only the preamble information but not the whole unicast burst stream.512: The BRS uses this when the RAMS request is denied due to a policy for the requested multicast stream, the RTP_Rx, or this particular BRS 🔒.
7.4. RAMS Termination 💅
Okay so, the RAMS Termination (RAMS-T) message is the one with SFMT=3, and it's basically how the RTP_Rx tells the BRS "hey, you can stop the burst now" 🛑✨
The BRS uses it to figure out when it's time to wrap up the burst. The RTP_Rx sends a separate RAMS-T message in the unicast burst RTP session for each primary multicast stream the BRS has been serving 🦋 Now here's the tea: in each RAMS-T message, the media sender SSRC field SHALL BE populated with the SSRC of the media stream that's getting terminated. If that SSRC doesn't match the SSRC of the burst the BRS is serving, the BRS SHALL ignore that RAMS-T message. Not me ignoring the wrong SSRC 🙈
Sometimes the RTP_Rx wants the BRS to stop a burst early, and that's when it sends a RAMS-T message. The second the BRS gets it, the burst stops right away 💨 If the RTP_Rx wants every single burst gone, it has to pack all the matching RAMS-T messages into one compound RTCP packet. Main character energy for sure 👑
The default move for the RTP_Rx is to send a RAMS-T message right after it joins the multicast session and starts receiving multicast packets. In that case, the RTP_Rx puts the sequence number of the first RTP packet it got from the primary multicast stream into the RAMS-T message. With that info, the BRS can figure out when it's safe to end the unicast burst. So smart, I'm obsessed 😭🎀
The FCI field MUST contain only one RAMS Termination. Its structure is shown in Figure 9 below ✨
The semantics of the RAMS-T message don't depend on the payload type carried in the primary multicast RTP session. Iconic, no notes 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: FCI field syntax for the RAMS Termination message
- Extended RTP Seqnum of First Multicast Packet (32 bits): This is an optional TLV element 🧚 It holds the extended RTP sequence number of the first packet received from the SSM session for a particular primary multicast stream. The low 16 bits are the sequence number of that first packet, and the most significant 16 bits extend it with the matching count of sequence number cycles, which can be maintained using the algorithm in Appendix A.1 of [RFC3550]. Type:
61
8. SDP Signaling 🌈
8.1. Definitions
Okay, the rtcp-fb attribute was already defined in [RFC4585], and here we're adding some new syntax to it. Heads up: the feedback type and the optional parameters are all case sensitive, so no sneaky capitals 🙃
In the ABNF below [RFC5234], rtcp-fb-nack-param is used the way [RFC4585] defines it:
rtcp-fb-nack-param =/ SP "rai"This document defines one parameter for use with 'nack':
- 'rai' stands for Rapid Acquisition Indication, and it means RAMS messages (as defined in Section 7) are in use 🦋
This document also defines a brand new media-level SDP attribute, rams-updates. It tells you whether the BRS supports updated request messages 💅 It's used in a declarative way, and no Offer/Answer Model behavior is specified for it. If the BRS supports updated request messages and this attribute shows up in the SDP description, the RTP_Rx can send updated requests. The BRS might or might not be able to accept value changes in every field of an updated RAMS-R message, so it's not guaranteed. But if the rams-updates attribute is NOT included in the SDP description, the RTP_Rx SHALL NOT send updated requests. The RTP_Rx MAY still repeat its initial request without changes, though 🫶
8.2. Requirements
Using SDP to describe the RAMS entities normatively requires support for the following, no skipping 📝
- The SDP grouping framework and flow identification (FID) semantics [RFC5888]
- The RTP/AVPF profile [RFC4585]
- The RTP retransmission payload format [RFC4588]
- The RTCP extensions for SSM sessions with unicast feedback [RFC5760]
- The 'multicast-rtcp' attribute [RFC6128]
- Multiplexing RTP and RTCP on a single port on both endpoints in the unicast session [RFC5761]
- The 'portmapping-req' attribute [RFC6284]
Support for the source-specific media attributes [RFC5576] might also be needed if you're using the ssrc attribute for the media descriptions ✨
8.3. Example and Discussion
This section gives you a declarative SDP [RFC4566] example (for the RTP_Rx side) that shows how to get rapid acquisition of multicast RTP sessions working 🌸 Here it is, in all its glory:
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=Rapid Acquisition Example
t=0 0
a=group:FID 1 2
a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream
c=IN IP4 233.252.0.2/255
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:98 MP2T/90000
a=multicast-rtcp:42000
a=rtcp:43000 IN IP4 192.0.2.1
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack rai
a=ssrc:123321 cname:iptv-ch32@rams.example.com
a=rams-updates
a=portmapping-req:54000 IN IP4 192.0.2.1
a=mid:1
m=video 51000 RTP/AVPF 99
i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1
a=sendonly
a=rtpmap:99 rtx/90000
a=rtcp-mux
a=rtcp:51500
a=fmtp:99 apt=98;rtx-time=5000
a=portmapping-req:55000
a=mid:2Figure 10: Example SDP for a Single-Channel RAMS Scenario
So in this example, there's a primary multicast (source) stream plus a unicast retransmission stream 🎀 The source stream is multicast from a distribution source (source IP address 198.51.100.1) to the multicast destination address 233.252.0.2 on port 41000. The matching RTCP traffic goes to that same multicast address, but on port 42000. We're assuming the multicast RTP and RTCP ports were picked carefully so different RTP and RTCP streams don't collide, which is super important 🙌
The feedback target (FT_Ap) lives on the RS (address 192.0.2.1) at port 43000, and it's declared with the "a=rtcp" line [RFC3605]. Support for conventional retransmission is shown by the "a=rtcp-fb:98 nack" line, so RTP receivers can report missing packets on the source stream to the feedback target and ask for retransmissions 🔁 The SDP includes "a=sendonly" for the retransmission stream's media description, since retransmissions only go one way 💜
Rapid acquisition support is shown by the "a=rtcp-fb:98 nack rai" line. The rtx-time parameter applies to both conventional retransmissions and rapid acquisition. But when rapid acquisition is turned on, the standard definition of rtx-time in [RFC4588] is NOT followed. Instead, rtx-time gives the time in milliseconds that the BRS keeps an RTP packet in its cache for retransmission. That time is measured from when the BRS received the packet, not from the timestamp in the packet itself ⏱️
Once an RTP_Rx has acquired an SDP description, it can ask for rapid acquisition before joining a primary multicast RTP session. To do that, it sends a RAMS-R message to the feedback target of that session 🧚 If the FT_Ap is tied to only one RTP stream, the RTP_Rx doesn't need to learn that stream's SSRC out-of-band. If the BRS accepts the request, it sends a RAMS-I message with the correct SSRC identifier. If the FT_Ap is tied to a multi-stream RTP session and the RTP_Rx wants rapid acquisition for the whole session, it again doesn't need to learn SSRCs out-of-band. But if the RTP_Rx only wants a particular subset of the primary multicast streams, it must learn their SSRC identifiers and list them in the RAMS-R message. Since this RTP_Rx hasn't received any RTP packets for those streams yet, it has to get the SSRC values from the ssrc attribute of the media description [RFC5576]. On top of the SSRC value, the cname source attribute must also be present in the SDP description [RFC5576] 💖
Listing the SSRC values for the primary multicast streams in the SDP file is totally fine in SSM sessions, even when an SSRC collision happens. In SSM sessions, an RTP_Rx that notices an SSRC collision with a media sender has to change its own SSRC [RFC5760], following the rules in [RFC3550] 🌈
A feedback target that gets a RAMS-R message knows the RTP_Rx wants to quickly catch up with a primary multicast RTP session. If the necessary conditions are satisfied (as outlined in Section 7 of [RFC4585]) and resources are available, the BRS can respond to the RAMS-R message by sending any transport-layer feedback message(s) (and optional payload-specific ones, when allowed) and starting the unicast burst 🚀
In this section we looked at the simplest case: the primary multicast RTP session carries only one stream, and the RTP_Rx wants to rapidly acquire just that one. Best practices for scenarios where the session carries two or more streams, or where the RTP_Rx wants to acquire one or more streams from multiple primary multicast RTP sessions at once, are covered in [RAMS-SCENARIOS] 🍓
9. NAT Considerations 🧚
okay so, there can be one or more Network Address Port Translators (NAPT, but we're just calling them NAT, bestie 💅) sitting between the RTP_Rx and the RS. NATs act differently for UDP traffic [RFC4787]. For a NAT to let traffic from the BRS reach the RTP_Rx, the NAT(s) must first either:
- (a) see UDP (or DCCP) traffic sent from the RTP_Rx (which is on the 'inside' of the NAT) to the BRS (which is on the 'outside' of the NAT). This traffic has the same transport address as the subsequent response traffic, or
- (b) be configured to forward certain ports (e.g., using HTML configuration or Universal Plug and Play (UPnP) Internet Gateway Device (IGD) [UPnP-IGD]). Details of this are out of the scope of this document.
For both (a) and (b), the RTP_Rx is responsible for keeping the NAT's state alive if it wants to receive traffic from the BRS on that port 🫶. For (a), the RTP_Rx MUST send UDP traffic to keep the NAT binding alive, at least every 30 seconds [RFC4787]. (a) is more of an automatic/dynamic setup, and (b) is more of a manual/static one. Very different vibes ✨
When the RTP_Rx sends a request (RAMS-R) message to the FT as unicast feedback in the primary multicast RTP session, and the FT receives that request, a new unicast burst RTP session gets set up between the BRS and RTP_Rx 🦋.
The FT and BRS ports on the RS are already signaled through out-of-band means (e.g., SDP), but the RTP_Rx still needs to convey the RTP and RTCP ports it wants to use on its side for the new session. Here's the tea: there are two RTP sessions involved (one multicast, one unicast), and one of them gets established because of a feedback message sent in the other one. So this needs an explicit port mapping method 🌸.
Applications using RAMS MUST support the method presented in [RFC6284] both on the RS and RTP_Rx side, so RTP receivers can use their desired ports and RAMS still works behind NAT devices. The port mapping message exchange needs to happen whenever the RTP_Rx wants to use the RAMS protocol to rapidly acquire a specific multicast RTP session before joining the associated SSM session 💜.
10. Security Considerations 🔐
Okay, this section is serious, so grab a snack. Applications that use RAMS lean heavily on the unicast feedback mechanism described in [RFC5760], the payload format defined in [RFC4588], and the port mapping solution specified in [RFC6284]. That means these applications are subject to the general security considerations discussed in those documents. Especially the threats and risks discussed in [RFC5760], which need to be considered carefully 😭. Here we give an overview of the guidelines and suggestions from those specifications from a RAMS perspective, and we also cover the security considerations that apply specifically to RAMS apps.
First of all, a lot of the session description info is available in the SDP descriptions that get distributed to the media senders, retransmission servers, and RTP receivers. Adequate security measures are RECOMMENDED to make sure the integrity and authenticity of those SDP descriptions are protected, so the transport addresses of the media senders, distribution sources, feedback targets, and other session-specific info stay safe. See [RFC4566] for details 🎀.
Compared to an RTCP NACK message that triggers one or more retransmissions, a RAMS Request (RAMS-R) message can trigger a brand new burst stream to be sent by the retransmission server. Depending on the application-specific requirements and the conditions at the time the retransmission server receives the RAMS-R, that burst stream could contain a large number of retransmission packets. Since those packets are sent faster than the nominal rate, RAMS uses up more resources on the retransmission servers, RTP receivers, and the network. So yeah, this can make denial-of-service (DoS) attacks more intense and more harmful than attacks targeting ordinary retransmission sessions 💀.
RAMS messages are sent as RTCP messages, so counter-measures SHOULD be taken to prevent tampered or spoofed RTCP packets, following the suggestions in [RFC4588]. Tampered RAMS-R messages can trigger inappropriate burst streams or alter existing burst streams in an inappropriate way. For example, if the Max Receive Bitrate field gets altered by a tampered RAMS-R message, the updated burst can overflow the buffer at the receiver side. Or, oppositely, it can slow the burst down to the point that it becomes useless 🙈. Tampered RAMS Termination (RAMS-T) messages can terminate valid burst streams prematurely, which results in gaps in the received RTP packets. RAMS Information (RAMS-I) messages contain fields that are critical for a successful rapid acquisition, so any tampered info in a RAMS-I message can easily make an RTP receiver make wrong decisions. Then the RAMS operation can fail.
RTCP BYE messages are kind of similar to RAMS-T messages in that they can be used to stop an existing burst. The CNAME of an RTP receiver is what binds the RTCP BYE message to an existing burst. So one should be careful if CNAMEs are reasonably easy to guess and off-path attacks can be performed. Also note that CNAMEs might be redistributed to all participants in the multicast group (as in ASM or the simple feedback model of [RFC5760]) 👀.
The retransmission server has to consider whether the values indicated in a RAMS-R message are reasonable. For example, a request demanding a large value of many seconds in the Min RAMS Buffer Fill Requirement element should, unless special use cases exist, likely be rejected, since it's likely an attempt to prolong a DoS attack on the retransmission server, RTP receiver, and/or the network. The Max Receive Bitrate could also be set to a very large value to try to get the retransmission server to cause massive congestion by bursting at a bitrate the network won't support 🚨. An RTP_Rx should also consider whether the values for the Earliest Multicast Join Time and Burst Duration indicated by the retransmission server in a RAMS-I message are reasonable. For example, if the burst packets stop arriving and the join time is still way off in the future, that could be a sign of a man-in-the-middle attack where the RAMS-I message has been manipulated by an attacker 👻.
A basic mitigation against DoS attacks introduced by an attacker injecting tampered RAMS messages is source address validation [RFC2827]. Also, most DoS attacks can be prevented by the integrity and authenticity checks enabled by Secure RTP (SRTP) [RFC3711]. However, an attack can still be started by legitimate endpoints that send several valid RAMS-R messages to a particular feedback target in a synchronized fashion within a very short amount of time. Since a RAMS operation can temporarily consume a large amount of resources, a series of RAMS-R messages can temporarily overload the retransmission server. In these circumstances, the retransmission server can, for example, reject incoming RAMS requests until its resources become available again. One way to ease this threat is to apply a per-endpoint policing mechanism on incoming RAMS requests. A reasonable policing mechanism should consider application-specific requirements and minimize false negatives 🧐.
On top of the DoS attacks, man-in-the-middle and replay attacks are also harmful. RAMS-R messages don't carry any info that lets the retransmission server detect duplication or replay attacks. So a replay attack using a captured valid RAMS-R message is possible unless a mitigation method such as Secure RTCP (SRTCP) is used. Similarly, RAMS-T messages can be replayed. The RAMS-I has a sequence number that makes replay attacks less likely, but not impossible. Man-in-the-middle attacks that can capture, inject, or modify RAMS messages can easily pull off the attacks described above. So cryptographic integrity and authentication is the only reliable protection 🔒. To protect RTCP messages from man-in-the-middle and replay attacks, the RTP receivers and the retransmission server SHOULD perform a Datagram Transport Layer Security (DTLS)-SRTP handshake [RFC5764] over the RTCP channel. Because there's no integrity-protected signaling channel between an RTP receiver and the retransmission server, the retransmission server MUST maintain a list of certificates owned by legitimate RTP receivers, or their certificates MUST be signed by a trusted Certificate Authority. Once DTLS-SRTP security is established, non-SRTCP-protected messages received from a particular RTP receiver are ignored by the retransmission server. To reduce the impact of DTLS-SRTP overhead when talking to different feedback targets on the same retransmission server, it is RECOMMENDED that RTP receivers and the retransmission server both support TLS Session Resumption without Server-side State [RFC5077]. To help SRTP scale to handle many RTP receivers asking for retransmissions of identical data, implementors may consider using the same SRTP key for SRTP data sent to the receivers [SRTP-EKT], but be aware that such key sharing allows those receivers to impersonate the sender. So source address validation remains important 💅.
[RFC4588] RECOMMENDS that cryptography mechanisms be used for the retransmission payload format to provide protection against known plain-text attacks. As discussed in [RFC4588], the retransmission payload format sets the timestamp field in the RTP header to the media timestamp of the original packet, and this does not compromise confidentiality. Furthermore, if cryptography is used to provide security services on the original stream, then the same services, with equivalent cryptographic strength, MUST be provided on the retransmission stream per [RFC4588] 🔐.
Finally, a retransmission server that has been subverted by an attacker is almost impossible to protect against, since such a server can perform a large number of different actions to deny service to receivers. Yikes 💀.
11. IANA Considerations 📋
The following contact information is used for all registrations in this document:
Ali Begen
abegen@cisco.comNote that the "RAMS" (value 2) in the Multicast Acquisition Method Registry refers to the method described in Section 6 of this document 🍓.
11.1. Registration of SDP Attributes
This document registers a new attribute name in SDP ✨.
SDP Attribute ("att-field"):
Attribute name: rams-updates
Long form: Support for Updated RAMS Request Messages
Type of name: att-field
Type of attribute: Media level
Subject to charset: No
Purpose: See this document
Reference: [RFC6285]
Values: None11.2. Registration of SDP Attribute Values
This document registers a new value for the 'nack' attribute to be used with the 'rtcp-fb' attribute in SDP. For more info about the 'rtcp-fb' attribute, refer to Section 4.2 of [RFC4585] 🦋.
Value name: rai
Long name: Rapid Acquisition Indication
Usable with: nack
Reference: [RFC6285]11.3. Registration of FMT Values 🎀
Okay so within the RTPFB range, there's one format (FMT) value registered, and it's giving RAMS 💖
Name: RAMS
Long name: Rapid Acquisition of Multicast Sessions
Value: 6
Reference: [RFC6285]11.4. SFMT Values for RAMS Messages Registry 🦋
Here's the vibe: this document creates a brand new sub-registry for the sub-feedback message type (SFMT) values, to be used with the FMT value we just registered for RAMS messages. It's called the SFMT Values for RAMS Messages Registry 🌸 and it's managed by the IANA according to the Specification Required policy of [RFC5226].
The SFMT field in RAMS messages is a single octet, so that's 256 possible values. The registry starts out with these entries:
Value Name Reference
----- -------------------------------------------------- ------------
0 Reserved [RFC6285]
1 RAMS Request [RFC6285]
2 RAMS Information [RFC6285]
3 RAMS Termination [RFC6285]
4-254 Unassigned - Specification Required
255 Reserved [RFC6285]Values 0 and 255 are reserved for future use, so hands off 🙅♀️
If you want to register an unassigned SFMT value, your registration needs to include:
- Contact information for whoever is registering it, including at least name, address, and email.
- A detailed description of what the new SFMT represents and how it shall be interpreted.
Also, a lowkey important vibe check ✨: new RAMS functionality is meant to come in through the extension mechanism inside the existing RAMS message types, not by making brand-new message types, unless it is absolutely necessary. Don't be extra 💅
11.5. RAMS TLV Space Registry 🌈
This document creates a new IANA TLV space registry for the RAMS extensions. It's called the RAMS TLV Space Registry, and it's managed by the IANA according to the Specification Required policy of [RFC5226] 💜
The Type field in the TLV elements is one octet, which gives us 256 values. Type values 0 and 255 are reserved for future use. Type values from 128 through 254 (both included) are reserved for private extensions 🧚
Here's the starting lineup:
Type Description Reference
---- ----------------------------------------------- -------------
0 Reserved [RFC6285]
1 Requested Media Sender SSRC(s) [RFC6285]
2 Min RAMS Buffer Fill Requirement [RFC6285]
3 Max RAMS Buffer Fill Requirement [RFC6285]
4 Max Receive Bitrate [RFC6285]
5 Request for Preamble Only [RFC6285]
6 Supported Enterprise Number(s) [RFC6285]
7-30 Unassigned - Specification Required
31 Media Sender SSRC [RFC6285]
32 RTP Seqnum of the First Packet [RFC6285]
33 Earliest Multicast Join Time [RFC6285]
34 Burst Duration [RFC6285]
35 Max Transmit Bitrate [RFC6285]
36-60 Unassigned - Specification Required
61 Extended RTP Seqnum of First Multicast Packet [RFC6285]
62-127 Unassigned - Specification Required
128-254 Reserved for Private Use
255 Reserved [RFC6285]Registering an unassigned Type value needs to include:
- Contact information for whoever is registering it, including at least name, address, and email.
- A detailed description of what the new TLV element represents and how it shall be interpreted.
11.6. RAMS Response Code Space Registry 🍓
This document creates another new IANA TLV space registry, this time for the RAMS response codes. It's called the RAMS Response Code Space Registry, and it's managed by the IANA according to the Specification Required policy of [RFC5226] ✨
The Response field is two octets, so you get 65536 codes. In this document though, the response codes were sorted and registered using an HTTP-style numbering scheme. New response codes should be sorted into these ranges:
Code Level Purpose
---------- ---------------
1xx Informational
2xx Success
3xx Redirection
4xx RTP Receiver (RTP_Rx) Error
5xx Burst/Retransmission Source (BRS) ErrorResponse code 65535 is reserved for future use 🔒
And here's the registry's opening set of codes:
Code Description Reference
----- -------------------------------------------------- ------------
0 A private response code is included in the message [RFC6285]
100 Parameter update for RAMS session [RFC6285]
200 RAMS request has been accepted [RFC6285]
201 Unicast burst has been completed [RFC6285]
400 Invalid RAMS-R message syntax [RFC6285]
401 Invalid min buffer requirement in RAMS-R message [RFC6285]
402 Invalid max buffer requirement in RAMS-R message [RFC6285]
403 Insufficient max bitrate requirement in RAMS-R
message [RFC6285]
404 Invalid RAMS-T message syntax [RFC6285]
500 An unspecified BRS internal error has occurred [RFC6285]
501 BRS has insufficient bandwidth to start RAMS
session [RFC6285]
502 Burst is terminated due to network congestion [RFC6285]
503 BRS has insufficient CPU cycles to start RAMS
session [RFC6285]
504 RAMS functionality is not available on BRS [RFC6285]
505 RAMS functionality is not available for RTP_Rx [RFC6285]
506 RAMS functionality is not available for
the requested multicast stream [RFC6285]
507 BRS has no valid starting point available for
the requested multicast stream [RFC6285]
508 BRS has no reference information available for
the requested multicast stream [RFC6285]
509 BRS has no RTP stream matching the requested SSRC [RFC6285]
510 RAMS request to acquire the entire session
has been denied [RFC6285]
511 Only the preamble information is sent [RFC6285]
512 RAMS request has been denied due to a policy [RFC6285]If you're registering an unassigned Response code, you need to include:
- Contact information for whoever is registering it, including at least name, address, and email.
- A detailed description of what the new Response code describes and how it shall be interpreted.
12. Contributors 🫶
Dave Oran, Magnus Westerlund, and Colin Perkins were seriously key to this spec. They wrote text and came up with solutions for some of the issues that popped up while it was being developed 👑
13. Acknowledgments 💐
These lovely people reviewed earlier versions of this specification and dropped helpful comments: Joerg Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox, Jose Rey, Sean Sheedy, and Keith Drage 🥹✨
14. References
14.1. Normative References 📚✨
okay bestie, this is the must-read list 💅 these are the docs the spec leans on so hard it literally can't work without them 🫶
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605,
October 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[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,
July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
[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, May 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010.
[RFC6128] Begen, A., "RTP Control Protocol (RTCP) Port for Source-
Specific Multicast (SSM) Sessions", RFC 6128,
February 2011.
[RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping
Between Unicast and Multicast RTP Sessions", RFC 6284,
June 2011.14.2. Informative References 🌸
these ones are the extra-helpful reads 🧚 the spec mentions them for context, but you don't need them to get the core stuff, so think of them as bonus material 💜
[ECN-FOR-RTP]
Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", Work in Progress, May 2011.
[IC2009] Begen, A., Glazebrook, N., and W. Ver Steeg, "Reducing
Channel Change Times in IPTV with Real-Time Transport
Protocol (IEEE Internet Computing)", May 2009.
[MULTICAST-ACQ]
Begen, A. and E. Friedrich, "Multicast Acquisition Report
Block Type for RTP Control Protocol (RTCP) Extended
Reports (XRs)", Work in Progress, May 2011.
[RAMS-SCENARIOS]
Begen, A., "Considerations and Guidelines for Deploying
the Rapid Acquisition of Multicast Sessions (RAMS)
Method", Work in Progress, June 2011.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control
Protocol (DCCP)", RFC 5762, April 2010.
[RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity
Forward Error Correction (FEC)", RFC 6015, October 2010.
[RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", RFC 6222, April 2011.
[SRTP-EKT] McGrew, D., Andreasen, F., Wing, D., and K. Fischer,
"Encrypted Key Transport for Secure RTP", Work
in Progress, March 2011.
[UPnP-IGD] UPnP Forum, "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD)", December 2010.Authors' Addresses 🎀
and finally, the squad behind this RFC 🫶 these are the people who wrote it, so if you ever need to reach out, here's where they're at 💌
Bill Ver Steeg
Cisco
5030 Sugarloaf Parkway
Lawrenceville, GA 30044
USA
EMail: billvs@cisco.com
Ali Begen
Cisco
181 Bay Street
Toronto, ON M5J 2T3
Canada
EMail: abegen@cisco.com
Tom Van Caenegem
Alcatel-Lucent
Copernicuslaan 50
Antwerpen 2018
Belgium
EMail: Tom.Van_Caenegem@alcatel-lucent.be
Zeev Vax
Magnum Semiconductor, Inc.
591 Yosemite Drive
Milpitas, CA 95035
USA
EMail: zeev.vax@magnumsemi.comthat's the whole RFC, bestie!! 🌈✨💖
📦 where this page comes from
- ietf: rfc6285 2011-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms