RFC 5760
RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback
RFC 5760 🎀 is an IETF document from February 2010, and it's on the Standards Track ✨ (so it's an actual Internet Standard in progress). The authors are J. Ott (Aalto University), J. Chesterfield (University of Cambridge), and E. Schooler (Intel) 💅. Its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it's a standalone main character 👑.
RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback 🦋
Abstract 💖
okay so this doc adds an extension to the Real-time Transport Control Protocol (RTCP) that lets receivers send unicast feedback back to a multicast sender 📮. It's super useful for single-source multicast sessions like Source-Specific Multicast (SSM), where the classic many-to-many group vibe is either not available or just not wanted 🙅♀️. It's also useful for any group that would benefit from a sender-controlled, summarized reporting mechanism. no cap, it's giving flexible 🧚
Status of This Memo 📝
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5760.
Copyright Notice ©️
Copyright (c) 2010 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 date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes.
This document may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from the people controlling that copyright, 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. The only exceptions are formatting it for publication as an RFC or translating it into languages other than English. 🫶
Table of Contents 🗂️
1. Introduction ....................................................3
2. Conventions and Acronyms ........................................4
3. Definitions .....................................................5
4. Basic Operation .................................................6
5. Packet Types ...................................................10
6. Simple Feedback Model ..........................................11
7. Distribution Source Feedback Summary Model .....................13
8. Mixer/Translator Issues ........................................36
9. Transmission Interval Calculation ..............................37
10. SDP Extensions ................................................39
11. Security Considerations .......................................41
12. Backwards Compatibility .......................................51
13. IANA Considerations ...........................................51
14. References ....................................................53
Appendix A. Examples for Sender-Side Configurations ...............57
Appendix B. Distribution Report Processing at the Receiver ........601. Introduction ✨
okay bestie, let's start with the basics 🌸. The Real-time Transport Protocol (RTP) [1] is a real-time transport mechanism that works for unicast or multicast communication between multimedia apps. It's usually used for real-time or near real-time group calls with audio and video streams 🎧. RTP's big sidekick is its control channel, the RTP Control Protocol (RTCP). RTCP sends control packets back and forth between group members on a regular schedule 📦. This lets the group estimate how big it is and work out session info like packet loss and round-trip time to other hosts. There's also a bonus: a third-party session monitor can just listen in to figure out network conditions and diagnose faults based on where the receivers are 🕵️♀️.
RTP was built to run in either unicast or multicast mode 🔁. In multicast mode it assumes an Any Source Multicast (ASM) group model, where one-to-many and many-to-many communication are both supported through a shared group address in the range 224.0.0.0 through 239.255.255.255 💫. To make multicast work across the whole Internet, intra-domain routing protocols (the ones that only operate inside a single administrative domain, like the Distance Vector Multicast Routing Protocol (DVMRP) [16] and Protocol Independent Multicast (PIM) [17][18]) are paired with inter-domain routing protocols (the ones that operate across administrative domain borders, like Multicast BGP (MBGP) [19] and the Multicast Source Discovery Protocol (MSDP) [20]) 🌐. Together these let a host join a single multicast group address and send data to, or receive data from, everyone in the group without knowing anything about the membership beforehand. the catch is that all this routing complexity is a LOT to support multicast in the network 😭.
Many-to-many communication isn't always available, or wanted, by every group app. For example, with Source-Specific Multicast (SSM) [8][9] and satellite communication, the multicast distribution channel only carries traffic from source to receiver 🛰️. In other cases, like big ASM groups with one active data source and lots of passive receivers, it's sub-optimal to build a full routing-level mesh of multicast sources just to distribute RTCP control packets. So an alternative solution is preferable 💅.
A one-to-many multicast topology can simplify routing and may be a closer match for the needs of certain RTP apps. But unidirectional communication makes it impossible for receivers in the group to share RTCP feedback with other group members 🙃. This document is where we fix that problem. We introduce unicast feedback as a new way to distribute RTCP control information among all session members 🎀. This method is designed to work under any group communication model, whether ASM or SSM. The RTP data stream protocol itself stays exactly the same 🦋.
Unicast feedback can help in scenarios including, but not limited to, these:
a) SSM groups with a single sender. The extensions let SSM groups that don't have many-to-many capability still receive RTP data streams and keep taking part in RTCP. They do this by using multicast in the source-to-receiver direction and unicast to send receiver feedback back to the source on the standard RTCP port 📬.
b) One-to-many broadcast networks. Unicast feedback may also help one-to-many broadcast networks, like a satellite network with a terrestrial low-bandwidth return channel or a broadband cable link 📡. Unlike the SSM network, these networks may let a receiver multicast return data to the group. Still, a unicast feedback mechanism may be preferable for routing simplicity 🧠.
c) ASM with a single sender. An ASM app with a single sender can use unicast feedback to take some load off the multicast routing infrastructure, which doesn't scale as efficiently as unicast routing does 🏗️. Because this is no more efficient than a standard multicast group RTP setup, it isn't expected to replace the traditional mechanism 🙈.
The changes in this document are meant to supplement the existing RTCP feedback mechanisms described in Section 6 of [1] 💜.
2. Conventions and Acronyms 📚
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 RFC 2119 [13] 🔥.
The following acronyms are used throughout this document 💅:
ASM Any Source Multicast
SSM Source-Specific Multicast3. Definitions ✨
okay bestie, let's get the vocab down first because this section is the foundation for everything else 🎀 we're in an SSM (source-specific multicast) context, and there's one entity that does a lot of the heavy lifting.
Distribution Source: 💖 okay so in an SSM setup, only ONE entity sends the RTP data and passes the RTCP info along to all the receivers. that entity is the Distribution Source 👑 it's also the one that forwards RTCP feedback back to the Media Senders, so it basically builds a virtual multicast environment where RTP and RTCP can actually work together ✨
ngl this is so iconic. also, heterogeneous networks (mixed setups) with ASM multiple-sender groups, unicast-only clients, and/or SSM single-sender receiver groups MAY be hooked up through translators or mixers to make one single-source group 🦋 (see Section 8 for the deets)
Media Sender: 🌸 a Media Sender is any entity that originates RTP packets for a given media session. in RFC 3550, these are just called "sources," but since the RTCP SSM architecture has a Distribution Source too, we're calling them Media Senders in this doc so nobody gets confused 🙈 a Media Sender is often co-located with the Distribution Source (very cozy 🧚). BUT even though there MUST be only one Distribution Source, there MAY be multiple Media Senders that the Distribution Source forwards RTP and RTCP packets on behalf of 💅
RTP and RTCP Channels: 🍓 so the data going from the source to the receivers is the RTP channel, and the control info is the RTCP channel. with regular RTP/RTCP these usually share the same multicast address but get told apart by port numbers, as specified in [1] 💜
in SSM, the RTP channel is multicast from the Distribution Source to the receivers. the RTCP or feedback channel is different though: it's actually a bunch of unicast channels between the receivers and the Distribution Source, going through the Feedback Target(s) 🫶 so bidirectional communication works by using SSM in the Distribution Source → receivers direction, and the unicast feedback channel in the receivers → Distribution Source direction. the way the channels between the Distribution Source and the Media Sender(s) work can vary, and we'll get into that in the next section 🦋
(Unicast RTCP) Feedback Target: 🌈 the Feedback Target is a logical function that unicast RTCP feedback traffic gets addressed to. the Feedback Target and the Distribution Source MAY be co-located or squished into the same entity 🎀 in that case, for a session with a Distribution Source A on ports n (RTP) and k (RTCP), the unicast RTCP Feedback Target is identified by an IP address of Distribution Source A on port k, unless the session description says otherwise. see Section 10 for how the address gets specified 💖
the Feedback Target MAY ALSO live in one or more entities that are different from the Distribution Source, and different RTP receivers MAY use different Feedback Target instances (for aggregation purposes, for example) ✨ if that's the setup, the Feedback Target instance(s) MUST pass the feedback they get from the RTP receivers along to the Distribution Source, using the RTCP mechanisms in this document 😭 if they're disjoint, the Feedback Target instances MAY be organized in arbitrary topologies: parallel, hierarchical, or chained 🧚 but the Feedback Target instance(s) and the Distribution Source MUST share enough info (through configuration, for example) to give the RTP receivers coherent RTCP info based on the feedback collected by the Feedback Target instance(s). basically it has to look the same as if both functions were part of one entity 👑
and for unicast feedback to work, each receiver MUST direct its RTCP reports to ONE specific Feedback Target instance. no splitting your reports, periodt 💅
SSRC: 🌷 SSRC is the synchronization source, as defined in [1]. it's a 32-bit value that uniquely identifies each member in a session 🔥
Report blocks: 🍒 a report block is the standard name for an RTCP reception report. RTCP [1] encourages stacking multiple report blocks in Sender Report (SR) and Receiver Report (RR) packets 🫶 which means one source can make a variable-size feedback packet that reports on multiple other sources in the group. the summarized reporting scheme builds on this model by including multiple summary report blocks in one packet 🦋 however, stacking reports from multiple receivers is NOT permitted in the Simple Feedback Model (see Section 6) 🙅♀️
4. Basic Operation ✨
okay so bestie, picture this 🎀 one or more Media Senders fire RTP packets at the Distribution Source 💖. The Distribution Source then relays those RTP packets to the receivers using a source-specific multicast arrangement 🦋. Going the other way, the receivers send their RTCP packets via unicast to one or more instances of the Feedback Target 🫶. The Feedback Target either passes along the original RTCP reports (the Simple Feedback Model) or sends summaries of them (the Summary Feedback Model) up to the Distribution Source 🔥. Then the Distribution Source passes the reports and/or summaries down to the Media Senders 💅. It also sends the RTCP Sender Reports and Receiver Reports, or summaries of them, back out to the receivers using source-specific multicast 🌈.
When the Feedback Target(s) are co-located (or integrated) with the Distribution Source, redistributing original or summarized RTCP reports is trivial 👑. When they're physically and/or topologically distinct from the Distribution Source, each Feedback Target either relays the RTCP packets to the Distribution Source or summarizes the reports and forwards an RTCP summary report to it 🌸. Coordination between multiple Feedback Targets is beyond the scope of this specification 🙈.
The Distribution Source MUST be able to communicate with all group members in order for either mechanism to work 🔥. The general architecture is shown in Figure 1 below ✨. There may be a single Media Sender or multiple Media Senders (Media Sender i, 1<=i<=M) on whose behalf the Distribution Source disseminates RTP and RTCP packets 🧚. The base case, which is expected to be the most common, is that the Distribution Source is co-located with a particular Media Sender 💜. A basic assumption is that communication is multicast (either SSM or ASM) in the direction of the Distribution Source to the receivers (R(j), 1<=j<=N), and unicast in the direction of the receivers to the Distribution Source 🦋.
Communication between Media Sender(s) and the Distribution Source may be performed in numerous ways 🍓:
- Unicast only: The Media Sender(s) MAY send RTP and RTCP via unicast to the Distribution Source and receive RTCP via unicast 🎀.
- Any Source Multicast (ASM): The Media Sender(s) and the Distribution Source MAY be in the same ASM group, and RTP and RTCP packets are exchanged via multicast 🌈.
- Source-Specific Multicast (SSM): The Media Sender(s) and the Distribution Source MAY be in an SSM group with the source being the Distribution Source. RTP and RTCP packets from the Media Senders are sent via unicast to the Distribution Source, while RTCP packets from the Distribution Source are sent via multicast to the Media Senders 💖.
Note that this SSM group MAY be identical to the SSM group used for RTP/RTCP delivery from the Distribution Source to the receivers, or it MAY be a different one 🫶.
Note that Figure 1 below shows a logical diagram, so no details about the above options for communication between Media Sender(s), Distribution Source, Feedback Target(s) and receivers are provided 🙈.
Configuration information needs to be supplied so that (among other reasons):
- Media Sender(s) know the transport address of the Distribution Source, or the transport address of the (ASM or SSM) multicast group used for the contribution link;
- the Distribution Source knows either the unicast transport address(es) or the (ASM or SSM) multicast transport address(es) to reach the Media Sender(s);
- receivers know the addresses of their respectively responsible Feedback Targets; and
- the Feedback Targets know the transport address of the Distribution Source.
The precise setup and configuration of the Media Senders and their interaction with the Distribution Source is beyond the scope of this document (appropriate Session Description Protocol (SDP) descriptions MAY be used for this purpose). This document only specifies how the various components interact within an RTP session 💅. Informative examples for different configurations of the Media Sources and the Distribution Source are given in Appendix A 🌸.
Future specifications may be defined to address these aspects ⭐.
Source-specific
+--------+ +-----+ Multicast
|Media | | | +----------------> R(1)
|Sender 1|<----->| D S | | |
+--------+ | I O | +--+ |
| S U | | | |
+--------+ | T R | | +-----------> R(2) |
|Media |<----->| R C |->+ +---- : | |
|Sender 2| | I E | | +------> R(n-1) | |
+--------+ | B | | | | | |
: | U | +--+--> R(n) | | |
: | T +-| | | | |
| I | |<---------+ | | |
+--------+ | O |F|<---------------+ | |
|Media | | N |T|<--------------------+ |
|Sender M|<----->| | |<-------------------------+
+--------+ +-----+ Unicast
FT = Feedback Target
Transport from the Feedback Target to the Distribution
Source is via unicast or multicast RTCP if they are not
co-located.
Figure 1: System ArchitectureThe first method proposed to support unicast RTCP feedback, the 'Simple Feedback Model', is a basic reflection mechanism 🪞. All Receiver RTCP packets are unicast to the Feedback Target, which relays them unmodified to the Distribution Source. Then the Distribution Source forwards these packets to all receivers on the multicast RTCP channel 🦋. The big perk here is that an existing receiver implementation needs little modification to use it 💖. Instead of sending reports to a multicast address, a receiver uses a unicast address and still receives forwarded RTCP traffic on the multicast control channel 🫶. This method is also backwards compatible with standard RTP/RTCP implementations 🎀. The Simple Feedback Model is specified in Section 6 ✨.
The second method, the 'Distribution Source Feedback Summary Model', is a summarized reporting scheme that saves bandwidth by consolidating Receiver Reports at the Distribution Source 🌈. It can optionally get help from the Feedback Target(s), and the result goes into summary packets that get distributed to all the receivers 👑. The Distribution Source Feedback Summary Model is specified in Section 7 💅.
The advantage of the latter scheme really shows up in large group sessions 🔥. The basic reflection mechanism outlined above generates a ton of packet forwarding when it replicates all the information to all the receivers 😭. Clearly, this technique requires that all session members understand the new summarized packet format outlined in Section 7.1 💜. The summarized scheme also provides an optional mechanism to send distribution information, or histograms, about the feedback data reported by the whole group 🧚. Potential uses for compiling distribution information are addressed in Section 7.4 🌸.
To tell the two reporting methods apart, a new SDP identifier is created and discussed in Section 10 🍓. The reporting method MUST be decided prior to the start of the session 🎀. A Distribution Source MUST NOT change the method during a session 🙈.
In a session using SSM, the network SHOULD prevent any multicast data from the receiver being distributed further than the first hop router 🦋. Additionally, any data heard from a non-unicast-capable receiver by other hosts on the same subnet SHOULD be filtered out by the host IP stack, so that it does not cause problems with respect to the calculation of the receiver RTCP bandwidth share 💅.
5. Packet Types 🌈
The RTCP packet types defined in [1], [26], and [15] are:
Type Description Payload number
-------------------------------------------------------
SR Sender Report 200
RR Receiver Report 201
SDES Source Description 202
BYE Goodbye 203
APP Application-Defined 204
RTPFB Generic RTP feedback 205
PSFB Payload-specific feedback 206
XR RTCP Extension 207This document defines one further RTCP packet format:
Type Description Payload number
---------------------------------------------------------
RSI Receiver Summary Information 209Within the Receiver Summary Information packet, there are various types of information that may be reported and encapsulated in optional sub-report blocks:
Name Long Name Value
------------------------------------------------------------------
IPv4 Address IPv4 Feedback Target Address 0
IPv6 Address IPv6 Feedback Target Address 1
DNS Name DNS name indicating Feedback Target Address 2
Reserved Reserved for Assignment by Standards Action 3
Loss Loss distribution 4
Jitter Jitter distribution 5
RTT Round-trip time distribution 6
Cumulative loss Cumulative loss distribution 7
Collisions SSRC collision list 8
Reserved Reserved for Assignment by Standards Action 9
Stats General statistics 10
RTCP BW RTCP bandwidth indication 11
Group Info RTCP group and average packet size 12
- Unassigned 13 - 255As with standard RTP/RTCP, the various reports MAY be combined into a single RTCP packet, which SHOULD NOT exceed the path MTU. Packets continue to be sent at a rate that is inversely proportional to the group size, in order to scale the amount of traffic generated 🫧.
6. Simple Feedback Model 🦋
6.1. Packet Formats 🎀
The Simple Feedback Model uses the same packet types as traditional RTCP feedback described in [1] 💖. Receivers still generate Receiver Reports with information on the quality of the stream received from the Distribution Source ✨. The Distribution Source still MUST create Sender Reports that include timestamp information for stream synchronization and round-trip time calculation 🫶. Both Media Senders and receivers are REQUIRED to send SDES packets as outlined in [1] 👑. The rules for generating BYE and APP packets as outlined in [1] also apply 🌸.
6.2. Distribution Source Behavior ✨
okay so for the Simple Feedback Model, the Distribution Source MUST provide a basic packet-reflection mechanism 🦋 It's the default behavior for any Distribution Source, and it's the bare minimum if you want to act as a Distribution Source for a group of receivers that are using unicast RTCP feedback 💅
The Distribution Source (unicast Feedback Target) MUST listen for unicast RTCP data sent to the RTCP port 👂 Every valid unicast RTCP packet that arrives on this port MUST be forwarded by the Distribution Source to the group on the multicast RTCP channel 📣 The Distribution Source MUST NOT stack report blocks from different receivers into one packet for retransmission to the group 🙅♀️ Every RTCP packet from each receiver MUST be reflected individually, no shortcuts bestie 💖
If the Media Sender(s) are not part of the SSM group for RTCP packet reflection, the Distribution Source MUST also forward the RTCP packets it gets from the receivers to the Media Sender(s) 🌸 And if there's more than one Media Sender, and these Media Senders don't talk over ASM with the Distribution Source and each other, the Distribution Source MUST forward each RTCP packet that came from one Media Sender to all the other Media Senders 👑
The Distribution Source MUST forward RTCP packets that come from the Media Sender(s) to the receivers 🎀
Now the bandwidth part, which is so important 😭 The reflected or forwarded RTCP traffic SHOULD NOT be counted as the Distribution Source's own traffic in the transmission interval calculation. In other words, the Distribution Source SHOULD NOT treat reflected packets as part of its own control data bandwidth allowance 🧚 However, reflected packets MUST still be processed by the Distribution Source, and the average RTCP packet size, RTCP transmission rate, and RTCP statistics MUST be calculated 💜 The algorithm for working out the allowance is explained in Section 9 ✨
6.3. Disjoint Distribution Source and Feedback Target(s) 🌈
If the Feedback Target function is separate from the Distribution Source (aka disjoint), the Feedback Target(s) MUST forward all RTCP packets from the receivers, or from another Feedback Target, to the Distribution Source. That can happen directly or indirectly, and either way it MUST happen 🫶
6.4. Receiver Behavior 🍓
Receivers MUST listen on the RTP channel for data and on the RTCP channel for control 👂 Each receiver MUST calculate its share of the control bandwidth, R/n, following the profile in use. Basically, a fraction of the RTCP bandwidth, R, that's allocated to receivers gets split equally between the number of unique receiver SSRCs in the session, which is n 🧮 R might be rtcp_bw * 0.75 or rtcp_bw * 0.5 (it depends on the ratio of senders to receivers, as per [1]), or it might be set explicitly with an SDP attribute [10] 💅 Check Section 9 for more on how the bandwidth allowance gets calculated 🔥 When a receiver is allowed to transmit, it MUST send a unicast Receiver Report packet to the Feedback Target, following the rules in Section 9 💌
Now, SSRC collisions, which are a whole mood 🙈 When a receiver sees either RTP packets or RTCP Sender Reports from a Media Sender whose SSRC collides with the SSRC it picked for itself, it MUST change its own SSRC following the procedures of [1]. And it MUST do this immediately after noticing, and before sending any (further) RTCP feedback messages ⏰
If a receiver has out-of-band information about the Media Sender SSRC(s) used in the media session, it MUST NOT use the same SSRC for itself 🙅♀️ Even when that out-of-band info is available, a receiver MUST still obey the collision-resolution mechanisms above 🔒
Further mechanisms defined in [1] apply for resolving SSRC collisions between receivers 🦋
6.5. Media Sender Behavior 🎤
Media Senders listen on a unicast or multicast transport address for RTCP reports. Those reports come from the receivers (and get forwarded by the Distribution Source), or from other Media Senders (forwarded by the Distribution Source if needed) 📬 Processing and general operation follow [1] 💖
Here's the drama 🎭 A Media Sender that sees an SSRC collision with an entity that is not also a Media Sender MAY delay its own collision-resolution actions as per [1], by 5 * 1.5 * Td, where Td is the deterministic calculated reporting interval. The idea is to give the receivers a chance to see whether the conflict still exists ⏳ SSRC collisions with other Media Senders, though, MUST be acted upon immediately 🚨
Note: This gives precedence to Media Senders and places the burden of collision resolution on the RTP receivers. 👑
Sender SSRC information MAY be communicated out-of-band, for example by means of SDP media descriptions 📄 So, senders SHOULD NOT change their own SSRC aggressively or unnecessarily. Chill, bestie 🧘♀️🌸
7. Distribution Source Feedback Summary Model 📊
In the Distribution Source Feedback Summary Model, the Distribution Source is required to summarize the info it gets from all the Receiver Reports the receivers generate, and then put that info into summary reports 🗂️ This model brings in a new report block format, the Receiver Summary Information (RSI) report, plus a bunch of optional sub-report block formats, which are listed in Section 7.1. As Section 7.3 explains, individual instances of the Feedback Target can do some preliminary summarizing to cut down the processing load at the Distribution Source 🧠
Sub-reports attached to the RSI report block give more detailed info about the overall session characteristics that all the receivers reported. They can also carry important stuff like the feedback address and the reporting bandwidth 🦋 Which sub-reports are mandatory and which are optional is defined below 👀
From an RTP point of view, the Distribution Source is an RTP receiver. It generates its own Receiver Reports and sends them to the receiver group and to the Media Senders 📨 In this model, an RSI report block MUST be appended to all RRs that the Distribution Source generates 💅
On top of that, the Distribution Source MUST forward the RTCP SR reports and SDES packets from Media Senders without changing them at all 🙌 If the Distribution Source is actually a Media Sender too (even if it's the only session sender), it MUST generate its own Sender Report (SR) packets for its role as a Media Sender, plus its Receiver Reports for its role as the Distribution Source 🎀
The Distribution Source MUST use its own SSRC value for transmitting summarization info, and it MUST perform proper SSRC collision detection and resolution 🔒
The Distribution Source MUST send at least one Receiver Summary Information packet for each reporting interval ⏰ It MAY also stack sub-report blocks after the RSI packet. If it does, each sub-report block MUST correspond to the RSI packet, and it's an enhancement to the basic summary info the receivers need to work out their reporting time interval ✨ Because of that, additional sub-report blocks are not required but recommended 💖 The compound RTCP packets that contain the RSI packet and any optional matching sub-report blocks MUST be formed by the rules in [1] for receiver-issued packets. So they MUST begin with an RR packet, contain at least an SDES packet with a CNAME, and MAY contain further RTCP packets and SDES items 🧩
Every RSI packet MUST contain either a Group and Average Packet Size sub-report or an RTCP Bandwidth sub-report, so receivers get their bandwidth indications 📶
7.1. Packet Formats 📦
All numeric values made up of multiple octets (usually two or four) MUST be encoded in network byte order 🔢
7.1.1. RSI: Receiver Summary Information Packet 💎
The RSI report block has a fixed header size, followed by a variable length report 💅
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|reserved | PT=RSI=209 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Summarized SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp (most significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP Timestamp (least significant word) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Sub-report blocks :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The RSI packet includes the following fields 🌟
- Length: 16 bits As defined in [1], this is the length of the RTCP packet in 32-bit words minus one, including the header and any padding.
- SSRC: 32 bits The SSRC of the Distribution Source.
- Summarized SSRC: 32 bits The SSRC (of the Media Sender) that this report contains a summary for.
- Timestamp: 64 bits This shows the wallclock time when the report was sent ⏰ Wallclock time (absolute date and time) is represented with the timestamp format of the Network Time Protocol (NTP), which counts seconds relative to 0h UTC on 1 January 1900 [1]. The wallclock time MAY (but need not) be NTP-synchronized, but it MUST provide consistent behavior in how time advances (similar to NTP). The full-resolution NTP timestamp is used, which is a 64-bit, unsigned, fixed-point number with the integer part in the first 32 bits and the fractional part in the last 32 bits. This format is similar to RTCP Sender Reports (Section 6.4.1 of [1]). The timestamp is used to detect duplicate packets and reordering, and to give a chronological profile of the feedback reports 🕰️
7.1.2. Sub-Report Block Types 🧁
For RSI reports, this document also introduces a sub-report block format that's specific to the RSI packet 🍰 The sub-report blocks get appended to the RSI packet using the following generic format. All sub-report blocks MUST be 32-bit aligned 📐
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SRBT-specific data +
| |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- SRBT: 8 bits Sub-Report Block Type. This is the sub-report block type identifier. The values for the sub-report block types are defined in Section 5.
- Length: 8 bits The length of the sub-report in 32-bit words.
- SRBT-specific data: <length * 4 - 2> octets This field may contain type-specific information based on the SRBT value.
7.1.3. Generic Sub-Report Block Fields 🎀
okay so for the sub-report blocks that carry distributions of values (Loss, Jitter, RTT, Cumulative Loss), we use this flexible "data bucket" style report 🫶 It chops the data set into variable-size buckets, and the guide fields at the head of the block tell you how to read them. bestie, this is so clever 😭
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
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SRBT | Length | NDB | MF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Distribution Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Distribution Value |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Distribution Buckets |
| ... |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+The SRBT and length fields are calculated the way we covered in Section 7.1.2, so go check that if you need a refresher 💅
Number of distribution buckets (NDB): 12 bits 🍓 This is how many buckets of data there are. You get each bucket's size with ((length * 4) - 12) * 8 / NDB bits. The math starts from the whole sub-report block length in octets (length * 4) and then takes off the 12-octet header. Giving NDB 12 bits means buckets can be as small as 2 bits for a full-length packet at an MTU of 1500 bytes, which is so iconic. Bucket size in bits must always be divisible by 2 so everything stays byte-aligned. A 2-bit bucket is kinda restrictive though, so bigger buckets are expected to be more practical for most distributions 🌸
Multiplicative Factor (MF): 4 bits ✨ 2^MF is the multiplicative factor applied to each distribution bucket value. MF can be 0 through 15, which gives you MF = 1, 2, 4 ... 32768. Appendix B has an example of how the multiplicative factor gets used. It's basically a way to get more "bits" without actually having them, because the bucket values get scaled up by the MF 🦋
Length: 8 bits 💜 The length field tells the receiver the full length of the sub-report block in 32-bit words (so length * 4 bytes), and that's how the receiver figures out the bucket size. For example, if there are no MTU restrictions, the data portion of a distribution packet can be as large as 1008 bytes (255 * 4 - 12). That gives you up to 4032 data buckets of 2 bits each, or 2016 data buckets of 4 bits each, and so on 🧚
Minimum distribution value (min): 32 bits 🌈 The minimum distribution value, together with the maximum distribution value, shows the range covered by the bucket values.
Maximum distribution value (max): 32 bits 🌈 The maximum distribution value, together with the minimum distribution value, shows the range covered by the bucket values. What the distribution values actually mean is defined in the individual subsection for each distribution type (DT) 👑
Distribution buckets: each bucket is ((length * 4) - 12) * 8 / NDB bits 🫧 The size and number of buckets are worked out the way we just described, based on NDB and the packet length. The values are spread out equally. Bucket x (where 0 <= x < NDB) covers this value range:
x = 0; [min, min + (max - min) / NDB]
x > 0; [min + (x) * (max - min) / NDB,
min + (x + 1) * (max - min) / NDB]What the minimum, maximum, and distribution values mean inside the sub-report block depends on which sub-report it is, and each one gets its own section below. The size of the sub-report block changes from packet to packet, and the packet length field tells you what it is 🎀
⚠️ bestie, check this one: for any bucket-based reporting, if the Distribution Source and the Feedback Target(s) are disjoint entities, out-of-band agreement on the bucket-reporting granularity is recommended. That way the Distribution Source can forward accurate information in these kinds of reports to the receivers 🙈
7.1.4. Loss Sub-Report Block 💀
The Loss sub-report block lets a receiver figure out how its own reception quality stacks up against everyone else. A receiver can use this info to drop out of a session (instead of sending a ton of error repair feedback) if it finds itself isolated at the low end of the reception quality scale. Iconic self-awareness 😭
The Loss sub-report block shows the distribution of losses as the receivers reported them to the Distribution Source. Values are a fixed-point number with the binary point at the left edge of the field, kinda like the "fraction lost" field in SR and RR packets, as defined in [1]. The Loss sub-report block type (SRBT) is 4 🌸
Valid results for the minimum distribution value field are 0 - 254. Valid results for the maximum distribution value field are 1 - 255. The minimum distribution value MUST always be less than the maximum 🔥
For examples of processing summarized loss report sub-blocks, see Appendix B 🦋
7.1.5. Jitter Sub-Report Block 🌊
A Jitter sub-report block shows the distribution of the estimated statistical variation in RTP data packet inter-arrival time, as reported by the receivers to the Distribution Source. It's how receivers can put their own observed jitter in context with the rest of the group, and it helps them estimate dynamic parameters for playout buffers. See [1] for the details on how the values get calculated and why the results matter. Jitter values are measured in timestamp units, using the rate the Media Sender uses, and they're expressed as unsigned integers ✨ The minimum distribution value MUST always be less than the maximum. The Jitter sub-report block type (SRBT) is 5 💖
Timestamp units depend on the payload type, so a payload type change in the middle of a session affects how relevant a jitter value is. Therefore, a Distribution Source MUST NOT report jitter distribution values for at least 2 reporting intervals after a payload type change occurs. Bestie, that's a hard rule 🙅♀️
7.1.6. Round-Trip Time Sub-Report Block 🚀
A Round-Trip Time sub-report shows the distribution of round-trip times from the Distribution Source to the receivers, so every receiver gets a global view of the range of values in the group. The Distribution Source can calculate the round-trip time to any other member because it forwards all the SR packets from the Media Sender(s) to the group. If the Distribution Source isn't a Media Sender itself, it can still work out the round-trip time to each receiver by keeping a record of the SR sender timestamp and the current time from its own system clock. It works out the round-trip time from the Receiver Report by finding the matching SR timestamp, then subtracting the RR advertised holding time (as reported by the receiver) from its own time difference measurement. That measurement is the time the RR packet arrived minus the recorded time the SR was sent. The math is giving genius 🧠
The Distribution Source has the option of sending these round-trip time estimations out to the whole group. Section 7.4 describes how they get used. The round-trip time is expressed in units of 1/65536 seconds and shows an absolute value. The Distribution Source calculates it from the Receiver Report responses, which declare the time difference since an original Sender Report, and from the holding time at the receiver. The minimum distribution value MUST always be less than the maximum. The Round-Trip Time sub-report block type (SRBT) is 6 🍓
🙈 if the Distribution Source and the Feedback Target functions are disjoint, the Distribution Source can only determine RTT if every Feedback Target forwards all RTCP reports from the receivers immediately (so no preliminary summarization) and includes at least the RR packet. Not everything can be a main character without help 😭
7.1.7. Cumulative Loss Sub-Report Block 📜
The cumulative loss field in a Receiver Report [1] is different from the fraction lost field. It gives you some historical perspective on session performance, meaning the total number of lost packets since the receiver joined the session. Because it sums over a bigger sample set (usually the whole session), it works as a longer-term average 🫶 The Distribution Source MAY record the values reported by the receiver group and report a distribution of those values. Values are a fixed-point number with the binary point at the left edge of the field, the same way as the Loss sub-report block 💜
Here's the tricky part. Each individual Receiver Report gives the cumulative number of packets lost, but not the cumulative number sent. You need that number as the denominator to calculate the long-term fraction lost. So the Distribution Source MUST maintain a record of the cumulative number lost and the extended highest sequence number received, as reported by each receiver at some point in the past. Ideally, the recorded values come from the first report received. Later calculations are then based on this:
(<the new cumulative loss value> - <the recorded value>) / (<new extended highest sequence number> - <recorded sequence number>)Valid results for the minimum distribution value field are 0 - 254. Valid results for the maximum distribution value field are 1 - 255. The minimum distribution value MUST always be less than the maximum. The Cumulative Loss sub-report block type (SRBT) is 7 🌈
7.1.8. Feedback Target Address Sub-Report Block 🎯✨
okay so this one is giving dynamic redirect energy 💅. The Feedback Target Address block lets the Distribution Source tell the receivers about an alternative unicast RTCP feedback address on the fly. If this block shows up, receivers MUST override any static SDP address info for the session with the Feedback Target address in this sub-report block 🙈.
If a Feedback Target Address sub-report block is used, it MUST be included in every RTCP packet originated by the Distribution Source so that everyone is on the same page 🫶. That way, receiver behavior should remain consistent even when packets get lost or people show up late to the session 😭.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT={0,1,2} | Length | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+SRBT: 8 bits 🧩 The type of sub-report block that corresponds to the type of address is as follows:
0: IPv4 address1: IPv6 address2: DNS name
Length: 8 bits 📏 The length of the sub-report block in 32-bit words. For an IPv4 address, this should be 2 (i.e., total length = 4 + 4 = 2 * 4 octets). For an IPv6 address, this should be 5. For a DNS name, the length field indicates the number of 32-bit words making up the string plus 1 byte and any additional padding required to reach the next word boundary.
Port: 2 octets 🚪 The port number to which receivers send feedback reports. A port number of 0 is invalid and MUST NOT be used.
Address: 4 octets (IPv4), 16 octets (IPv6), or n octets (DNS name) 🏠 The address to which receivers send feedback reports. For IPv4 and IPv6, fixed-length address fields are used. A DNS name is an arbitrary-length string that is padded with null bytes to the next 32-bit boundary. The string MAY contain Internationalizing Domain Names in Applications (IDNA) domain names and MUST be UTF-8 encoded [11].
A Feedback Target Address block for a certain address type (i.e., with a certain SRBT of 0, 1, or 2) MUST NOT occur more than once within a packet. Numerical Feedback Target Address blocks for IPv4 and IPv6 MAY both be present. If so, the resulting transport addresses MUST point to the same logical entity 🤝.
If a Feedback Target address block with an SRBT indicating a DNS name is present, there SHOULD NOT be any other numerical Feedback Target Address blocks present.
⚠️ The Feedback Target Address presents a significant security risk if accepted from unauthenticated RTCP packets. See Sections 11.3 and 11.4 for further discussion. Do not skip this one, bestie 🚨💀
7.1.9. Collision Sub-Report Block 💥🫣
The Collision SSRC sub-report gives the Distribution Source a way to report SSRC collisions across the group. When a non-unique SSRC is found based on the tuple [SSRC, CNAME], the collision gets reported in this block, and the affected nodes must reselect their respective SSRC identifiers.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=8 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Collision SSRC :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Collision SSRC: n * 32 bits 📋 This field contains a list of SSRCs that are duplicated within the group. Usually this is handled by the hosts upon detection of the same SSRC. However, since receivers in an SSM session using the Distribution Source Feedback Summary Model no longer have a global view of the session, the collision algorithm is handled by the Distribution Source. SSRCs that collide are listed in the packet. Each Collision SSRC is reported only once for each collision detection. If more Collision SSRCs need to be reported than fit into an MTU, the reporting is done in a round robin fashion so that all Collision SSRCs have been reported once before the second round of reporting starts. On receipt of the packet, receiver(s) MUST detect the collision and select another SSRC, if the collision pertains to them.
The Collision sub-report block type (SRBT) is 8 🔢.
Collision detection is only possible at the Distribution Source. If the Distribution Source and Feedback Target functions are disjoint and collision reporting across RTP receiver SSRCs shall be provided, the Feedback Targets(s) MUST forward the RTCP reports from the RTP receivers, including at least the RR and the SDES packets to the Distribution Source 📨.
In system settings in which, by explicit configuration or implementation, RTP receivers are not going to act as Media Senders in a session (e.g., for various types of television broadcasting), SSRC collision detection MAY be omitted for RTP receivers 📺. In system settings in which an RTP receiver MAY become a Media Sender (e.g., any conversational application), SSRC collision detection MUST be provided for RTP receivers 🗣️.
📝 Note: The purpose of SSRC collision reporting is to ensure unique identification of RTCP entities. This is of particular relevance for Media Senders so that an RTP receiver can properly associate each of the multiple incoming media streams (via the Distribution Source) with the correct sender. Collision resolution for Media Senders is not affected by the Distribution Source's collision reporting because all SR reports are always forwarded among the senders and to all receivers. Collision resolution for RTP receivers is of particular relevance for those receivers capable of becoming a Media Sender. RTP receivers that will, by configuration or implementation choice, not act as a sender in a particular RTP session, do not necessarily need to be aware of collisions as long as the those entities receiving and processing RTCP feedback messages from the receivers are capable of disambiguating the various RTCP receivers (e.g., by CNAME). Note also that RTP receivers should be able to deal with the changing SSRCs of a Media Sender (like any RTP receiver has to do.) and, if possible, be prepared to continuously render a media stream nevertheless. 🎬✨
7.1.10. General Statistics Sub-Report Block 📊💖
The General Statistics sub-report block is used if specifying buckets is deemed too complex. With this block, only aggregated values are reported back. The rules for generating these values are provided in point b of Section 7.2.1 🧮.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=10 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MFL | HCNL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Median inter-arrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Median fraction lost (MFL): 8 bits 📉 The median fraction lost indicated by Receiver Reports forwarded to this Distribution Source, expressed as a fixed-point number with the binary point at the left edge of the field. A value of all '1's indicates that the MFL value is not provided.
Highest cumulative number of packets lost (HCNL): 24 bits 🔝 Highest 'cumulative number of packets lost' value out of the most recent RTCP RR packets from any of the receivers. A value of all '1's indicates that the HCNL value is not provided.
Median inter-arrival jitter: 32 bits 🎢 Median 'inter-arrival jitter' value out of the most recent RTCP RR packets from the receiver set. A value of all '1's indicates that this value is not provided.
The General Statistics sub-report block type (SRBT) is 10 🔟.
Note that, in case the Distribution Source and the Feedback Target functions are disjoint, it is only possible for the Distribution Source to determine the median of the inter-arrival jitter if all the Feedback Targets forward all RTCP reports from the receivers immediately and include at least the RR packet 🫠.
7.1.11. RTCP Bandwidth Indication Sub-Report Block 📡🌸
This sub-report block tells the Media Senders and receivers about either the maximum RTCP bandwidth that each Media Sender is supposed to use, or the maximum bandwidth allowance each receiver is allowed to use. The value is applied universally to all Media Senders or all receivers 🌍. Each receiver MUST base its RTCP transmission interval calculation on the average size of the RTCP packets sent by itself. Conversely, each Media Sender MUST base its RTCP transmission interval calculation on the average size of the RTCP packets sent by itself 🧠.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=11 | Length |S|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTCP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Sender (S): 1 bit 🎙️ The contained bandwidth value applies to each Media Sender.
Receivers (R): 1 bit 🎧 The contained bandwidth value applies to each RTP receiver.
Reserved: 14 bits 🔒 MUST be set to zero upon transmission and ignored upon reception.
RTCP Bandwidth: 32 bits 💌 If the S bit is set to 1, this field indicates the maximum bandwidth allocated to each individual Media Sender. This also informs the receivers about the RTCP report frequency to expect from the senders. This is a fixed-point value with the binary point in between the second and third bytes. The value represents the bandwidth allocation per receiver in kilobits per second, with values in the range 0 <= BW < 65536.
If the R bit is set to 1, this field indicates the maximum bandwidth allocated per receiver for sending RTCP data relating to the session. This is a fixed-point value with the binary point in between the second and third bytes. The value represents the bandwidth allocation per receiver in kilobits per second, with values in the range 0 <= BW < 65536. Each receiver MUST use this value for its bandwidth allowance 🫧.
This report block SHOULD only be used when the Group and Average Packet Size sub-report block is NOT included. The RTCP Bandwidth Indication sub-report block type (SRBT) is 11 🎀.
7.1.12. RTCP Group and Average Packet Size Sub-Report Block ✨
okay so this sub-report block is how the Distribution Source tells the Media Senders and receivers how big the group is (which is what the feedback bandwidth math is built on) plus the average packet size of the group 🎀. This sub-report MUST always be present, appended to every RSI packet, unless an RTCP Bandwidth Indication sub-report block is included (in which case it MAY, but need not, be present) 💅
Note: The RTCP Bandwidth Indication sub-report block lets the Distribution Source hide the actual group size from the receivers while still avoiding feedback implosion 🙈 this is so clever, I'm obsessed
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRBT=12 | Length | Average Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Group Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Group size: 32 bits 🍓 This field is the Distribution Source's view of how many receivers are in a session. The number of Media Senders isn't reported directly, because you can work it out by looking at the RTCP SR packets the Distribution Source forwards. The group size is calculated following the rules in [1]. When this sub-report block is included, this field MUST always be present.
Average RTCP packet size: 16 bits 🌸 This field is the Distribution Source's view of the average RTCP packet size, calculated locally using the rules defined in [1]. The value is an unsigned integer that counts octets. When this sub-report block is included, this field MUST always be present.
The Group and Average Packet Size sub-report block type (SRBT) is 12 🦋
7.2. Distribution Source Behavior 👑
In the Distribution Source Feedback Summary Model, the Distribution Source (the unicast Feedback Target) MUST listen for unicast RTCP packets sent to the RTCP port. All RTCP packets received on this port MUST be processed by the Distribution Source, as described below. The processing MUST take place per Media Sender SSRC for which Receiver Reports are received.
The Distribution Source acts like a regular RTCP receiver, which is very relatable ngl 🧚 It receives an RTP stream from each RTP Media Sender and MUST calculate the proper reception statistics for these RTP streams. It MUST transmit the resulting information as report blocks contained in each RTCP packet it sends (in an RR packet).
Note: This information may help to determine the transmission characteristics of the feed path from the RTP sender to the Distribution Source (if these are separate entities).
The Distribution Source is responsible for accepting RTCP packets from the receivers and for interpreting and storing per-receiver information, as defined in [1]. This matters so much because incorrect information can have serious implications when the RSI and sub-report block reports get created 😭 Section 11 addresses the security risks in detail, so go read that one, it's lowkey the main event 💀
As defined in [1], all RTCP reports from the Distribution Source MUST start with an RR report, followed by any relevant SDES fields. Then the Distribution Source MUST append an RSI header and sub-reports containing any summarization-specific data. In addition, either the Group and Average Packet Size sub-report or the Receiver RTCP Bandwidth sub-report block MUST be appended to the RSI header ✨
A Distribution Source has the option of masking the group size by including only an RTCP Bandwidth sub-report. If both sub-reports are included, the receiver is expected to give precedence to the information contained in the Receiver RTCP Bandwidth sub-report.
The Receiver RTCP Bandwidth sub-report block gives the Distribution Source the power to control the amount of feedback from the receivers, and the bandwidth value MAY be increased or decreased based upon the requirements of the Distribution Source. Regardless of the value the Distribution Source picks for the Receiver RTCP Bandwidth sub-report block, the Distribution Source MUST continue to forward Sender Reports and RSI packets at the rate allowed by the total RTCP bandwidth allocation. See Section 9 for further details about the frequency of reports 🌈
A Distribution Source MAY start out reporting group size and switch to Receiver RTCP Bandwidth reporting later on, and vice versa. If the Distribution Source does so, it SHOULD ensure that the correspondingly indicated values for the Receiver RTCP Bandwidth sub-report roughly match, i.e., are at least the same order of magnitude 🫶
In order to identify SSRC collisions, the Distribution Source is responsible for maintaining a record of each SSRC and the corresponding CNAME within at least one reporting interval by the group, so it can tell clients apart. It is RECOMMENDED that an updated list covering more than one interval be maintained to increase accuracy. This mechanism should prevent the possibility of collisions, since the combination of SSRC and CNAME should be unique, if the CNAME is generated correctly. If collisions are not detected, the Distribution Source will have an inaccurate impression of the group size. Since the statistical probability is very low that collisions will both occur and be undetectable, this should not be a significant concern. In particular, the clients would have to randomly select the same SSRC and have the same username + IP address (e.g., using private address space behind a NAT router) 🍓💜
7.2.1. Receiver Report Aggregation ✨
okay so the Distribution Source is in charge of aggregating the reception-quality info that comes in through RR packets 🫶. When it does that, it MUST consider the report blocks from every RR packet, and it MUST NOT consider the report blocks of an SR packet 💅.
Note: the receivers will get the information contained in the SR packets anyway by packet forwarding, so duplication of this information should be avoided.
For the optional sub-report blocks, the Distribution Source MAY decide which ones are the most significant feedback values to share, and it MAY choose not to include any 🌸. The packet format is flexible about how much detail the data points carry. There's a tradeoff between granularity and accuracy, based on the multiplicative factor (MF), the number of buckets, and the min and max values 🧚. To zoom in on a particular region of a distribution, the Distribution Source can adjust the minimum and maximum values and either increase the number of buckets (and possibly the factorization) or decrease the number of buckets and give more accurate values 🦋. See Appendix B for detailed examples on how to convey a summary of RTCP Receiver Reports as RSI sub-report block information.
For each value the Distribution Source decides to include in an RSI packet, it MUST adhere to the following measurement rules 👑.
a) bestie, if the Distribution Source intends to use a sub-report to convey a distribution of values (Sections 7.1.3 to 7.1.7), it MUST keep per-receiver state, i.e., remember the last value V reported by the respective receiver. If a new value is reported by a receiver, the existing value MUST be replaced by the new one. The value MUST be deleted (along with the entire entry) if the receiver is timed out (as per Section 6.3.5 of [1]) or has sent a BYE packet (as per Section 6.3.7 of [1]) 💀.
All the values collected in this way MUST be included in the creation of the subsequent Distribution sub-report block 🎀.
The results should correspond as closely as possible to the values received during the interval since the last report. The Distribution Source may stack as many sub-report blocks as required in order to convey different distributions ✨. If the distribution size exceeds the largest packet length (1008 bytes data portion), more packets MAY be stacked with additional information (but in total SHOULD NOT exceed the path MTU) 📦.
All stacked sub-reports MUST be internally consistent, i.e., generated from the same session data. Overlapping of distributions is therefore allowed, and variation in values should only occur as a result of data set granularity, with the more accurate bucket sizes taking precedence in the event that values differ. Non-divisible values MUST be rounded up or down to the closest bucket value, and the number of data buckets must always be an even number, padding where necessary with an additional zero bucket value to maintain consistency 🍓.
Note: This intentionally provides persistent full coverage of the entire session membership to avoid oscillations due to changing membership samples.
Scheduling the transmission of summarization reports is left to the discretion of the Distribution Source. However, the Distribution Source MUST adhere to the bandwidth limitations for Receiver Reports as defined for the respective AV profile in use 🌈.
b) if the Distribution Source intends to report a short summary using the General Statistics sub-report block format, defined in Section 7.1.10, for EACH of the values included in the report (MFL, HCNL, average inter-arrival jitter), it MUST keep a timer T_summary as well as a sufficient set of variables to calculate the summaries for the last three reporting intervals. This MAY be achieved by keeping per-receiver state (i.e., remember the last value V reported by the respective receiver) or by maintaining summary variables for each of these intervals 💜.
The summary values are included here to reflect the current group situation. By recording the last three reporting intervals, the Distribution Source incorporates reports from all members while allowing for individual RTCP Receiver Report packet losses. The process of collecting these values also aims to avoid resetting any of the values and then having to send out an RSI report based upon just a few values collected 🙈. If data is available for less than three reporting intervals (as will be the case for the first two reports sent), only those values available are considered.
The timer T_summary MUST be initialized as T_summary = 1.5 * Td, where Td is the deterministic reporting interval, and MUST be updated following timer reconsideration whenever the group size or the average RTCP size (avg_rtcp_size) changes. This choice should allow each receiver to report once per interval ⏰.
Td
__^__
t0/ \ t1 t2 t3 t4 t5
---+---------+---------+---------+---------+---------+------->
\____ ____/ : : : :
: V : : : : :
:T_summary: : : : :
:=1.5 * Td: : : : :
\______________ ______________/ : :
: V : : :
: 3 * T_summary : :
: : : :
\______________ ______________/ :
: V :
: 3 * T_summary :
: :
\______________ ______________/
V
3 * T_summary
Figure 2: Overview of Summarization ReportingFigure 2 depicts how the summarization reporting shall be performed. At time t3, the RTCP reports collected from t0 through t3 are included in the RSI reporting; at time t4, those from t1 through t4; and so on. The RSI summary report sent MUST NOT include any RTCP report from more than three reporting intervals ago, e.g., the one sent at time t5, must not include reports received at the Distribution Source prior to t2 🦋.
7.2.2. Handling Other RTCP Packets from RTP Receivers 🌸
When following the Feedback Summary Model, the Distribution Source MAY reflect any other RTCP packets of potential relevance to the receivers (such as APP, RTPFB, PSFB) to the receiver group. Also, it MAY decide not to forward other RTCP packets not needed by the receivers such as BYE, RR, SDES (because the Distribution Source performs collision resolution), group size estimation, and RR aggregation. The Distribution Source MUST NOT forward RR packets to the receiver group 🚫.
If the Distribution Source is able to interpret and aggregate information contained in any RTCP packets other than RR, it MAY include the aggregated information along with the RSI packet in its own compound RTCP packet ✨.
Aggregation MAY be a null operation, i.e., the Distribution Source MAY simply append one or more RTCP packets from receivers to the compound RTCP packet (containing at least RR, SDES, and RSI from the Distribution Source) 🧚.
Note: This is likely to be useful only for a few cases, e.g., to forward aggregated information from RTPFB Generic NACK packets and thereby maintain the damping property of [15].
Note: This entire processing rule implies that the flow of information contained in non-RR RTCP packets may terminate at the Distribution Source, depending on its capabilities and configuration.
The configuration of the RTCP SSM media session (expressed in SDP) MUST specify explicitly which processing the Distribution Source will apply to which RTCP packets. See Section 10.1 for details 📝.
7.2.3. Receiver Report Forwarding 💌
If the Media Sender(s) are not part of the SSM group for RTCP packet reflection, the Distribution Source MUST explicitly inform the Media Senders of the receiver group. To achieve this, the Distribution Source has two options: 1) it forwards the RTCP RR and SDES packets received from the receivers to the Media Sender(s); or 2) if the Media Senders also support the RTCP RSI packet, the Distribution Source sends the RSI packets not just to the receivers but also to the Media Senders 🎀.
If the Distribution Source decides to forward RR and SDES packets unchanged, it MAY also forward any other RTCP packets to the senders.
If the Distribution Source decides to forward RSI packets to the senders, the considerations of Section 7.2.2 apply.
7.2.4. Handling Sender Reports 📣
The Distribution Source also receives RTCP (including SR) packets from the RTP Media Senders.
The Distribution Source MUST forward all RTCP packets from the Media Senders to the RTP receivers 💖.
If there is more than one Media Sender and these Media Senders do not communicate via ASM with the Distribution Source and each other, the Distribution Source MUST forward each RTCP packet from any one Media Sender to all other Media Senders 🔁.
7.2.5. RTCP Data Rate Calculation 📊
As noted above, the Distribution Source is a receiver from an RTP perspective. The Distribution Sources MUST calculate its deterministic transmission interval Td as every other receiver; however, it MAY adjust its available data rate depending on the destination transport address and its local operation 🌟:
- For sending its own RTCP reports to the SSM group towards the receivers, the Distribution Source MAY use up to the joint share of all receivers as it is forwarding summaries on behalf of all of them. Thus, the Distribution Source MAY send its reports up to every
Td/Rtime units, with R being the number of receivers. - For sending its own RTCP reports to the Media Senders only (i.e., if the Media Senders are not part of the SSM group), the allocated rate depends on the operation of the Distribution Source:
- a) If the Distribution Source only sends RSI packets along with its own RTCP RR packets, the same rate calculation applies as for #1 above.
- b) If the Distribution Source forwards RTCP packets from all other receivers to the Media Senders, then it MUST adhere to the same bandwidth share for its own transmissions as all other receivers and use the calculation as per [1] 🥹.
7.2.6. Collision Resolution 💅
Okay so, if a Distribution Source spots RTP packets from a Media Sender using an SSRC that collides with the one it picked, it MUST change its own SSRC following the procedures of [1]. And it MUST do this immediately after noticing, no waiting around 🫶
A Distribution Source MAY use out-of-band information about the Media Sender SSRC(s) used in the media session, when it's available, to avoid SSRC collisions with Media Senders 🦋 Still, the Distribution Source MUST monitor Sender Report (SR) packets to detect any changes, observe collisions, and then follow the collision-resolution procedure above. The out-of-band info is a helper, not a replacement for watching the SRs 👀
For collision resolution between the Distribution Source and receivers or the Feedback Target(s) (if they're a separate entity, as described in the next subsection), the Distribution Source and the Feedback Target (if separate) operate similarly to ordinary receivers 💖
7.3. Disjoint Distribution Source and Feedback Target 🧚
If the Distribution Source and the Feedback Target are disjoint, the processing of the Distribution Source is limited by how much RTCP feedback information the Feedback Target makes available 🌸
The Feedback Target(s) MAY simply forward all RTCP packets incoming from the RTP receivers to the Distribution Source. In that case, the Distribution Source has all the necessary information available to perform all the functions described above, which is honestly the easiest vibe ✨
The Feedback Target(s) MAY also perform aggregation of incoming RTCP packets and send only aggregated information to the Distribution Source. In this case, the Feedback Target(s) MUST use correctly formed RTCP packets to communicate with the Distribution Source, and they MUST operate in concert with the Distribution Source so that the Distribution Source and the Feedback Target(s) appear to be operating as a single entity 👑 The Feedback Target(s) MUST report their observed receiver group size to the Distribution Source, either explicitly by means of RSI packets or implicitly by forwarding all RR packets.
Note: For example, for detailed statistics reporting, the Distribution Source and the Feedback Target(s) may need to agree on a common reporting granularity, so that the Distribution Source can aggregate the buckets coming in from various Feedback Targets into one coherent report for the receivers. Teamwork makes the dream work 🍓
The joint behavior of the Distribution Source and Feedback Target(s) MUST be reflected in the (SDP-based) media session description, as per Section 7.2.2. Bestie, this part is non-negotiable 📝
If the Feedback Target performs summarization functions, it MUST also act as a receiver and choose a unique SSRC for its own reporting towards the Distribution Source. The collision-resolution considerations for receivers apply here too 💜
7.4. Receiver Behavior 🎀
An RTP receiver MUST process RSI packets and adapt session parameters, such as the RTCP bandwidth, based on the information received. Ngl the receiver doesn't have a global view of the session anymore, so it can't hear from individual receivers except itself 🥺 BUT the info from the Distribution Source can be super detailed, giving the receiver an accurate view of overall session quality without the processing overhead of listening to and analyzing every single Receiver Report. Iconic efficiency 😭
The RTP receiver MUST process the report blocks contained in any RTP SR and RR packets to complete its view of the RTP session.
The SSRC collision list MUST be checked against the SSRC selected by the receiver, to make sure there are no collisions, as MUST be incoming RTP packets from the Media Senders. A receiver that observes RTP packets from a Media Sender with an SSRC that collides with its own chosen SSRC MUST change its own SSRC following the procedures of [1]. The receiver MUST do so immediately after noticing, and before sending any (further) RTCP feedback messages 🙈
A Group and Average Packet Size sub-report block is most likely to be appended to the RSI header. Either a Group Size sub-report or an RTCP Bandwidth sub-report MUST be included. The group size n lets a receiver calculate its share of the RTCP bandwidth, r. Given R, the total available RTCP bandwidth share for receivers (in the SSM RTP session), r = R/(n). For the group size calculation, the RTP receiver MUST NOT include the Distribution Source, i.e., the only RTP receiver sending RSI packets 🧮
The receiver RTCP bandwidth field MAY override this value. If the receiver RTCP bandwidth field is present, the receiver MUST use this value as its own RTCP reporting bandwidth r. Override energy 💅
If the RTCP bandwidth field was used by the Distribution Source in an RTCP session, but this field was not included in the last five RTCP RSI reports, the receiver MUST revert to calculating its bandwidth share based upon the group size information. Plot twist, we go back to the group size 🔄
If the receiver has not received any RTCP RSI packets from the Distribution Source for a period of five times the sender reporting interval, it MUST cease transmitting RTCP Receiver Reports until the next RTCP RSI packet is received. Radio silence until it hears from the Distribution Source again 🤫
The receiver can use the summarized data as desired. This data is most useful for giving the receiver a more global view of the conditions other receivers are experiencing, and it lets the client place itself within the distribution and work out how far its own reported conditions match the group reports as a whole 🌈 Appendix B has more info and examples of data processing at the receiver 📚
The receiver SHOULD assume that any sub-report blocks in the same packet correspond to the same data set the Distribution Source received during the last reporting time interval. This applies to packets with multiple blocks, where each block conveys a different range of values 🍓
A receiver MUST NOT rely on all of the RTCP packets it sends reaching the Media Senders or any other receiver. RR statistics will be aggregated, BYE packets will be processed, and SSRC collisions will usually be announced, but processing and/or forwarding of further RTCP packets is up to the discretion of the Distribution Source and will be performed as specified in the session description. Not every message is guaranteed to arrive, so don't count on it 🫠
If a receiver has out-of-band information available about the Media Sender SSRC(s) used in the media session, it MUST NOT use the same SSRC for itself. The receiver MUST be aware that such out-of-band information may be outdated (i.e., the sender SSRC(s) may have changed), and it MUST follow the collision-resolution procedure above if necessary. Stay alert, babe 👀
A receiver MAY use such Media Sender SSRC information when available, but it MUST beware of potential changes to the SSRC, which can only be learned from Sender Report (SR) packets ⭐
7.5. Media Sender Behavior 💜
Media Senders listen on a unicast or multicast transport address for RTCP reports sent by the receivers (and forwarded by the Distribution Source), or by other Media Senders (optionally forwarded by the Distribution Source) 🦋
Unlike in the simple forwarding model, Media Senders MUST be able to process RSI packets from the Distribution Source to determine the group size and their own RTCP bandwidth share. Media Senders MUST also be capable of determining the group size (and their corresponding RTCP bandwidth share) from listening to (forwarded) RTCP RR and SR packets, as mandated in [1]. Double-check that math, it's giving responsibility 🧠
As long as they send RTP packets, they MUST also send RTCP SRs, as defined in [1]. No skipping the SRs, periodt 📻
A Media Sender that observes an SSRC collision with another entity that is not also a Media Sender MAY delay its own collision-resolution actions, as per [1], by 5 * 1.5 * Td, with Td being the deterministic calculated reporting interval, so receivers get the chance to see whether the conflict still exists ⏳ SSRC collisions with other Media Senders MUST be acted upon immediately, no drama.
Note: This gives precedence to Media Senders and places the burden of collision resolution on RTP receivers. Receivers really are the MVPs here 👑
Sender SSRC information MAY be communicated out-of-band, e.g., by means of SDP media descriptions. Therefore, senders SHOULD NOT change their own SSRC eagerly or unnecessarily. Don't be a drama queen with your SSRC 🙅♀️💖
8. Mixer/Translator Issues 🌸
The original RTP specification allows a session to use mixers and translators to help connect heterogeneous networks into one session. BUT there are a bunch of issues raised by the unicast feedback model proposed in this document 😵💫 The term 'mixer' refers to devices that provide data stream multiplexing, where multiple sources are combined into one stream. A translator, on the other hand, doesn't multiplex streams. It just acts as a bridge between two distribution mechanisms, e.g., a unicast-to-multicast network translator. Since the issues raised by this document apply equally to either a mixer or a translator, the latter are referred to from this point onwards as mixer-translator devices 🧚
A mixer-translator between distribution networks in a session MUST ensure that all members in the session receive all the relevant traffic, so the clients can do their usual thing 🎀 A typical use might be connecting an older implementation of an RTP client with an SSM distribution network, where the client can't unicast feedback to the source. In that case, the mixer-translator MUST join the session on behalf of the client and send and receive traffic from the session to the client. Certain hybrid scenarios may have different requirements 🦋
8.1. Use of a Mixer-Translator 💅
The mixer-translator MUST adhere to the SDP description [5] for the single-source session (Section 11) and use the feedback mechanism indicated. Implementers of receivers SHOULD be aware that when a mixer-translator is present in the session, more than one Media Sender may be active, since the mixer-translator may be forwarding traffic to the SSM receivers either from multiple unicast sources or from an ASM session 👀 Receivers SHOULD still forward unicast RTCP reports in the usual manner to their assigned Feedback Target/Distribution Source, which in this case, by assumption, would be the mixer-translator itself. It is RECOMMENDED that the simple packet-reflection mechanism be used under these circumstances, since attempting to coordinate RSI + summarization reporting between more than one source may get complicated unless the mixer-translator is capable of summarization 🫶
8.2. Encryption and Authentication Issues 🔐
Encryption and security issues are discussed in detail in Section 11. Security is serious business, so take it seriously 🥹 A mixer-translator MUST be able to follow the same security policy as the client in order to unicast RTCP feedback to the source, and it therefore MUST be able to apply the same authentication and/or encryption policy required for the session. Transparent bridging and subsequent unicast feedback to the source, where the mixer-translator is not acting as the Distribution Source, is only allowed if the mixer-translator can conduct the same source authentication as required by the receivers. A translator MAY forward unicast packets on behalf of a client, but it SHOULD NOT translate between multicast-to-unicast flows towards the source without authenticating the source of the feedback address information 🔒💜
9. Transmission Interval Calculation ✨
okay so the Control Traffic Bandwidth from [1] is basically an arbitrary number 🎀 It's meant to be handed over by a session-management app (think SDR [21]) or figured out from how much bandwidth one single sender in the session gets.
The RTCP transmission interval either stays exactly the same as in the original RTP spec [1], or it uses the algorithm in [10] when bandwidth modifiers have been set for the session. Pick your fighter 💅
9.1. Receiver RTCP Transmission
bestie, this one's giving receivers homework 📚 If the Distribution Source is running in Simple Feedback Model (the session description might say so, and the receiver can also tell from the lack of RTCP RSI packets), a receiver MUST count the other members in the session using its own SSRC count, which it gets from the forwarded Sender and Receiver Reports it receives. The receiver MUST also work out the average RTCP packet size from every RTCP packet it receives. 🧮
If the Distribution Source is running in Distribution Source Feedback Summary Model, the receiver MUST use either the group size field and the average RTCP packet size field, or the Receiver Bandwidth field, from the matching sub-report blocks attached to the RSI packet. Either way works, no cap 🫶
The receiver plugs these values into the deterministic calculated interval as per [1] and [10]. ✨
9.2. Distribution Source RTCP Transmission
the Distribution Source has its own little checklist 🌸 In Simple Feedback Model, it MUST calculate the transmission interval for its Receiver Reports and associated RTCP packets, based on the control traffic bandwidth from above, and it MUST count itself as an RTP receiver. Receiver Reports get forwarded as soon as they arrive, no extra thinking needed. The Distribution Source MAY choose to check that all or only some receivers roughly stay within the calculated bandwidth limits, and it MAY choose to drop extra packets from any receiver that doesn't. 🚫
In all cases, the average RTCP packet size is worked out from the forwarded Media Senders' and receivers' RTCP packets, plus the ones the Distribution Source makes itself. Main character energy for the whole group 👑
If it's running in Distribution Source Feedback Summary Model, the Distribution Source does not share the forward RTCP bandwidth with any of the receivers. So it SHOULD use the full RTCP bandwidth for its Receiver Reports and associated RTCP packets, plus RTCP RSI packets. In this case the average RTCP packet size only comes from RTCP packets the Distribution Source originates itself. 💖
The Distribution Source feeds these values into the deterministic calculated interval as per [1] and [10]. Done and dusted ✨
9.3. Media Senders RTCP Transmission
in Simple Feedback Model, Media Senders get all their RTCP SRs and RRs the same way they would in an ASM session. The only difference is that the Distribution Source is the one forwarding them 🦋 They MUST do their RTCP group size estimate and calculate the deterministic transmission interval as per [1] and [10].
In Distribution Source Feedback Summary Model, Media Senders still get all RTCP SRs like they would in ASM. For the RR side, they either get RTCP RR reports the usual ASM way (if the Distribution Source forwards them) or they get RSI packets with summaries. If the RR reports are forwarded, they MUST do their RTCP group size estimate and calculate the deterministic transmission interval as per [1] and [10]. If they get RSI packets instead, they MUST combine what they learned from the Sender Reports and the RSI packets to build a complete view of the group size and the average RTCP packet size, then calculate the deterministic transmission interval as per [1] and [10] using those inputs. It's like puzzle time, but make it iconic 🧩💅
9.4. Operation in Conjunction with AVPF and SAVPF
if the RTP session is an AVPF session [15] or an SAVPF session [28] (instead of a regular AVP [6] session), receivers MAY change how they schedule their RTCP reports, as defined in [15]. Using AVPF or SAVPF does not change how the Distribution Source transmits or forwards RTCP, so it stays the same no matter what 🙈
It is RECOMMENDED that a Distribution Source, plus any separate Feedback Target(s), get set up to forward AVPF/SAVPF-specific RTCP packets. That way nobody counteracts the damping mechanism built into AVPF 🛑 They MAY also optionally aggregate the feedback information from the receivers as per Section 7.2.2. If only generic feedback packets are in use, and the Distribution Source understands them and can easily aggregate them, the Distribution MAY combine several incoming RTCP feedback packets and forward the aggregate along with its next RTCP RR/RSI packet. In every case, the Distribution Source and Feedback Target(s) SHOULD keep the extra delay as small as possible when forwarding feedback, but the Distribution Source MUST stay within its RTCP bandwidth constraints. Rules are rules, babe 📏
Now, if specific APP packets are used that don't have a format or summarization mechanism understood by the Feedback Target(s) and/or the Distribution Source, it is RECOMMENDED that those packets get forwarded with minimal delay. Otherwise the receiver's ability to send timely feedback is likely to take a hit 😭
10. SDP Extensions 🎀
the Session Description Protocol (SDP) [5] is how we describe media sessions in terms of transport addresses, codecs, and other attributes. Signaling that RTCP feedback will be sent via unicast, as this document specifies, needs one more session parameter in the session description. Other SSM RTCP feedback parameters also need to be provided, like the summarization model at the sender and the target unicast address that feedback should go to. This section defines the SDP parameters that the mechanisms in this document need (and that have been registered with IANA). It's giving organization 🗂️
10.1. SSM RTCP Session Identification
a new session-level attribute MUST be used to indicate unicast feedback instead of multicast feedback: "rtcp-unicast".
This attribute takes one parameter to specify the model of operation. An optional set of parameters specifies the behavior for RTCP packet types (and subtypes).
rtcp-unicast:reflection
This attribute MUST be used to indicate the "Simple Feedback" model of operation, where the Distribution Source reflects packets (without further processing). 🪞
rtcp-unicast:rsi *(SP <processing>:<rtcp-type>])
This attribute MUST be used to indicate the "Distribution Source Feedback Summary" model of operation. In this model, a list of parameters may be used to explicitly specify how RTCP packets originated by receivers get handled. The options for processing a given RTCP packet type are:
aggr: The Distribution Source has means for aggregating the contents of the RTCP packets and will do so.forward: The Distribution Source will forward the RTCP packet unchanged.term: The Distribution Source will terminate the RTCP packet.
The default rules apply if no parameters are specified, like so:
- RR and SDES packets MUST be aggregated and MUST lead to RSI packets being generated.
- All other RTP packets MUST be terminated at the Distribution Source (or Feedback Target(s)).
The SDP description only needs to specify deviations from the default rules. Aggregation of RR packets and forwarding of SR packets MUST NOT be changed. Don't mess with the classics 💀
The token for the new SDP attribute is "rtcp-unicast", and the formal SDP ABNF syntax for the new attribute value looks like this:
att-value = "reflection"
/ "rsi" *(SP rsi-rule)
rsi-rule = processing ":" rtcp-type
processing = "aggr" / "forward" / "term" / token ;keep it extensible
rtcp-type = 3*3DIGIT ;the RTCP type (192, 193, 202--209)10.2. SSM Source Specification
in a Source-Specific Multicast RTCP session, the address of the Distribution Source has to be indicated in two places: for the source-specific joins to the multicast group, and for addressing unicast RTCP packets on the backchannel from receivers to the Distribution Source. 📡
This is done by following the SDP source filters proposal documented in [4]. According to that spec, only the inclusion model ("a=source-filter:incl") MUST be used for SSM RTCP. There SHOULD be exactly one "a=source-filter:incl" attribute listing the address of the Distribution Source. The RTCP port MUST be derived from the m= line of the media description. 🧭
An alternative Feedback Target Address and port MAY be supplied using the SDP RTCP attribute [7], for example:
a=rtcp:<port> IN IP4 192.0.2.1This attribute only defines the transport address of the Feedback Target and does not affect the SSM group specification for media stream reception. Two "source-filter" attributes MAY be present to indicate an IPv4 and an IPv6 representation of the same Distribution Source. Dual-stack glow-up 🌈
10.3. RTP Source Identification
the SSRC information for the Media Sender(s) MAY be communicated explicitly out of band (meaning outside the RTP session). One option for doing that is the Session Description Protocol (SDP) [5]. If that kind of indication is wanted, the "ssrc" attribute [12] MUST be used for this purpose. As per [12], the "cname" Source Attribute MUST be present. Further Source Attributes MAY be specified as needed. 🏷️
If it's used in an SDP session description of an RTCP-SSM session, the ssrc MUST contain the SSRC that the respective Media Sender intends to use, and the cname MUST equal the CNAME for that Media Sender. If present, the role SHOULD indicate the function of the RTP entity identified by this line. Right now, only the "media-sender" role is defined. 🎭
Example:
a=ssrc:314159 cname:iptv-sender@example.comIn the example above, the Media Sender is identified as using the SSRC identifier 314159 and the CNAME iptv-sender@example.com. Chef's kiss 🤌
11. Security Considerations 🔐
⚠️ this section is serious business, bestie. Read every word.
The level of security the current RTP/RTCP model provides MUST NOT be weakened by adding unicast feedback to the source. This section lists the security weaknesses the feedback mechanism introduces, the potential threats, and the level of protection that MUST be adopted. Any suggestions for raising the security of RTP sessions above the current standard are RECOMMENDED but OPTIONAL. The final section outlines some security frameworks that are suitable for conforming to this specification. 🛡️💜
11.1. Assumptions ✨
okay so RTP/RTCP carries real-time multimedia, which means low overhead is the whole vibe 💅 any security framework has to stay light, and that includes the cost of each kind of crypto operation AND the cost of setting up security infrastructure for big groups 🫶
distributing session parameters (usually SDP objects) through the Session Announcement Protocol (SAP) [22], over email, or over the web is outside this document's scope 🌸 but it is RECOMMENDED that whatever method you pick uses adequate security measures to make sure the info has integrity and authenticity 🔐 suitable solutions that meet the security requirements here are listed at the end of this section ✨
in practice, the multicast and group distribution mechanism (e.g., the SSM routing tree) is not immune to source IP address spoofing or traffic snooping 🙈 however, this document does not discuss those concerns. for everything that follows, security weaknesses are handled at the transport level or above 🦋
11.2. Security Threats 💀
attacks on media distribution and the feedback architecture proposed here can show up in a bunch of different ways 🎀 here's the detailed breakdown:
a) Denial of Service (DoS)
DoS is a MAJOR concern 😭 because of how the communication architecture works, an attacker can create a DoS in several ways by using the unicast feedback channel to their advantage 🔥
b) Packet Forgery
another potential attack is packet forgery ✍️ it's super important to protect the integrity of certain influential packets, because if those get compromised, the transmission characteristics of the WHOLE group could be directly affected 😱
c) Session Replay
session recording and later replay is also a concern 📼 an attacker doesn't even need to understand the packet content. they can just record the data stream and, later on, replay it to any receivers who are listening 🫠
d) Eavesdropping on a Session
an attacker eavesdropping on a session is already a security weakness on its own 👀 and it can also set up other attacks, so it's treated as a potential threat too. for example, an attacker could use what they overheard to pull off a smarter DoS attack 😈
11.3. Architectural Contexts 🧚
to really get what the solution needs, we look at the threats above in each of the three communication contexts 💜
a) Source-to-Receiver Communication
the downstream channel (source to receivers) is critical to protect 🔒 because it controls the behavior of the whole group. it carries the bandwidth allocation for each receiver, which decides how fast RTCP traffic gets unicast straight back to the source 🚀 all the traffic on this downstream channel comes from a single source. both the RTP data stream and the RTCP control data from the source are part of this context, and the RTCP data the source generates is indirectly shaped by the group feedback 🌈
the downstream channel is vulnerable to all four attack types above 🫣 DoS is possible but it's less of a worry than the others. the worst-case DoS effect would be large volumes of traffic going over the distribution channel, potentially reaching every receiver, but only on a one-to-one basis. so this threat is no more pronounced than in the current multicast ASM model ✨ the real danger of DoS in this context comes indirectly, through compromised source RTCP traffic 😬 if receivers get an incorrect group size estimate or bandwidth allowance, the return traffic to the source may create a distributed DoS effect on the source itself. similarly, an incorrect feedback address (whether from a malicious attack or by mistake, like an IP address configuration error or a typo) could directly create a denial of service attack on another host 🙃
there's also a concern about DoS coming indirectly through fake BYE packets, which could make the source adjust the advertised group size 👻 a Distribution Source MUST follow the correct rules for timing out members in a session before it reports a change in group size. that gives the authentic SSRC enough time to keep reporting and, as a result, cancel the fake BYE report 💅
packet forgery could, in the worst case, be used to maliciously start a DoS attack 😤 for example, if an attacker can spoof the source address and inject incorrect packets into the data stream, or intercept the source RTCP traffic and modify its fields 🕵️
a session replay would recreate the receiver feedback to the source address at a time when the source is NOT expecting more traffic from what could be a large group 📭 on its own this attack may be less effective, but combined with other attacks it could be serious 😳
eavesdropping on the session gives an attacker info about the characteristics of the source-to-receiver traffic, like how often RTCP traffic shows up 👂 if RTCP traffic is unencrypted, this could also reveal valuable details like group size, Media Source SSRC(s), and the transmission characteristics of the receivers back to the source 📊
b) Receiver-to-Distribution-Source Communication
the second context is the return traffic from the group to the Distribution Source 📥 this traffic should ONLY consist of RTCP packets, including Receiver Reports, SDES information, BYE reports, extended reports (XR), feedback messages (RTPFB, PSFB), and possibly application-specific packets 🎀 compromising a single receiver or a subset of them isn't likely to have as big an impact as in context (a) 🙌 however, a lot of the responsibility for spotting a compromised source data stream falls on the receivers 👀
the effects of compromising critical Distribution Source control information can be seriously amplified in this context 🚨 a large group of receivers could accidentally launch a distributed DoS attack on the Distribution Source if the integrity of the source RTCP channel is compromised and the individual receivers don't notice 😱
an attacker who can pull off packet forgery could inject false RTCP traffic and create fake SSRC identifiers 🎭 these attacks might slow down the overall control channel data rate, because the group size could be misperceived 🐢 similarly, an attacker creating fake BYE reports would cause some group size instability, but it shouldn't be effective as long as the source applies the correct timeout rules when removing SSRC entries from its database 💖
a replay attack on receiver return data to the source has the same implications as generating false SSRC identifiers and RTCP traffic toward the source 🔁 so ensuring the authenticity and freshness of the data source is important 🫶
eavesdropping in this context could give an attacker a LOT of potentially personal information about a large group of receivers, available from SDES packets 🫣 it would also reveal info on the group's traffic-generation characteristics and the parameters used to calculate individual receiver bandwidth allowances 📉
c) Receiver-to-Feedback-Target Communication
the third context is the return traffic from the group to the Feedback Target 🎯 it suffers from the same threats as the receiver-to-source context, with one big difference: now a large group of receivers could accidentally launch a distributed DoS (DDos) attack on the Feedback Target 💥 and there's no way to tell whether the DDoS is deliberate or just a misconfiguration of the Feedback Target Address 🤷♀️ deliberate attacks can be mitigated by properly authenticating messages that communicate the Feedback Target Address (that's the SDP session description and the Feedback Target Address sub-report block carried in RTCP) ✅ but a misconfigured address comes from an authenticated source, so security mechanisms CAN'T prevent it 😩
the Feedback Target also can't communicate its predicament to either the Distribution Source or the session receivers 📵 from the feedback packets it receives, the Feedback Target can't tell which SSM multicast group the feedback belongs to, or which Distribution Source it's from, so analysis and suppression are way harder 🫠 the Feedback Target may not even support RTCP or listen on the port number in question 🙈
note that the DDoS happens inside the RTCP session, and the unicast receivers follow the transmission interval calculations ([1], [10]). so in the misconfigured case, the bandwidth misdirected toward the Feedback Target is capped at a percentage of the session bandwidth, i.e., the Control Traffic Bandwidth established for the session 🧮 that's a built-in limit, kinda iconic of the protocol 👑
11.4. Requirements in Each Context ✨
okay so now we get to the actual requirements for each context 💅 to deal with all those threats from the last sections. here's the vibe for each one:
a) the big scary one in the source-to-receiver context is denial of service through packet forgery 😭. the forgery can look like interception and modification of packets coming from the source, or the attacker can just inject fake packets into the distribution channel. to fight this, data integrity and source authenticity MUST be applied to source traffic 🔒. confidentiality isn't a requirement here, since eavesdropping doesn't mess with how the protocol works 🙈. BUT, and this is a big but, without confidentiality any external listener could read personal and group characteristics info totally unrestricted 💀. so confidentiality is RECOMMENDED 💖.
b) the receiver-to-source threats are the same kinds of attacks, just considered less important than the downstream traffic compromise 🦋. all the security weaknesses also apply to the current RTP/RTCP security model, so we only make recommendations for protecting against compromise. data integrity is RECOMMENDED so that interception and modification of an individual receiver's RTCP traffic can be detected 👀. that protects against false influence from group control information and the potentially more serious compromise of future services provided by the distribution functionality. in order to ensure security, data integrity and authenticity of receiver traffic is therefore also RECOMMENDED 🫶. for confidentiality, it's the same situation as the first context, so it is RECOMMENDED that precautions be taken to protect the privacy of the data 🌸.
c) the threats to the receiver-to-feedback-target context are similar to the receiver-to-source ones, so the recommendations to protect against them are similar too 🧚. however, there are a couple of situations with broader issues that are beyond the scope of this document:
- an endpoint experiencing DDoS or the side effects of a misconfigured RTCP session may not even be a participant in the session. it might not be listening on the respective port number, and it might even support RTCP, so it won't be able to react within RTCP 😵. figuring out that there's a problem is up to network administrators and, possibly, anti-malware software that can do correlation across receiver nodes 🕵️♀️.
- with misconfiguration, the normally desirable usage of SRTP and SRTCP unfortunately becomes undesirable 😤. because the packet content is encrypted, neither the misconfigured Feedback Target nor the network administrator can work out the root cause of the traffic 🔐.
in the case where the misconfigured Feedback Target happens to be a node participating in the session, or is an RTCP-enabled node, the Feedback Target Address block gives the Distribution Source a dynamic way to signal an alternative unicast RTCP feedback address to the receivers 🎯. as this type of packet MUST be included in every RTCP packet originated by the Distribution Source, all receivers can obtain the corrected Feedback Target information 📦. that way, receiver behavior should remain consistent even with packet loss or late-session arrivals 🌈. the only caveat is that the misconfigured Feedback Target is largely uninvolved in repairing the situation, so it relies on others to detect the problem 🥲.
an additional security consideration, which isn't a component of this specification but still has a direct influence on the general security, is where the session-initiation data comes from 👑. this is the SDP parameters that get communicated to the members before the session starts, via channels like an HTTP server, email, SAP, or other means. it's beyond the scope of this document to put any strict requirements on the external communication of that information. however, suitably secure SDP communication approaches are outlined in Section 11.7 🍓.
11.5. Discussion of Trust Models 💜
as we covered in the previous sections, source authenticity is a fundamental requirement of the protocol 🔑. it's also important to clarify which trust model would be acceptable for meeting that requirement. there are two fundamental models that apply here:
a) the shared-key model, where all authorized group members share the same key and can equally encrypt and decrypt the data 🗝️. this method assumes an out-of-band method is used to distribute the shared group key, making sure every key-holder is individually authorized to receive it. and if members leave the group, a re-keying exercise can happen 🔄. the advantage is that the costly processing of one-way key-authentication techniques is avoided, along with the need to run extra cipher operations with alternative key sets on the same data set, e.g., if data confidentiality is also applied 🙌. the disadvantage is that, for very large groups where the receiver set becomes effectively untrusted, a shared key doesn't offer much protection 😬.
b) the public-key authentication model, using cryptosystems such as RSA-based or PGP authentication, gives a more secure method of source authentication at the cost of higher processing overhead 🧠. this is typically not recommended for real-time data streams, but for RTCP reports, which are distributed with a minimum interval of 5 seconds, it may be a viable option 💫. (the processing overhead might still be too great for small, low-powered devices, so it should be considered with caution 🪫.) wherever possible, though, public key source authentication is preferable to the shared key model above ✨.
as far as protocol acceptability goes, either model is acceptable, although it is RECOMMENDED that the more secure public-key-based options be applied wherever possible 🎀.
11.6. Recommended Security Solutions 🌸
this section presents some existing security mechanisms that are RECOMMENDED for suitably addressing the requirements outlined in Section 11.5 🛠️. this is only intended as a guideline, and it's acknowledged that there are other solutions that would also be suitable for complying with the specification 🤍.
11.6.1. Secure Distribution of SDP Parameters 📨
a) SAP, HTTPS, Email -- initial distribution of the SDP parameters for the session SHOULD use a secure mechanism, like the SAP authentication framework, which lets an authentication certificate be attached to the session announcements 🔏. other methods might involve HTTPS or signed email content from a trusted source. but some more commonly used techniques for distributing session information and starting media streams are the Real-Time Streaming Protocol (RTSP) [25] and SIP [14] 📡.
b) RTSP -- RTSP provides a client- or server-initiated stream control mechanism for real-time multimedia streams 🎬. the session parameters are conveyed using SDP syntax, and it may adopt standard HTTP authentication mechanisms in combination with suitable network (e.g., IPsec)- or transport (e.g., Transport Layer Security (TLS))-level security 🛡️.
c) SIP -- a typical use of SIP involving a unicast feedback identifier might be a client wanting to dynamically join a multi-party call on a multicast address using unicast RTCP feedback 📞. the client would be required to authenticate the SDP session descriptor information returned by the SIP server 🪪. the recommended method for this, as outlined in the SIP specification [14], is to use an S/MIME message body containing the session parameters, signed with an acceptable certificate 💌.
for the purposes of this profile, it's acceptable to use any suitably secure authentication mechanism that establishes the identity and integrity of the information provided to the client 💖.
11.6.2. Suitable Security Solutions for RTP Sessions with Unicast Feedback 🦋
a) SRTP -- SRTP [3] is the recommended Audio/Video Transport (AVT) security framework for RTP sessions 🎧. it specifies the general packet formats and cipher operations that are used, and it gives you the flexibility to pick different stream ciphers based on preference or requirements 🎛️. it can provide confidentiality of the RTP and RTCP packets, as well as protection against integrity compromise and replay attacks 🔁. it authenticates the data stream using the shared-key trust model. any suitable key-distribution mechanism can be used in parallel to the SRTP streams 🗂️.
b) IPSEC -- a more general group security profile that might be used is the Group Domain of Interpretation [23], which defines the process of applying IPSec mechanisms to multicast groups 🌐. this requires the use of the Encapsulating Security Payload (ESP) in tunnel mode as the framework, and it provides the capability to authenticate, either using a shared key or individually through public-key mechanisms 🔐. it should be noted that using IPSec would break the 'transport-independent' condition of RTP, so it would not be useable for anything other than IP-based communication 🙅♀️.
c) TESLA -- Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [24] is a scheme that offers a more flexible approach to data authentication using time-based key disclosure ⏰. the authentication uses one-way, pseudo-random key functions based on key chain hashes, which have a short period of authenticity based on the key disclosure intervals from the source 🔗. as long as the receiver can make sure the encrypted packet is received before the source discloses the key, which requires loose time synchronization between source and receivers, it can prove the packet's authenticity ✅. the scheme does add a delay to packet distribution and decryption because of the key disclosure delay 🐢. however, the processing overhead is much lower than other standard public-key mechanisms, so it may be more suited to small or energy-restricted devices 🔋.
11.6.3. Secure Key Distribution Mechanisms 🗝️
a) MIKEY -- Multimedia Internet KEYing (MIKEY) [29] is the preferred solution for SRTP sessions, providing a shared group-key distribution mechanism and intra-session rekeying facilities 🌟. if a partly protected communication channel exists, keys may also be conveyed using SDP as per [27] 📜.
b) GSAKMP -- The Group Secure Association Key Management Protocol (GSAKMP) is the general solution favored for Multicast Secure group-key distribution 🌍. it is the recommended key distribution solution for Group Domain of Interpretation (GDOI) [RFC3547] sessions 🥰.
11.7. Troubleshooting Misconfiguration
okay so we already covered this, but the security stuff won't save you if an authorized source sends out wrong info about the Feedback Target 🙃. Even if it's properly authenticated and integrity-protected, it's still wrong. The accidentally-chosen Feedback Target then gets RTCP packets from a potentially huge crowd of receivers. At least the RTCP rate is capped by the RTCP timing rules 🫶
BUT the RTCP packets don't carry much context, and if they're encrypted they carry none at all 😭. So the people running the network with the Feedback Target have a hard time debugging, like tracking down whoever caused the misconfiguration and telling them about it 💀
One suitable approach might be adding explicit context info to RTCP packets so you can figure out the source 🔍. That packet could be defined in this specification, but it would be totally useless with SRTP/SRTCP and encrypted RTCP reports 🙈. Since the extensions in this document might not be the only thing that runs into this problem, it's desirable to find a fix that works for RTP at large 💜. Those mechanisms are for further study in the AVT WG 🧚
12. Backwards Compatibility ✨
Unicast feedback to the source shouldn't cause any serious backwards compatibility drama 💅. The RTP data streams stay unaffected, and so do the RTCP packets from the Media Sender(s), which keep enabling inter-stream synchronization when there are multiple streams 🎀. Sending unicast RTCP to a source that can't redistribute the traffic by simple reflection or through summaries could have serious security implications, as outlined in Section 11 🙀, but it wouldn't actually break the operation of RTP 🌸
For RTP-compliant receivers that don't understand the unicast mechanisms, the RTCP traffic may still reach the group if an ASM distribution network is used 🦋. In that case there may be some duplication of traffic due to the reflection channel, but this should be ignored 🙃. It's anticipated, however, that the distribution network will typically not let the receiver multicast RTCP traffic. Then the data gets lost and the RTCP calculations won't include those receivers 😭
It is RECOMMENDED that any session that may involve non-unicast-capable clients always uses the simple packet-reflection mechanism 👑. That way the packets received can be understood by all clients, which is literally the whole point 🫶
13. IANA Considerations 🌈
The following contact information shall be used for all registrations included here 📇:
Contact: Joerg Ott
mail: jo@acm.org
tel: +358-9-470-22460Based on the guidelines suggested in [2], a new RTCP packet format has been registered with the RTCP Control Packet type (PT) Registry 🎟️:
Name: RSI
Long name: Receiver Summary Information
Value: 209
Reference: This document.This document defines a substructure for RTCP RSI packets 🧩. A new sub-registry has been set up for the sub-report block type (SRBT) values for the RSI packet, with the following registrations created initially 📋:
Name: IPv4 Address
Long name: IPv4 Feedback Target Address
Value: 0
Reference: This document.
Name: IPv6 Address
Long name: IPv6 Feedback Target Address
Value: 1
Reference: This document.
Name: DNS Name
Long name: DNS Name indicating Feedback Target Address
Value: 2
Reference: This document.
Name: Loss
Long name: Loss distribution
Value: 4
Reference: This document.
Name: Jitter
Long name: Jitter Distribution
Value: 5
Reference: This document.
Name: RTT
Long name: Round-trip time distribution
Value: 6
Reference: This document.
Name: Cumulative loss
Long name: Cumulative loss distribution
Value: 7
Reference: This document.
Name: Collisions
Long name: SSRC Collision list
Value: 8
Reference: This document.
Name: Stats
Long name: General statistics
Value: 10
Reference: This document.
Name: RTCP BW
Long name: RTCP Bandwidth indication
Value: 11
Reference: This document.
Name: Group Info
Long name: RTCP Group and Average Packet size
Value: 12
Reference: This document.The value 3 shall be reserved as a further way of specifying a Feedback Target Address 🎯. The value 3 MUST only be allocated for a use defined in an IETF Standards Track document 📜
Further values may be registered on a first come, first served basis 🙋♀️. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter, as well as the syntax and semantics of the associated sub-report block 📚. The general registration procedures of [5] apply 💅
In the registry for SDP parameters, the attribute named "rtcp-unicast" has been registered as follows 🎀:
SDP Attribute ("att-field"):
Attribute Name: rtcp-unicast
Long form: RTCP Unicast feedback address
Type of name: att-field
Type of attribute: Media level only
Subject to charset: No
Purpose: RFC 5760
Reference: RFC 5760
Values: See this document.14. References 📚
14.1. Normative References
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[3] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[4] Quinn, B. and R. Finlayson, "Session Description Protocol (SDP) Source Filters", RFC 4570, July 2006.
[5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[6] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[7] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[8] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific Protocol Independent Multicast in 232/8", BCP 120, RFC 4608, August 2006.
[9] 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.
[10] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.
[11] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[12] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.
[13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[15] 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.
[16] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress, October 2003.
[17] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[18] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[19] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[20] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[21] Session Directory Rendez-vous (SDR), developed at University College London by Mark Handley and the Multimedia Research Group, http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/.
[22] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[23] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.
[24] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[25] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[26] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[27] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[28] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008.
[29] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
Appendix A. Examples for Sender-Side Configurations 🎬
This appendix describes a few common setups, focusing on the contribution side 🎥, i.e., the communications between the Media Sender(s) and the Distribution Source. In all cases, the same session description may be used for the distribution side as defined in the main part of this document 🫶. This is because this specification defines only the media stream setup between the Distribution Source and the receivers 💖
A.1. One Media Sender Identical to the Distribution Source ✨
okay so the simplest case is when the Distribution Source is literally the same thing as the Media Sender 💖 (see Figure 3). that means there's zero extra setup needed between the two, because they're already one and the same 🫶
Source-specific
+--------+ Multicast
| | +----------------> R(1)
|M D S | | |
|E I O | +--+ |
|D S U | | | |
|I T R | | +-----------> R(2) |
|A R C |->+----- : | |
| = I E | | +------> R(n-1) | |
|S B | | | | | |
|E U | +--+--> R(n) | | |
|N T | | | | |
|D I |<---------+ | | |
|E O |<---------------+ | |
|R N |<--------------------+ |
| |<-------------------------+
+--------+ UnicastFigure 3: Media Source == Distribution Source
A.2. One Media Sender ✨
ok this one is a little more involved 🦋 here the Media Sender and the Distribution Source are two separate entities, and they might be running on the same machine or on different ones. so the Media Sender has to get the media stream(s) over to the Distribution Source 📦 and it can do that by unicasting the RTP stream, by ASM multicast, or by SSM. then the Distribution Source takes over: it forwards the RTP packets that make up the media stream plus the RTCP Sender Reports out to the receivers, and it passes feedback from the receivers (and from itself!) back to the Media Sender 🔁
figure 4 shows the setup. the link between the Media Sender and the Distribution Source can be statically configured, or you can use SDP together with some signaling protocol to share the session parameters 💅 and fun detail: it's totally a local config thing for the Distribution Source to figure out how to connect the session between the Media Sender and itself (the Contribution session) with the session between itself and the receivers (the Distribution session) 🌸
Source-specific
+-----+ Multicast
+--------+ | | +----------------> R(1)
| Media |<---->| D S | | |
| Sender | | I O | +--+ |
+--------+ | S U | | | |
| T R | | +-----------> R(2) |
+--------+ | R C |->+----- : | |
| Media |<---->| I E | | +------> R(n-1) | |
|Sender 2| | B | | | | | |
+--------+ | U | +--+--> R(n) | | |
| T | | | | |
+--------+ | I |<---------+ | | |
| Media |<---->| O |<---------------+ | |
|Sender 3| | N |<--------------------+ |
+--------+ | |<-------------------------+
+-----+ UnicastFigure 4: One Media Sender Separate from Distribution Source
Wait, I need to correct the diagram above: the block I just wrote mixes up the one-sender layout, so here is the exact Figure 4 as it appears in the original:
Source-specific
+-----+ Multicast
| | +----------------> R(1)
| D S | | |
| I O | +--+ |
| S U | | | |
+--------+ | T R | | +-----------> R(2) |
| Media |<---->| R C |->+----- : | |
| Sender | | I E | | +------> R(n-1) | |
+--------+ | B | | | | | |
| U | +--+--> R(n) | | |
| T | | | | |
| I |<---------+ | | |
| O |<---------------+ | |
| N |<--------------------+ |
| |<-------------------------+
+-----+ Unicast
Contribution Distribution
Session Session
(unicast or ASM) (SSM)Figure 4: One Media Sender Separate from Distribution Source
A.3. Three Media Senders, Unicast Contribution ✨
similar vibes here, but now three Media Senders are all sending to an SSM multicast group through the Distribution Source 🎀 and each one sends its own media stream RTP packets to the Distribution Source via unicast 💜
the Distribution Source has a bigger job in this one. it's basically doing everything from the last example, plus it has to relay media traffic from each Media Sender out to the receivers and forward the (aggregated) feedback from the receivers back to the Media Senders 🧚 on top of that, it relays the RTCP packets (SRs) from each Media Sender to the other two 👑
the Media Senders are set up exactly the same way as before. it's only the Distribution Source that needs to know there are multiple senders and do the relaying 🫶 the transport address for the RTP session at the Distribution Source can be the same for every Media Sender (which may make correlation easier) or you can use different addresses 🦋
figure 5 shows it:
Source-specific
+-----+ Multicast
+--------+ | | +----------------> R(1)
| Media |<---->| D S | | |
|Sender 1| | I O | +--+ |
+--------+ | S U | | | |
| T R | | +-----------> R(2) |
+--------+ | R C |->+----- : | |
| Media |<---->| I E | | +------> R(n-1) | |
|Sender 2| | B | | | | | |
+--------+ | U | +--+--> R(n) | | |
| T | | | | |
+--------+ | I |<---------+ | | |
| Media |<---->| O |<---------------+ | |
|Sender 3| | N |<--------------------+ |
+--------+ | |<-------------------------+
+-----+ Unicast
Contribution Distribution
Session Session
(unicast) (SSM)Figure 5: Three Media Senders, Unicast Contribution
A.4. Three Media Senders, ASM Contribution Group ✨
this is the final example, and it's a glow-up 🌈 the individual unicast contribution sessions between the Media Senders and the Distribution Source get swapped out for one single ASM contribution group (aka one common RTP session). so now all the Media Senders get each other's traffic through IP-layer multicast 📡 and the Distribution Source doesn't need to do any explicit forwarding between the Media Senders anymore 🙌 it still forwards the feedback it gets from the receivers to the ASM contribution group, and that part is optional, so it can be sent as summaries 💅
the ASM contribution group can be statically configured, or the info can be shared using a standard SDP session description for a multicast session 🌸 and once again, the Distribution Source's implementation is the one that has to properly link the ASM contribution session and the SSM distribution sessions 🔗
figure 6 shows the whole vibe:
_ Source-specific
/ \ +-----+ Multicast
+--------+ | | | | +----------------> R(1)
| Media |<->| A | | D S | | |
|Sender 1| | S | | I O | +--+ |
+--------+ | M | | S U | | | |
| | | T R | | +-----------> R(2) |
+--------+ | G | | R C |->+----- : | |
| Media |<->| r |<->| I E | | +------> R(n-1) | |
|Sender 2| | o | | B | | | | | |
+--------+ | u | | U | +--+--> R(n) | | |
| p | | T | | | | |
+--------+ | | | I |<---------+ | | |
| Media |<->| | | O |<---------------+ | |
|Sender 3| \_/ | N |<--------------------+ |
+--------+ | |<-------------------------+
+-----+ Unicast
Contribution Distribution
Session Session
(ASM) (SSM)Figure 6: Three Media Senders in ASM Group
Appendix B. Distribution Report Processing at the Receiver ✨
B.1. Algorithm 🧮
here's how the receiver processes Loss Distribution Values, bestie 💜
Example processing of Loss Distribution Values
X values represent the loss percentage. Y values represent the number of receivers.
Number of x values is the NDB value
xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV) First data point = MnDV,first ydata
then
For each ydata => xdata += (MnDV + (xrange / NDB))B.2. Pseudo-Code 💻
the variables are split into two groups: the packet variables and the code variables 🎀
Packet Variables -> factor,NDB,MnDVL,MaDV Code variables -> xrange, ydata[NDB],x,y
xrange = MaDV - MnDV
x = MnDV;
for(i=0; i<NDB; i++) {
y = (ydata[i] * factor);
/*OUTPUT x and y values*/
x += (xrange / NDB);
}B.3. Application Uses and Scenarios ✨
Okay so bestie, providing a distribution function in a feedback message is genuinely useful for a whole bunch of different app types 🦋. The appendix lists some potential uses, but future apps will probably find their own cool ways to use it 🧚. The summarization format is super flexible, so new extensions can slot right in 💅. Some of these scenarios go beyond a simple SSM architecture, like single-source group topologies where every receiver might also be able to become the source 👑. Another one is multiple SSM topologies that combine into a bigger distribution tree 🌈.
A distribution of values is input for any algorithm, multicast or not, that could be tuned by having the feedback values for all group members 🔥. Here are some areas that would benefit:
- The parameterization of a multicast Forward Error Correction (FEC) algorithm. 🛡️ If you have a good estimate of the distribution of reported losses, a source or other distribution agent without a global view can tune how much redundancy goes into the FEC stream. The distribution helps show whether most of the group is struggling with high loss, or whether only a small subset is reporting it 😭. A receiver could also use this data to decide more wisely whether to leave a group where a very high percentage of members are worst-case reporters 🙈.
- The organization of a multicast data stream into layers for layered coding schemes. 🍓 The distribution of packet losses and delay shows what percentage of members see each loss and delay level, so the stream bandwidth can be split to suit the group conditions ✨. This needs the same algorithm on both senders and receivers so they derive the same results 🫶.
- The establishment of a suitable feedback threshold. 🎀 An app might want feedback values only when they're above (or below) a certain threshold 💖. But picking a good threshold is hard when the range and distribution of feedback values isn't known a priori 😵. In a very large group, knowing the distribution lets you set a reasonable threshold, which can prevent message implosion when lots of members share the same feedback value 💜. A typical example is a sensor network measuring temperature or some other natural phenomenon 🌸. Another is a network of mobile devices tracking signal power, so they can hand off to a different distribution device when power gets too low 📱.
- The tuning of Suppression algorithms. 💅 Knowing the distribution of round-trip times, bandwidth, and network loss lets you optimize wake-up timers and adjust the Suppression interval bounds properly 🔥. Biased wake-up functions can also be built to favor early responses from more capable members, smooth out responses from later ones, and avoid bursty response traffic 🦋.
- Leader election among a group of processes based on the maximum or minimum of some attribute value. 👑 Knowing the distribution of values lets a group pick a leader process, or processes, to act on its behalf 🧚. Leader election can boost scalability when group sizes get extremely large 🌈.
B.4. Distribution Sub-Report Creation at the Source ✨
Okay so this example shows two different ways to convey loss data using the generic format of a Loss sub-report block (Section 7.1.4) 💖. The same techniques could work for other distribution types too 🦋.
- The first method tries to represent the data in as few bytes as possible 💜.
- The second method conveys all values without saving any bandwidth 🙈.
Data Set
X values indicate loss percentage reported; Y values indicate the number of receivers reporting that loss percentage 🌸.
X - 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
Y - 1000| 800 | 6 | 1800 | 2600 | 3120 | 2300 | 1100 | 200 | 103
X - 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19
Y - 74 | 21 | 30 | 65 | 60 | 80 | 6 | 7 | 4 | 5
X - 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29
Y - 2 | 10 | 870 | 2300 | 1162 | 270 | 234 | 211 | 196 | 205
X - 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39
Y - 163 | 174 | 103 | 94 | 76 | 52 | 68 | 79 | 42 | 4Constant value
Because the multiplicative factor field is 4 bits, the maximum multiplicative value is 15 🎀.
The distribution type field of this packet would be value 1, since it represents loss data 💅.
Example: 1st Method
Description
The minimal method of conveying data, i.e., small amount of bytes used to convey the values 🧚.
Algorithm
Attempt to fit the data set into a small sub-report size, selected length of 8 octets 🌈.
Can we split the range (0 - 39) into 16 4-bit values? 🤔 The largest bucket value would, in this case, be the bucket for X values 5 - 7.5, the sum of which is 5970. An MF value of 9 generates a multiplicative factor of 2^9, or 512 -- which, multiplied by the max bucket value, produces a maximum real value of 7680 ✨.
The packet fields will contain the values:
Header distribution Block
Distribution Type: 1
Number of Data Buckets: 16
Multiplicative Factor: 9
Packet Length field: 5 (5 * 4 => 20 bytes)
Minimum Data Value: 0
Maximum Data Value: 39
Data Bucket values: (each value is 16-bits)Results, 4-bit buckets:
X - 0 - 2.5 | 2.5 - 5 | 5 - 7.5 | 7.5 - 10
(Y - 1803 | 4403 | 5970 | 853 ) ACTUAL
Y - 4 | 9 | 12 | 2
X - 10 - 12.5 | 12.5 - 15 | 15 - 17.5 | 17.5 - 20
(Y - 110 | 140 | 89.5 | 12.5) ACTUAL
Y - 0 | 0 | 0 | 0
X - 20 - 22.5 | 22.5 - 25 | 25 - 27.5 | 27.5 - 30
(Y - 447 | 3897 | 609.5 | 506.5) ACTUAL
Y - 1 | 8 | 1 | 1
X - 30 - 32.5 | 32.5 - 35 | 35 - 37.5 | 37.5 - 40
(Y - 388.5 | 221.5 | 159.5 | 85.5) ACTUAL
Y - 1 | 0 | 0 | 0Example: 2nd Method
Description
This demonstrates the most accurate method for representing the data set. This method doesn't attempt to optimise any values 🔥.
Algorithm
Identify the highest value and select buckets large enough to convey the exact values, i.e., no multiplicative factor 💖.
The highest value is 3120. This requires 12 bits (closest 2 bit boundary) to represent, therefore it will use 60 bytes to represent the entire distribution. This is within the max packet size; therefore, all data will fit within one sub-report block. The multiplicative value will be 1 🦋.
The packet fields will contain the values:
Header Distribution Block
Distribution Type: 1
Number of Data Buckets: 40
Multiplicative Factor: 0
Packet Length field: 18 (18 * 4 => 72 bytes)
Minimum Loss Value: 0
Maximum Loss Value: 39Bucket values are the same as the initial data set 💜.
Result
Selecting one of the three methods outlined above might be done by a congestion parameter or by user preference 🌸. The overhead for processing the packets is likely to differ very little between the techniques 🫶. The savings in bandwidth are apparent, though, using 20, 52, and 72 octets respectively 🎀. These values would vary more widely for a larger data set with less correlation between results 🔮.
Acknowledgements
The authors would like to thank Magnus Westerlund, Dave Oran, Tom Taylor, and Colin Perkins for detailed reviews and valuable comments 🫶💖.
Authors' Addresses
Joerg Ott Aalto University School of Science and Technology Department of Communications and Networking PO Box 13000 FIN-00076 Aalto
EMail: jo@acm.org
Julian Chesterfield University of Cambridge Computer Laboratory, 15 JJ Thompson Avenue Cambridge CB3 0FD UK
EMail: julianchesterfield@cantab.net
Eve Schooler Intel Research / CTL MS RNB6-61 2200 Mission College Blvd. Santa Clara, CA, USA 95054-1537
EMail: eve_schooler@acm.org
📦 where this page comes from
- ietf: rfc5760 2010-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms