RFC 6659
Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method
RFC 6659: Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method 💖
okay bestie, the header info first 🎀. It's RFC 6659, written by A. Begen at Cisco and dated July 2012. It's Informational, not a Standards Track spec, and its ISSN is 2070-1721. The header has no Obsoletes or Updates lines, so it doesn't replace or change any other RFC 🦋.
Abstract ✨
okay so RAMS (Rapid Acquisition of Multicast RTP Sessions) is a method built on RTP and RTCP 🌸 that lets an RTP receiver quickly get into a multicast RTP stream and start consuming it. When the receiver asks, an extra unicast RTP retransmission session gets set up between a retransmission server and that receiver. Over that session, reference info about the new multicast stream gets sent at a speeded-up rate. That info usually shows up before the multicast stream, but it can also show up at the same time 🚀.
With just one multicast stream, RAMS is super straightforward 😌. But if you want two or more multicast streams, from the same multicast RTP session or from different ones, you have to set up each RAMS session carefully 💅. This doc walks through example scenarios and talks about how RAMS could be used in them 🧚.
Status of This Memo 🌈
This document is not an Internet Standards Track specification. It's published for informational purposes, so no, it's not a standard 🙈.
It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, which is lowkey important to know 😭. See Section 2 of RFC 5741 for more on that.
For info on the current status of this document, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6659 🔥.
Copyright Notice 💜
Copyright (c) 2012 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), as they stand on the publication date. Please read them carefully, because they explain your rights and restrictions for this document 📜. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫶.
Table of Contents 🍓
1. Introduction ....................................................2
2. Background ......................................................3
3. Example Scenarios ...............................................4
3.1. Scenario #1: Two Multicast Groups ..........................4
3.2. Scenario #2: One Multicast Group ...........................5
3.3. Scenario #3: SSRC Multiplexing .............................6
3.4. Scenario #4: Payload-Type Multiplexing .....................6
4. Feedback Target and SSRC Signaling Issues .......................7
5. FEC during RAMS and Bandwidth Issues ............................7
5.1. Scenario #1 ................................................7
5.2. Scenario #2 ................................................9
5.3. Scenario #3 ...............................................10
6. Security Considerations ........................................10
7. Acknowledgments ................................................10
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................111. Introduction 🎀
okay so RAMS is that same method again: RTP plus RTCP, helping an RTP receiver rapidly acquire and start consuming multicast RTP data 💅. Through an auxiliary unicast RTP retransmission session [RFC4588], the receiver gets reference info about the new multicast stream it's about to join. That info often comes before the multicast stream, but it can also come along with it. The full RAMS details live in [RFC6285] 📖.
The RAMS specification [RFC6285] has provisions for acquiring multiple streams inside one multicast RTP session at the same time 🌸. What it doesn't cover is scenarios where a receiver uses RAMS to rapidly acquire multiple associated multicast streams in parallel. It also doesn't cover cases where different RTP sessions are part of the same Source-Specific Multicast (SSM) session 😭. The example in Section 8.3 of [RFC6285] only shows the simple case, a receiver rapidly acquiring just one multicast stream, so the protocol details are easy to follow 🧚.
Some deployment models have a multicast RTP session with two or more multicast streams attached to it 🦋. Some receivers also want to acquire one or more multicast streams from several multicast RTP sessions 💜. When an RTP server starts several RAMS sessions at once, with each one kicked off by its own RAMS Request message to a different feedback target, they need close coordination 👑. In this doc, we share scenarios from real-life deployments and talk about how RAMS could be used in them ✨.
2. Background 🌈
For this discussion, we assume there are two RTP streams (1 and 2) that are somehow associated with each other 🫶. They could be audio and video elementary streams for the same TV channel, or an MPEG2 Transport Stream (with audio and video multiplexed together) and its Forward Error Correction (FEC) stream 📺.
An SSM session is defined by its (distribution) source address and its (destination) multicast group. There can be only one feedback target per SSM session [RFC5760] 🎯. So if the RTP streams come from different sources or go over different multicast groups, they count as different SSM sessions 💅. Different SSM sessions can usually share the same feedback target address and/or port. But RAMS requires each unique feedback target (meaning the combo of address and port) to be tied to at most one RTP session (see Section 6.2 of [RFC6285]) 🔥.
Two or more multicast RTP streams can be sent in the same RTP session, like in a single UDP flow. That's called Synchronization Source (SSRC) multiplexing 🧚. The (de)multiplexing happens at the SSRC level in that case 💖. Or the multicast RTP streams can be sent in different RTP sessions, like different UDP flows, and that's called session multiplexing 🦋. In practice, each multiplexing scheme has its own deployment models 🌸.
Generally, to avoid complications in RTCP reports, it's suggested that two different media streams with different clock rates use different SSRCs or go in different RTP sessions 📊. Some fields in RAMS messages might depend on the clock rate. So in a single RTP session, RTP streams carrying payloads with different clock rates need different SSRCs 💜. Since RTP streams with different SSRCs don't share sequence numbering, each stream has to be acquired individually 😭.
For the rest of the sections, we'll only show the relevant parts of the Session Description Protocol (SDP) descriptions [RFC4566] 🎀. For a full SDP example, check Section 8.3 of [RFC6285] 🌈.
3. Example Scenarios ✨
3.1. Scenario #1: Two Multicast Groups 💅
This scenario is about session multiplexing, where RTP streams 1 and 2 go over different multicast groups 🦋. A practical use case is when the first and second SSM sessions carry the primary video stream and its associated FEC stream, respectively 📺.
Each RTP stream that needs rapid acquisition gets its own RAMS session 💖. Each one needs a separate RAMS Request message to be sent 🧚. These RAMS sessions can run in parallel. If they do, the RTP receiver needs to pay attention to using the shared bandwidth properly across the two unicast bursts 👑. Like we said earlier, these two SSM sessions each need a different feedback target 🔥.
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
a=group:FEC-FR Channel1_Video Channel1_FEC
m=video 40000 RTP/AVPF 96
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video
m=application 40000 RTP/AVPF 97
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtcp:42000 IN IP4 192.0.2.1
a=ssrc:2 cname:ch1_fec@example.com
a=mid:Channel1_FECNote that the multicast destination ports in the SDP above don't matter. They can be the same or different 🙈. The "FEC-FR" grouping semantics are defined in [RFC5956] 💜.
3.2. Scenario #2: One Multicast Group 🌸
In this one, RTP streams 1 and 2 go over the same multicast group but with different destination ports 🧚. A practical use case is an SSM session that carries both the primary video and audio streams, each going to its own port 📺.
The RAMS Request message that an RTP receiver sends to the feedback target can ask for all of the available RTP streams, a subset, or just one 💅. So the primary video and audio streams can both be acquired rapidly in parallel ✨. Or, if the receiver wants, it can grab only the primary video or only the audio stream by naming the specific SSRC in the request 🎯. Compared to the previous scenario, the only real difference is that the join times for both streams have to be coordinated, since they're delivered in the same multicast session 🫶.
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
m=video 40000 RTP/AVPF 96
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video
m=audio 40001 RTP/AVPF 97
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=ssrc:2 cname:ch1_audio@example.com
a=mid:Channel1_AudioNote that the destination ports on the "m" lines need to be distinct, per [RFC5888] 🔥.
If RTP streams 1 and 2 share the same distribution source, then there's only one SSM session. That means there can be only one feedback target, as the SDP above shows 👑. It also means RTP streams 1 and 2 need their own unique SSRC values, which the SDP above shows too 💖. But if RTP streams 1 and 2 don't share the same distribution source, so their SSM sessions can use different feedback target transport addresses, then their SSRC values don't have to be different from each other 🌈.
3.3. Scenario #3: SSRC Multiplexing ✨
okay so this is the SSRC multiplexing scenario 🎀 where both RTP streams ride over the same multicast group and land on the same destination port. ngl it's a less practical setup, but it could totally make sense when one SSM session carries both the primary video and audio stream, both headed to the same port 💅
just like scenario #2, the primary video and audio streams can both be acquired rapidly in parallel 🦋 or, if the RTP receiver only wants one of them, it can ask for just the primary video or audio by naming the specific SSRC in the request 🫶 bestie, that means there's only ONE distribution source and the destination multicast address is shared, so there's always exactly one SSM session and one feedback target 🌸
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
m=video 40000 RTP/AVPF 96 97
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=ssrc:1 cname:ch1_video@example.com
a=ssrc:2 cname:ch1_audio@example.com
a=mid:Channel13.4. Scenario #4: Payload-Type Multiplexing 🧚
this is the payload-type multiplexing scenario 💜
here it's giving one RTP stream (and one RTP session) carrying BOTH payload types, like a media payload and its FEC data 🍓 the thing is, this is allowed per [RFC3550] 👑 but it comes with a few drawbacks 😭 for example, RTP packets carrying different payload formats share the same sequence numbering space, and RAMS operations can't be applied based on the payload type 💀 for more drawbacks and details, check Section 5.2 of [RFC3550] ✨
4. Feedback Target and SSRC Signaling Issues 🌈
okay so the RAMS protocol uses the common packet format from [RFC4585], which has a field to signal the media sender SSRC 🎀 the SSRCs for the RTP streams can be signaled out-of-band in the SDP, or they could be learned from the RTP packets once transmission starts 🦋 but in RAMS, the latter cannot be used 🙈
signaling the media sender SSRC value helps the feedback target correctly identify the RTP stream to be acquired 🫶 if a feedback target is serving multiple SSM sessions on a particular port, all the RTP streams in those sessions are supposed to have a unique SSRC value 🔥 however, this is NOT an easy requirement to satisfy 😭 so the RAMS specification forbids having more than one RTP session associated with a specific feedback target on a specific port 💅
5. FEC during RAMS and Bandwidth Issues 🔥
let's do an example 🧚 suppose RTP stream 1 is the primary video stream with a bitrate of 10 Mbps, and RTP stream 2 is the associated FEC stream with a bitrate of 1 Mbps 💖 also assume the RTP receiver knows it can receive data at a maximum bitrate of 22 Mbps ✨ SDP can specify the bitrate ("b=" line in kbps) of each media session (per "m" line) 🌸
note that RAMS can potentially congest the network temporarily 💀 refer to [RFC6285] for a detailed discussion 🫶
5.1. Scenario #1 🦋
this is the session multiplexing scenario where RTP streams 1 and 2 are transmitted over different multicast groups 🎀
this is the preferred deployment model for FEC [RFC6363] 👑 having FEC in a different multicast group gives two flexibility points 💅 first, RTP receivers that aren't FEC capable can receive the primary video stream without FEC 🌈 second, RTP receivers that are FEC capable can decide to skip FEC during the rapid acquisition, but still start receiving the FEC stream once acquisition of the primary video stream is complete ⭐
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
a=group:FEC-FR Channel1_Video Channel1_FEC
m=video 40000 RTP/AVPF 96
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=rtpmap:96 MP2T/90000
b=TIAS:10000
a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video
m=application 40000 RTP/AVPF 97
c=IN IP4 233.252.0.2/127
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtcp:42000 IN IP4 192.0.2.1
a=rtpmap:97 1d-interleaved-parityfec/90000
b=TIAS:1000
a=ssrc:2 cname:ch1_fec@example.com
a=mid:Channel1_FECif the RTP receiver doesn't want FEC until the primary video stream is done acquiring, the total available bandwidth can go toward a faster acquisition of the primary video 🏎️ in that case, the RTP receiver can request a Max Receive Bitrate of 22 Mbps in the RAMS Request message for the primary video stream 💖 once RAMS is complete, the RTP receiver can join the FEC multicast session if it wants 🫶
if the RTP receiver wants to rapidly acquire BOTH the primary and FEC streams, it needs to split the total bandwidth between the two RAMS sessions and indicate individual Max Receive Bitrate values in each respective RAMS Request message 😭 since less bandwidth goes to the primary video stream, acquiring the primary video session will take longer on average 💀
the RTP receiver can update the Max Receive Bitrate values during the RAMS session, but this approach is more error-prone 🙈 the reason is the possibility of losing the update messages 😬
5.2. Scenario #2 🌸
here, RTP streams 1 (primary video) and 2 (FEC) are transmitted over the same multicast group, but with different destination ports 🧚 this is NOT a preferred deployment model 🙅♀️
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
a=group:FEC-FR Channel1_Video Channel1_FEC
m=video 40000 RTP/AVPF 96
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=rtpmap:96 MP2T/90000
b=TIAS:10000
a=ssrc:1 cname:ch1_video@example.com
a=mid:Channel1_Video
m=application 40001 RTP/AVPF 97
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=rtpmap:97 1d-interleaved-parityfec/90000
b=TIAS:1000
a=ssrc:2 cname:ch1_fec@example.com
a=mid:Channel1_FECthe RAMS Request message that an RTP receiver sends to the feedback target can ask for all, a subset, or just one of the available RTP streams 🫶 so both the primary video and FEC streams can be acquired rapidly in parallel, sharing the same available bandwidth 🌈 or, the RTP receiver can grab only the primary video stream by naming its specific SSRC in the request 🎀 in that case, the RTP receiver can first acquire the primary video stream at the full receive bitrate 🔥 but once it does the multicast join, the available bandwidth for the burst drops to 11 Mbps instead of 12 Mbps 😭 no matter whether the RTP receiver wants FEC or not, its bitrate needs to be taken into account once it joins the SSM session 💅
5.3. Scenario #3 💜
this is the SSRC multiplexing scenario where both RTP streams go over the same multicast group to the same destination port 🦋
v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=RAMS Scenarios
t=0 0
m=video 40000 RTP/AVPF 96 97
c=IN IP4 233.252.0.1/127
a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
a=rtcp:41000 IN IP4 192.0.2.1
a=rtpmap:96 MP2T/90000
a=rtpmap:97 1d-interleaved-parityfec/90000
a=fmtp:97 L=10; D=10; repair-window=200000
a=ssrc:1 cname:ch1_video@example.com
a=ssrc:2 cname:ch1_fec@example.com
b=TIAS:11000
a=mid:Channel1similar to scenario #2, both the primary video and audio streams can be acquired rapidly in parallel 🧚 or the RTP receiver can grab only the primary video stream by naming its specific SSRC in the request 🫶
note that based on the "a=fmtp" line for the FEC stream, it could be possible to infer the bitrate of that FEC stream and set the Max Receive Bitrate value accordingly 👑
6. Security Considerations 🔐
okay bestie, this one's serious 😭 because this document only describes deployment scenarios for RAMS, all security considerations are specified in the RAMS specification [RFC6285] 💀 go read that one for the full picture 🫶
7. Acknowledgments 🫶
the author would like to thank various individuals in the AVTEXT and MMUSIC WGs, and her friends at Cisco, for their comments and feedback 💖
8. References 📚
8.1. Normative References 💅
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
"Unicast-Based Rapid Acquisition of Multicast RTP
Sessions", RFC 6285, June 2011.8.2. Informative References 🌸
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[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.
[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.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in
the Session Description Protocol", RFC 5956,
September 2010.
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error
Correction (FEC) Framework", RFC 6363, October 2011.Author's Address 🏡
Ali Begen
Cisco
181 Bay Street
Toronto, ON M5J 2T3
Canada
EMail: abegen@cisco.com📦 where this page comes from
- ietf: rfc6659 2012-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms