RFC 8108

Sending Multiple RTP Streams in a Single RTP Session

📅 published March 2017, from ietf

RFC 8108: Sending Multiple RTP Streams in a Single RTP Session 💖

okay bestie, let's get into it 🦋 first, the title block, because it's the vibe check for the whole doc:

  • Number: RFC 8108 🎀
  • Title: Sending Multiple RTP Streams in a Single RTP Session
  • Stream: Internet Engineering Task Force (IETF)
  • Category: Standards Track
  • Date: March 2017
  • ISSN: 2070-1721
  • Authors: J. Lennox (Vidyo), M. Westerlund (Ericsson), Q. Wu (Huawei), and C. Perkins (University of Glasgow) 👑
  • Updates: RFC 3550 and RFC 4585 ✨

Abstract 💖

so the abstract is basically the TL;DR 🫶 this memo expands and clarifies how Real-time Transport Protocol (RTP) endpoints behave when they use multiple synchronization sources (SSRCs). that happens, for example, when one endpoint sends several RTP streams in a single RTP session. it updates RFC 3550 for handling multiple SSRCs per endpoint in RTP sessions, with a big focus on RTP Control Protocol (RTCP) behavior. it also updates RFC 4585 to change and clarify how SSRC timeouts are calculated and when feedback messages get included. iconic, honestly 🔥

Status of This Memo 📜

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

for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc8108 💅

Copyright (c) 2017 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 in effect on the date it was published. please actually read those, bestie, because they explain your rights and restrictions for this document 🙈 also, any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License. no cap, read the fine print 😭

Table of Contents 🗺️

1. Introduction ....................................................4
2. Terminology .....................................................4
3. Use Cases for Multi-Stream Endpoints ............................4
   3.1. Endpoints with Multiple Capture Devices ....................4
   3.2. Multiple Media Types in a Single RTP Session ...............5
   3.3. Multiple Stream Mixers .....................................5
   3.4. Multiple SSRCs for a Single Media Source ...................5
4. Use of RTP by Endpoints That Send Multiple Media Streams ........6
5. Use of RTCP by Endpoints That Send Multiple Media Streams .......6
   5.1. RTCP Reporting Requirement .................................7
   5.2. Initial Reporting Interval .................................7
   5.3. Aggregation of Reports into Compound RTCP Packets ..........8
        5.3.1. Maintaining AVG_RTCP_SIZE ...........................9
        5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs ....10
   5.4. Use of RTP/AVPF or RTP/SAVPF Feedback .....................13
        5.4.1. Choice of SSRC for Feedback Packets ................13
        5.4.2. Scheduling an RTCP Feedback Packet .................14
6. Adding and Removing SSRCs ......................................15
   6.1. Adding RTP Streams ........................................16
   6.2. Removing RTP Streams ......................................16
7. RTCP Considerations for Streams with Disparate Rates ...........17
   7.1. Timing Out SSRCs ..........................................19
        7.1.1. Problems with the RTP/AVPF T_rr_interval
               Parameter ..........................................19
        7.1.2. Avoiding Premature Timeout .........................20
        7.1.3. Interoperability between RTP/AVP and RTP/AVPF ......21
        7.1.4. Updated SSRC Timeout Rules .........................22
   7.2. Tuning RTCP Transmissions .................................22
        7.2.1. RTP/AVP and RTP/SAVP ...............................22
        7.2.2. RTP/AVPF and RTP/SAVPF .............................24
8. Security Considerations ........................................25
9. References .....................................................26
   9.1. Normative References ......................................26
   9.2. Informative References ....................................26
Acknowledgments ...................................................29
Authors' Addresses ................................................29

1. Introduction 🌈

back in the day, when the Real-Time Transport Protocol (RTP) [RFC3550] was first designed, and for a long time after, endpoints in RTP sessions usually only sent one media source 🧚 so they used one RTP stream and one synchronization source (SSRC) per RTP session, and separate RTP sessions were typically used for each media type. these days, though, a bunch of scenarios have popped up where endpoints want to send multiple RTP streams, each one told apart by its own SSRC identifier, all in one RTP session. we'll go through them in Section 3. the original RTP design did think about this stuff, ngl, but the spec wasn't written with these use cases consistently in mind, so it's a little unclear in places 🙈

this memo updates [RFC3550] to clear up behavior for use cases where endpoints use multiple SSRCs. it also updates [RFC4585] to fix problems with timing out inactive SSRCs and to clarify behavior around including feedback messages 💅

2. Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. these are the official requirement words, so they're the ones with real weight here ✨

3. Use Cases for Multi-Stream Endpoints 🎬

this section talks through a few use cases that pushed people to build endpoints sending RTP data with multiple SSRCs in a single RTP session 💜

3.1. Endpoints with Multiple Capture Devices 📸

the most straightforward reason for an endpoint to send multiple simultaneous RTP streams in one RTP session is when it has several capture devices and can therefore produce multiple media sources of the same media type and characteristics. for example, telepresence systems of the type described by the CLUE Telepresence Framework [CLUE-FRAME] often have multiple cameras or microphones covering different parts of a room, so they send several RTP streams of each type within a single RTP session 🎥🎤

3.2. Multiple Media Types in a Single RTP Session 🎶

recent work has updated RTP [MULTI-RTP] and Session Description Protocol (SDP) [SDP-BUNDLE] to drop the old assumption in RTP that media sources of different media types always go on different RTP sessions. in this setup, one endpoint's audio and video RTP streams (for example) are sent in a single RTP session instead, which cuts down on the number of transport-layer flows used 🦋

3.3. Multiple Stream Mixers 🎛️

there are a few RTP topologies where a central device generates multiple RTP streams in a session by itself. one example is a mixer that provides centralized compositing for a multi-capture scenario like the one in Section 3.1. here, the central node acts a lot like a multi-capture endpoint, generating several similar, related sources 🌸

a more complex example is the selective forwarding middlebox, described in Section 3.7 of [RFC7667] 🧠 this is a middlebox that receives RTP streams from several endpoints and then selectively forwards modified versions of some of them toward the other endpoints it's connected to. for each connected endpoint, a separate media source shows up in the session for every other source connected to the middlebox, "projected" from the original streams. but at any given time, lots of them can look inactive (so they're receivers, not senders, in RTP). this kind of device is closer to an RTP mixer than an RTP translator: it terminates RTCP reporting about the mixed streams, it can rewrite SSRCs, timestamps, and sequence numbers, as well as the contents of the RTP payloads, and it can turn sources on and off at will without appearing to generate packet loss 🫠 each projected stream will typically keep its original RTCP source description (SDES) information ✨

3.4. Multiple SSRCs for a Single Media Source 🔁

there are also several cases where one media source can send its data using multiple SSRCs within a single RTP session. these include, but aren't limited to, transport robustness tools like the RTP retransmission payload format [RFC4588], which needs one SSRC for the media data and another SSRC for the repair data 🛟 similarly, some layered media encoding schemes, like H.264 Scalable Video Coding (SVC) [RFC6190], can be set up so that each layer is sent using a different SSRC within a single RTP session 🍓

4. Use of RTP by Endpoints That Send Multiple Media Streams 🌟

RTP is inherently a group communication protocol 🫶 each endpoint in an RTP session will use one or more SSRCs, and so will some types of RTP-level middlebox. so, unless restrictions on the number of SSRCs have been signaled, RTP endpoints can expect to receive RTP data packets sent using a number of different SSRCs within a single RTP session. this can happen whether the RTP session runs over a point-to-point connection or a multicast group, because middleboxes can connect multiple transport connections together into a single RTP session. (the RTP session is defined by the shared SSRC space, not by the transport connections, bestie 🧠) and if RTP mixers are in the mix, some SSRCs might only show up in the contributing source (CSRC) list of an RTP packet and in RTCP, and might not appear directly as the SSRC of an RTP data packet 🙃

every RTP endpoint gets an allocated share of the available session bandwidth, as decided by signaling and congestion control 💸 the endpoint needs to keep its total media sending rate inside that share. BUT, endpoints that send multiple RTP streams don't necessarily have to split their share independently or evenly across each RTP stream and its SSRCs. an endpoint can vary the bandwidth allocated to different streams based on what they need, and it can dynamically change the bandwidth given to different SSRCs (for example, by using a variable-rate codec), as long as the total sending rate doesn't go over its allocated share. this includes turning RTP streams, or their redundancy streams, on or off as more or less bandwidth becomes available 🎀

5. Use of RTCP by Endpoints That Send Multiple Media Streams 🎀

Okay so RTCP is defined in Section 6 of [RFC3550] 💅 The whole protocol is written around "participants" in an RTP session, and it quietly assumes every endpoint is one participant with a single SSRC. But when an endpoint has multiple SSRC values, things only work right if implementations MUST treat each SSRC as a separate participant in the RTP session. So an endpoint with multiple SSRCs counts as multiple participants 🧚✨

5.1. RTCP Reporting Requirement

An RTP endpoint that has multiple SSRCs MUST treat each SSRC as a separate participant in the RTP session 💖 Each SSRC keeps its own RTCP-related state information, so each one gets its own RTCP reporting interval that decides when it sends RTCP reports. If the mechanism in [MULTI-STREAM-OPT] is not used, then each SSRC sends RTCP reports for all the other SSRCs, including the ones sitting at the same endpoint 👀

Here's the tea: if the endpoint has some SSRCs that are sending data and some that are only receivers, they get different shares of the RTCP bandwidth and calculate different base RTCP reporting intervals 🙈 Otherwise, all the SSRCs at an endpoint calculate the same base RTCP reporting interval. The actual reporting intervals for each SSRC are randomized in the usual way, but reports can be aggregated as described in Section 5.3 🦋

5.2. Initial Reporting Interval

When a participant joins a unicast session, this bit from Section 6.2 of [RFC3550] is relevant: "For unicast sessions... the delay before sending the initial compound RTCP packet MAY be zero." 🌸 The basic assumption is that this should also apply when there are multiple SSRCs. Caution is needed though 😭 If an endpoint (or middlebox) with a LOT of SSRCs joins a unicast session, sending a ton of RTCP reports immediately can cause a big burst of traffic. That can lead to transient congestion and packet loss from queue overflows, which is not the vibe.

So to keep the initial burst from an RTP endpoint no bigger than what a TCP connection would produce, an RTP endpoint MUST NOT send more than four compound RTCP packets with zero initial delay when it joins an RTP session. That's true no matter how many SSRCs the endpoint uses 🔥 Each of those initial compound RTCP packets MAY include aggregated reports from multiple SSRCs, as long as the total compound RTCP packet size doesn't go over the MTU, and the avg_rtcp_size is maintained as in Section 5.3.1 🎀 Aggregating reports from several SSRCs in those initial packets lets a substantial number of SSRCs report right away ✨ Endpoints SHOULD prioritize reports on SSRCs that are likely to be most immediately useful, e.g., SSRCs that are initially senders 💅

An endpoint that needs to report on more SSRCs than fit into the four compound RTCP reports that can go out immediately MUST send the other reports later. It follows the usual RTCP timing rules, including timer reconsideration ⏰ Those reports MAY be aggregated as described in Section 5.3 🫶

Note: The above is chosen to match the TCP maximum initial window of four packets [RFC3390], not the larger TCP initial windows for which there is an ongoing experiment [RFC6928]. The reason for this is a desire to be conservative, since an RTP endpoint will also in many cases start sending RTP data packets at the same time as these initial RTCP packets are sent. 🧁

5.3. Aggregation of Reports into Compound RTCP Packets

As outlined in Section 5.1, an endpoint with multiple SSRCs has to treat each SSRC as a separate participant when it comes to sending RTCP reports 🌈 That means each SSRC sends a compound RTCP packet in every reporting interval. Since these packets come from the same endpoint, you might reasonably expect they can be aggregated to cut down on overhead, and you'd be right 🧠 Section 6.1 of [RFC3550] already lets RTP translators and mixers aggregate packets in similar circumstances:

It is RECOMMENDED that translators and mixers combine individual RTCP packets from the multiple sources they are forwarding into one compound packet whenever feasible in order to amortize the packet overhead (see Section 7). An example RTCP compound packet as might be produced by a mixer is shown in Fig. 1. If the overall length of a compound packet would exceed the MTU of the network path, it SHOULD be segmented into multiple shorter compound packets to be transmitted in separate packets of the underlying protocol. This does not impair the RTCP bandwidth estimation because each compound packet represents at least one distinct participant. Note that each of the compound packets MUST begin with an SR or RR packet.

This lets RTP translators and mixers build compound RTCP packets holding multiple Sender Report (SR) or Receiver Report (RR) packets from different SSRCs, plus any of the other packet types 🦋 The order of RTCP packets inside the compound packet is totally free, with one exception: the regular rule that the compound RTCP packet starts with an SR or RR packet. Because of that rule, correctly implemented RTP endpoints can handle compound RTCP packets that contain RTCP packets for multiple SSRCs 💜

So endpoints using multiple SSRCs can aggregate the RTCP packets from their different SSRCs into compound RTCP packets, as long as:

  1. the resulting compound RTCP packets begin with an SR or RR packet,
  2. they maintain the average RTCP packet size as described in Section 5.3.1, and
  3. they schedule packet transmission and manage aggregation as described in Section 5.3.2.

5.3.1. Maintaining AVG_RTCP_SIZE

The RTCP scheduling algorithm in [RFC3550] works on a per-SSRC basis 🍓 Each SSRC sends a single compound RTCP packet in each RTCP reporting interval. When an endpoint uses multiple SSRCs, it's desirable to aggregate the compound RTCP packets its SSRCs send, which cuts overhead by forming a bigger compound RTCP packet ✨ That aggregation can be done as described in Section 5.3.2, provided the average RTCP packet size calculation is updated as follows.

Participants in an RTP session update their estimate of the average RTCP packet size (avg_rtcp_size) each time they send or receive an RTCP packet (see Section 6.3.3 of [RFC3550]) 🌸 When a compound RTCP packet containing RTCP packets from several SSRCs is sent or received, the avg_rtcp_size estimate for each SSRC that gets reported upon is updated using div_packet_size instead of the actual packet size:

avg_rtcp_size = (1/16) * div_packet_size + (15/16) * avg_rtcp_size

where div_packet_size is packet_size divided by the number of SSRCs reporting in that compound packet. The number of SSRCs reporting in a compound packet is found by counting the number of different SSRCs that are the source of SR or RR RTCP packets within the compound RTCP packet. Non-compound RTCP packets (i.e., RTCP packets that do not contain an SR or RR packet [RFC5506]) are considered to report on a single SSRC 🧚

A participant that doesn't follow the above rule, and instead uses the full RTCP compound packet size to calculate avg_rtcp_size, will derive an RTCP reporting interval that's overly large 😬 It's too large by a factor proportional to the number of SSRCs aggregated into compound RTCP packets, and to the size of the set of SSRCs being aggregated relative to the total number of participants. That increased interval can cause premature timeouts if it's more than five times the interval chosen by the SSRCs that understand compound RTCP and aggregate reports from many SSRCs. A 1500-octet MTU can fit five typical-size reports into a compound RTCP packet, so this is a real concern if endpoints aggregate RTCP reports from multiple SSRCs 💀

The issue in the previous paragraph is mitigated by the modification in timeout behavior specified in Section 7.1.2 of this memo 🫶 That mitigation applies when the RTCP bandwidth is high enough that an endpoint, using avg_rtcp_size calculated without counting the number of reporting SSRCs, can transmit more often than roughly every 5 seconds. Note, however, that the non-updated endpoint's RTCP reporting is still negatively affected even if the premature timeouts of its SSRCs are avoided 🥺 If compatibility with non-updated endpoints is a concern, the number of reports from different SSRCs aggregated into a single compound RTCP packet SHOULD either be limited to two reports, or aggregation ought not be used at all. That keeps the non-updated endpoint's RTCP reporting interval no larger than twice the RTCP reporting interval that an endpoint following this specification would choose 👑

5.3.2. Scheduling RTCP when Aggregating Multiple SSRCs ✨

okay so this section is literally where the RTCP scheduling glow-up happens 💅 it revises and extends what [RFC3550] says in Section 6.3, and what [RFC4585] says in Section 3.5.3 if you're using the RTP/AVPF or RTP/SAVPF profile. the whole point is figuring out what to do when a bunch of reporting SSRCs want to stuff their RTCP packets into the same compound packet 📦 these changes are needed so the important timing stuff still works, like the inter-packet distribution and how things behave during flash joins and other membership changes 🦋 no cap, the timing is everything bestie 🫶

the variables tn, tp, tc, T, and Td are defined in Section 6.3 of [RFC3550], so go check there if you forget what they mean 🌸 T_rr_interval and T_rr_last come from [RFC4585] 💜

okay now the big rule: every endpoint MUST schedule RTCP transmission independently for each of its SSRCs, using the regular tn calculation for whatever RTP profile is being used 🎀 every time the tn timer expires for an SSRC, the endpoint MUST do RTCP timer reconsideration and, if it applies, suppression based on T_rr_interval 🔥 if that says a compound RTCP packet should go out from that SSRC, and it's not an early RTCP packet [RFC4585], then the endpoint SHOULD try to aggregate RTCP packets from other SSRCs that are scheduled in the future into that compound packet before it's sent 🧚 the reason it might limit or skip aggregating for backwards compatibility is covered in Section 5.3.1 💅

here's how the aggregation goes down 🍓 the endpoint picks the SSRC with the smallest tn value after the current time, tc, and prepares the RTCP packets that SSRC would send if its tn timer expired right at tc ✨ if those packets fit in the compound packet being built, taking the path MTU and the packets already added into account, they get added 💖 if they don't fit, they get discarded 🙈 this repeats for each SSRC in order of increasing tn until the compound packet is full or everyone's been aggregated, and then it gets sent 🚀

when the compound packet goes out, the endpoint MUST update tp, tn, and T_rr_last (if applicable) for every SSRC that got included 👑 here's the update breakdown:

a. for the first SSRC that reported in the compound packet, set its effective transmission time, tt, to tc 💜

b. for each additional SSRC that reported in the compound packet, work out the transmission time that SSRC would've had if it hadn't been aggregated 🫠 you do that by taking tn for that SSRC, then reconsidering and updating tn until tp + T <= tn 🌈 once that's done, set that SSRC's tt to the calculated tn 🎀 and if you're using the RTP/AVPF or RTP/SAVPF profile, suppression based on T_rr_interval MUST NOT be used in this calculation 🙅‍♀️

c. work out the average effective transmission time, tt_avg, for the compound packet using the tt values of all the SSRCs sent in it ✨ then set tp for each of those SSRCs to tt_avg 💖 and if you're on RTP/AVPF or RTP/SAVPF, set T_tt_last for each SSRC sent to tt_avg too 🦋

d. for each SSRC sent in the compound packet, recalculate tn using the updated parameters and the usual RTCP timing rules, and reschedule the timers 🔥

when you're on RTP/AVPF or RTP/SAVPF, the mechanism above only tries to aggregate when the compound packet isn't an early RTCP packet, so the algorithm in Section 3.5.3 of [RFC4585] is the one running the RTCP scheduling 🎀 if T_rr_interval == 0, or if T_rr_interval != 0 and option 1, 2a, or 2b of that algorithm got picked, the mechanism updates the variables it needs 🌸 but if the transmission gets suppressed under option 2c, then tp is updated to tc, because aggregation didn't actually happen 🙈

reverse reconsideration MUST be done following Section 6.3.4 of [RFC3550] 🧚 sometimes that makes tp (after reverse reconsideration) bigger than tc, and that's totally fine, not a problem at all 💅 it has the desired effect of pulling tp toward tc (and tn too) proportionally as the reporting interval shrinks in direct proportion to the smaller group size 🦋

the algorithm above has been shown in simulations [Sim88] [Sim92] to keep the inter-RTCP packet transmission time distribution for each SSRC AND to use the same amount of bandwidth as non-aggregated RTCP packets 😭🔥 the actual transmission interval for an SSRC that triggers a compound RTCP transmission still follows the regular rules 🌈 tp gets set somewhere in the interval [0, 1.5/1.21828*Td] ahead of tc 💖 the actual value is the average of one instance of tc and the randomized transmission times of the additional SSRCs, so the lower end of the interval is more likely 🥺 this makes up for the bias you'd otherwise get from picking the shortest tn out of the N SSRCs in the aggregate 💜

the algorithm also handles cases where the number of SSRCs that fit in an aggregated packet changes 🎀 an SSRC that was aggregated before but doesn't fit this time still has its own transmission scheduled by the normal rules 🍓 so it'll trigger a transmission in due time, or get included in another aggregate ✨ here's what happens to the algorithm when group size changes:

RTP sessions where the number of SSRCs is growing: when the group grows, Td grows in proportion to the number of new SSRCs in the group 🌸 when reconsideration runs because the tn timer expired, that SSRC reconsiders and, with a certain probability, reschedules its tn timer 💅 this part of reconsideration is only affected by the above algorithm having tp values that were in the future, instead of set to the time of the actual last transmission when tp got updated 🫶

RTP sessions where the number of SSRCs is shrinking: when the group shrinks, reverse reconsideration moves tp and tn toward tc, proportionally to how many SSRCs left the session compared to the total number of participants when they left 🦋 setting tp forward in time relative to tc might look like it has a negative effect 🙈 but it's there to make up for the bias from picking the shortest tn out of the N aggregated 💖 that bias sticks around even after the number of SSRCs goes down 💅 reverse reconsideration fixes it whether or not aggregation is being used ✨ the negative effect that can happen when an SSRC leaves is that the most favorable tn belonged to the SSRC that got removed 😬 the damage is limited to delaying transmission by, at worst, one reporting interval 🫠

so in conclusion 👑 the investigations found no significant negative impact on the scheduling algorithm 🎉 iconic behavior tbh 💖

5.4. Use of RTP/AVPF or RTP/SAVPF Feedback 🦋

okay so this section is about sending RTP/AVPF feedback packets when the sending endpoint has multiple SSRCs 💜 the guidelines here also apply to endpoints using the RTP/SAVPF profile ✨

5.4.1. Choice of SSRC for Feedback Packets 🎀

when an RTP/AVPF endpoint has multiple SSRCs, it gets to choose which SSRC to use as the source for the RTCP feedback packets it sends 💅 a few factors can affect that choice:

  • RTCP feedback packets about a particular media type SHOULD be sent by an SSRC that receives that media type 🌸 for example, when audio and video are multiplexed onto a single RTP session, endpoints will use their audio SSRC to send feedback on the audio they got from other participants 🎤
  • RTCP feedback packets and RTCP codec control messages that are notifications or indications about RTP data an endpoint processed MUST be sent from the SSRC used for that RTP data 🔥 this includes notifications that relate to a previously received request or command [RFC4585][RFC5104] 💖
  • if separate SSRCs are used to send and receive media, then the corresponding SSRC SHOULD be used for feedback, since they have differing RTCP bandwidth fractions 🦋 this can also affect whether or not the SSRC can be used in immediate mode ✨
  • some RTCP feedback packet types need consistency in the SSRC used 🙈 for example, if a Temporary Maximum Media Stream Bit Rate Request (TMMBR) limitation [RFC5104] is set by an SSRC, the same SSRC needs to be used to remove the limitation 🫶
  • if several SSRCs are suitable for sending feedback, it might be desirable to use one that lets the feedback go out as an early RTCP packet 🧚

when an RTCP feedback packet is sent as part of a compound RTCP packet that aggregates reports from multiple SSRCs, there's no requirement that the compound packet contain an SR or RR packet generated by the sender of the RTCP feedback packet 🌈 for reduced-size RTCP packets, aggregation of RTCP feedback packets from multiple sources is not limited any further than Section 4.2.2 of [RFC5506] 💅🎀

5.4.2. Scheduling an RTCP Feedback Packet ✨

okay bestie, so when an SSRC needs to send a feedback packet in early mode, it MUST schedule that packet using the algorithm in Section 3.5 of [RFC4585], with a few tweaks 💅

  • Figuring out the session vibe 🧮: an endpoint MUST count the distinct RTCP SDES CNAME values used by the SSRCs listed in the SSRC field of the RTP data packets it receives, and in the SSRC of sender field of the RTCP SR, RR, RTPFB, or PSFB packets it receives. An RTP session counts as a multiparty session if more than one CNAME is used by those SSRCs, unless signaling says the session is to be handled as point to point, or RTCP reporting groups [MULTI-STREAM-OPT] are being used. If reporting groups are used, the session counts as point-to-point if the endpoint receives only a single reporting group. It counts as multiparty if multiple reporting groups are received, or if a mix of reporting groups and SSRCs that are not part of a reporting group is received. Endpoints MUST NOT decide whether a session is multiparty or point to point based on the type of connection (unicast or multicast) used, or on the number of SSRCs received. 🙅‍♀️
  • Checking for an already-scheduled packet 👀: when checking whether there is already a scheduled compound RTCP packet containing feedback messages (Step 2 in Section 3.5.2 of [RFC4585]), that check MUST be done considering all local SSRCs.
  • Early-mode permission slip 🎫: if an SSRC is not allowed to send an early RTCP packet, the feedback message MAY be queued for transmission as part of any early or regular scheduled transmission that can happen within the maximum useful lifetime of the feedback message (T_max_fb_delay). This modifies the behavior in item 4a in Section 3.5.2 of [RFC4585].

The first bullet point above sets a rule for deciding whether an RTP session is point-to-point or multiparty. It's straightforward to implement, but it's known to sometimes misclassify sessions as multiparty. The known problems are:

  • Endpoint with multiple synchronization contexts: an endpoint that is part of a point-to-point session can have multiple synchronization contexts, for example because it forwards an external media source into an interactive real-time conversation. In this case the classification treats the peer as two endpoints, even though one endpoint is actually in control of the RTP/RTCP transmission.
  • Selective Forwarding Middlebox: the Selective Forwarding Middlebox (SFM) defined in Section 3.7 of [RFC7667] controls the transmission and configuration between itself and each peer endpoint individually. It also fully controls the RTCP packets forwarded between the individual legs. So this kind of middlebox is comparable to an RTP mixer, which uses its own SSRCs to mix or select the media it forwards, and it will be classified as a point-to-point RTP session by the rule above. 🫣

In the cases above, using RTCP reporting groups [MULTI-STREAM-OPT] is very reasonable. If that extension is used, an endpoint can indicate that the multitude of CNAMEs are actually under the control of a single endpoint or middlebox, by using only a single reporting group. 🧁

The rules above will also classify some sessions as point to point when the endpoint is connected to an RTP mixer. For example, the mixer could act as a gateway to an RTP session based on Any Source Multicast for the endpoint in question. In most cases this is fine, though, because the RTP mixer separates the two parts of the session. It's then up to the mixer to act accordingly in each domain. 🌸

Finally, signaling mechanisms could be defined to override the rules in cases where they would produce the wrong classification. 🔑

6. Adding and Removing SSRCs 🦋

The set of SSRCs in a single RTP session can change over time, because the number of endpoints in the session changes, or because the number or type of RTP streams being sent changes. 🔄

Every endpoint in an RTP session has at least one SSRC that it uses for RTCP reporting, and for sending media if it wants to. It can also have extra SSRCs, for sending extra media sources or for additional RTCP reporting. If the set of media sources being sent changes, the set of SSRCs being sent changes too. Changes in the media format or clock rate might also require changes to the set of SSRCs in use. An endpoint can also have more SSRCs than it has active RTP streams. It can send RTCP about SSRCs that aren't currently sending RTP data packets, so its peers know those SSRCs exist and already have the associated context in place (such as clock synchronization and an SDES CNAME). That way they can play out media as soon as the SSRCs become active. 🎬

Below, we go through some things to think about when adding and removing RTP streams and their SSRCs.

6.1. Adding RTP Streams 🌱

When an endpoint joins an RTP session, it can have zero, one, or more RTP streams it will send, or that it is ready to send. If it has no RTP stream it plans to send, it still needs an SSRC for sending RTCP feedback. If it will send one or more RTP streams, it needs the matching number of SSRC values. Other endpoints in the RTP session learn about the SSRCs an endpoint uses when it sends RTP and RTCP packets. SSRCs can also be signaled by non-RTP means (for example, [RFC5576]). Unless signaling restricts it, an endpoint can, at any time, send an additional RTP stream identified by a new SSRC. This might be tied to a signaling event, but that's outside the scope of this memo. Either way, the new SSRC becomes visible to the other endpoints in the session, because they all share the single SSRC space that comes with the definition of an RTP session. 👀

An endpoint that has never sent an RTP stream still has an SSRC that it uses for RTCP reporting. If that endpoint wants to start sending an RTP stream, it is RECOMMENDED that it use its existing SSRC for that stream. Otherwise the participant count in the RTP session goes up for no good reason, which leads to a longer RTCP reporting interval and larger RTCP reports due to cross reporting. 📈 If the endpoint wants to send more than one RTP stream, it needs to generate a new SSRC for the second and any subsequent RTP streams.

An endpoint that has previously stopped sending an RTP stream, and now wants to start a new one, generally can't reuse the existing SSRC. It often needs to generate a new one, because an SSRC cannot change media type (for example, audio to video) or RTP timestamp clock rate [RFC7160], and because the application might attach a particular meaning to the SSRC. 🙃 (Note: an RTP stream can pause and restart using the same SSRC, as long as RTCP is sent for that SSRC during the pause. These rules only apply to new RTP streams that reuse an existing SSRC.)

6.2. Removing RTP Streams 🗑️

An SSRC leaves an RTP session in one of two ways. When an endpoint stops sending RTP and RTCP packets using an SSRC, that SSRC eventually times out, as described in Section 6.3.5 of [RFC3550]. Or an SSRC can be explicitly removed from use by sending an RTCP BYE packet, as described in Section 6.3.7 of [RFC3550]. It is RECOMMENDED that SSRCs be removed from use by sending an RTCP BYE packet. Note that [RFC3550] says the RTCP BYE SHOULD be the last RTP/RTCP packet sent in the RTP session for an SSRC. If an endpoint needs to restart an RTP stream after sending an RTCP BYE for its SSRC, it needs to generate a new SSRC value for that stream. 🔁

Sending an RTCP BYE is final, so endpoints need to figure out whether stopping an RTP stream is temporary or permanent. Temporarily pausing media on a particular RTP stream (SSRC) means keeping that SSRC as an active participant by continuing RTCP transmission for it. That way the media can resume right away, knowing the context is still in place. ⏸️ When transmission is permanently halting, a participant needs to send an RTCP BYE. That lets the other participants reclaim the RTCP bandwidth and clean up their state databases. 🧹

⚠️ An endpoint that stops transmitting all of its RTP streams but stays in the RTP session MUST maintain at least one SSRC for RTCP reporting and feedback. It can't send a BYE for every SSRC; it needs to keep at least one SSRC active. Because some feedback packets can be bound to a media type, there might be a need to maintain one SSRC per media type within the RTP session. An alternative is to create a new SSRC for RTCP reporting and feedback. However, to avoid the perception that an endpoint has dropped completely out of the RTP session, such a new SSRC ought to be established first, before terminating all the existing SSRCs. 🫶

7. RTCP Considerations for Streams with Disparate Rates 🎀

okay bestie, so every RTP session gets just one set of bandwidth settings 💅 That means the RTCP sender and receiver fractions (like the SDP b=RR: and b=RS: lines from [RFC3556]) and the RTP/AVPF profile settings from [RFC4585] (think trr-int) if you're using that profile, or its secure cousin RTP/SAVPF [RFC5124]. The result? The base RTCP reporting interval, before randomization, is the same for every sending SSRC in the session. Receiving SSRCs get the same base interval too, though it can be different from what the sending SSRCs pick. This one-size-fits-all interval can make RTCP reports go out way too often, or way too rarely, for what a particular stream actually needs 🙈

Let's look at an example. Picture an audio flow sending at tens of kilobits per second, multiplexed into a session with a multi-megabit, high-quality video flow. If the session bandwidth is set based on the video rate, and you use the default RTCP bandwidth fraction of 5% of session bandwidth, the RTCP bandwidth will likely be bigger than the audio sending rate 😭 Now add the reduced minimum RTCP interval from Section 6.2 of [RFC3550]. That's great for video, where you want fast feedback on damaged I-frames. But with one uniform reporting interval for everyone, the audio sources could end up sending RTCP packets more often than their actual audio data packets. You can shrink this mismatch with careful tuning of the RTCP parameters, especially trr_int when RTP/AVPF is in use. It can't be avoided entirely though, because it's built into the RTCP timing rules themselves, and it hits every RTP session that mixes flows with wildly different bandwidths 💀

Different media rates or RTCP needs can also show up with SSRCs carrying the same media type. A super common case in multiparty calls is when a few video streams show up in high resolution while the rest are tiny low-res thumbnails, and voice activity decides who gets the big screen 🎬 Here the differences are in both the actual media rate and in which feedback messages might be needed. Another example is the purpose of the source itself. A camera pointed at the speaker is totally different from a document camera. The basic parameters that can differ here are frame-rate, acceptable end-to-end delay, and the Signal-to-Noise Ratio (SNR) fidelity of the image ✨ These differences affect more than just the bitrates needed. They also change what transmission behaviors are possible, which repair mechanisms are usable, what feedback messages the control and repair need, what transmission requirements apply to those feedback messages, and how the RTP stream delivery gets monitored. Other similar scenarios can exist too.

Sending multiple media types in one RTP session means that session has more SSRCs than if each media type had its own session. For instance, if two participants each send an audio and a video RTP stream in a single session, that session has four SSRCs. If separate RTP sessions were used for audio and video, each of those two sessions would only have two SSRCs 🦋 So when you cram multiple RTP streams into one session, the SSRCs cross-report on each other more, since each one reports on every other SSRC in the session. That makes the RTCP reports bigger, which means they go out less often than they would have if separate sessions were used for the same RTCP bandwidth.

One more thing: when a session has multiple media types, the RTCP reception quality reports, feedback messages, and extended report blocks you're using might not apply to every media type 🙈 Endpoints need to look at the media type of each SSRC, and only send or process the reports and feedback that actually apply to that SSRC and its media type. Signaling solutions might also struggle to indicate that a particular set of RTCP reports or feedback messages only applies to one media type within an RTP session.

So from an RTCP point of view, there are real advantages to using a separate RTP session for each media source, instead of stuffing multiple sources into one session. But those advantages are often outweighed by the need to reduce port use and to ease NAT/firewall traversal, which is exactly what combining media sources into one RTP session gets you 💖 The following sections dig deeper into some of the issues with using RTCP in sessions with multiple media sources.

7.1. Timing Out SSRCs 🧚

Various issues have been identified with timing out SSRC values when you're sending multiple RTP streams in one RTP session. Let's get into them!

7.1.1. Problems with the RTP/AVPF T_rr_interval Parameter 🌸

RTP/AVPF has a method to stop regular RTCP reports from going out too often. It's described in Section 3.5.3 of [RFC4585], and it's controlled by the T_rr_interval parameter. Here's how it works: every time a regular RTCP report is sent, a new random value, T_rr_current_interval, is generated, drawn evenly in the range 0.5 to 1.5 times T_rr_interval. If a regular RTCP packet is about to go out sooner than T_rr_current_interval seconds after the previous regular RTCP packet, and there are no feedback messages to send, then that regular RTCP packet gets suppressed and the next regular RTCP packet is scheduled instead. T_rr_current_interval gets recalculated every time a regular RTCP packet is sent. The benefit of suppression is that it avoids wasting bandwidth when nothing needs frequent RTCP transmissions, but it still lets you use the configured bandwidth when feedback is needed ✨

Here's the catch though. This suppression mechanism skews the distribution of RTCP sending intervals compared to the regular reporting intervals 🙃 The standard RTCP timing rules, including reconsideration and the compensation factor, make the gaps between RTCP packets skew toward the upper end of the range [0.5/1.21828, 1.5/1.21828]*Td, where Td is the deterministic calculated RTCP reporting interval. With Td = 5 s, that distribution covers [2.052 s, 6.156 s]. By comparison, the RTP/AVPF suppression rules act in a window that's 0.5 to 1.5 times T_rr_interval. For T_rr_interval = 5s, that's [2.5 s, 7.5 s].

This has a big effect: the time between consecutive RTCP packets when T_rr_interval suppression is in use can get really long 😭 The maximum gap between sending one regular RTCP packet and the next happens when T_rr_current_interval hits its maximum value, a regular RTCP packet gets suppressed at the end of the suppression period, and then the next regular RTCP packet is scheduled after its largest possible reporting interval. Taking the worst case of those two intervals gives a maximum time between two RTCP reports of 1.5*T_rr_interval + 1.5/1.21828*Td.

This can be really surprising when Td and T_rr_interval have the same value, meaning T_rr_interval is configured to match the regular RTCP reporting interval. You'd expect regular RTCP packets to follow their usual schedule while feedback packets can go out early. But because of the issue above, RTCP packets actually land in the range [0.5*Td, 2.731*Td] with a super non-uniform distribution, rather than the range [0.41*Td, 1.23*Td] you'd expect 👑 It's perhaps unexpected, but it isn't a problem in itself. The trouble starts when it's combined with packet loss, because then it raises the issue of premature timeout 😬

7.1.2. Avoiding Premature Timeout 💅

In RTP/AVP [RFC3550], the timeout behavior is simple: it's 5 times Td, where Td is calculated with a Tmin value of 5 seconds. Put differently, if the configured RTCP bandwidth allows an average RTCP reporting interval shorter than 5 seconds, the timeout is 25 seconds of no activity from the SSRC (RTP or RTCP). Otherwise, the timeout is 5 average reporting intervals.

RTP/AVPF [RFC4585] brings in different timeout behaviors depending on the value of T_rr_interval. When T_rr_interval is 0, it uses the same timeout calculation as RTP/AVP. But when T_rr_interval is non-zero, it replaces Tmin in the timeout calculation, most likely to speed up detection of timed-out SSRCs. Using a non-zero T_rr_interval does come with two consequences for RTP behavior, though 👀

First, because of suppression, the number of RTP and RTCP packets sent by an SSRC that isn't an active RTP sender can get super low, thanks to the issue discussed in Section 7.1.1. The RTCP packet interval can stretch as long as 2.73*Td, so during a 5*Td time period, an endpoint might actually only transmit a single RTCP packet 💀 Those long intervals mean fewer RTCP packets overall, to the point where losing just one RTCP packet can sometimes time out an SSRC.

Second, the RTP/AVPF changes to the timeout rules reduce robustness to misconfiguration. It's really common to use RTP/AVPF configured so RTCP packets go out frequently for rapid feedback, but that makes timeouts very sensitive to T_rr_interval 🫠 For example, say two SSRCs are configured, one with T_rr_interval = 0.1 s and the other with T_rr_interval = 0.6 s. That small difference means the SSRC with the shorter T_rr_interval will time out the other one if it stops sending RTP packets, because the other RTCP reporting interval is more than five times its own. When RTP/AVP is used, or RTP/AVPF with T_rr_interval = 0, this is a non-issue. The timeout period is 25 s, and differences in configured RTCP bandwidth can only cause premature timeouts when reporting intervals are greater than 5 s and differ by a factor of five. To limit the scope for this kind of problematic misconfiguration, we define an update to the RTP/AVPF timeout rules in Section 7.1.4 🎀

7.1.3. Interoperability between RTP/AVP and RTP/AVPF 💅

okay bestie, picture this 🎀 if RTP/AVP and RTP/AVPF endpoints (or their secure variants) are hanging out in the same RTP session, and the RTP/AVPF ones use a non-zero T_rr_interval that's significantly below 5 seconds, the RTP/AVPF crew could prematurely time out the SSRCs of the RTP/AVP endpoints 😭. why? their RTCP timeout rules are different. flip it: if the RTP/AVPF endpoints use a T_rr_interval significantly larger than 5 seconds, now the RTP/AVP endpoints might time out the RTP/AVPF SSRCs 💀. total chaos, ngl.

Mixing endpoints on two different RTP profiles inside one RTP session is NOT RECOMMENDED 🙅‍♀️. BUT if you're going to mix them anyway, and the RTP/AVPF endpoints haven't been updated to follow Section 7.1.4 of this memo, then the RTP/AVPF session SHOULD be configured with T_rr_interval = 4 seconds to avoid premature timeouts 🧚.

Now the 4 seconds thing might look sus at first 🙈. Intuitively you'd think it should be 5 seconds so both profiles use the same timeout period. But the behavior in Section 7.1.1 shows that real RTP/AVPF reporting intervals can run longer than expected 👀. So setting T_rr_interval = 4 seconds gives actual RTCP intervals close to what RTP/AVP expects, and that's what keeps everyone interoperable 🫶✨.

7.1.4. Updated SSRC Timeout Rules 🌸

okay so, to keep things interoperable and avoid premature timeouts, every SSRC in an RTP session MUST use the same timeout behavior 🔥. the problem? older specs are inconsistent about this 😤. so to fix the interoperability mess, this memo updates the timeout rules like so:

  • For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, the timeout interval SHALL be calculated using a multiplier of five times the deterministic RTCP reporting interval. In other words, the timeout interval SHALL be 5*Td 💖.
  • For the RTP/AVP, RTP/SAVP, RTP/AVPF, and RTP/SAVPF profiles, calculating Td just for the participant timeout SHALL be done using a Tmin value of 5 seconds, and NOT the reduced minimal interval 🙅‍♀️. this is true even if the reduced minimum interval is what's used to calculate the RTCP packet transmission intervals 🍓.

This changes things for the RTP/AVPF or RTP/SAVPF profiles whenever T_rr_interval != 0 🦋. Specifically, the first paragraph of Section 3.5.4 of [RFC4585] gets updated so the timeout calculation for RTP/AVPF entities uses Tmin instead of T_rr_interval 💅.

7.2. Tuning RTCP Transmissions 🎀

this subsection is all about what tuning you can do to reduce the downsides of the shared RTCP packet intervals 🧁. first we'll look at the options for the RTP/AVP [RFC3551] profile, and then the extra tools RTP/AVPF [RFC4585] brings to the table ✨.

7.2.1. RTP/AVP and RTP/SAVP 🌈

when you're using RTP/AVP or RTP/SAVP, your tuning options for the RTCP reporting intervals are pretty limited 😮‍💨. you've got the RTCP sender and receiver bandwidth, and whether the minimum RTCP interval gets scaled according to the bandwidth. since the scheduling algorithm has both randomization AND reconsideration, you can't just calculate the expected average transmission interval with the formula for Td from Section 6.3.1 of [RFC3550] and call it a day 🙃. BUT if you look at the inputs to that expression, plus the randomization and reconsideration rules, you can start to understand how the RTCP transmission interval actually behaves 🔍.

Let's start with some basic observations:

  • a. Unless the scaled minimum RTCP interval is used, Td before randomization and reconsideration can never be less than Tmin. The default value of Tmin is 5 seconds 🖐️.
  • b. If the scaled minimum RTCP interval is used, Td can drop as low as 360 divided by RTP Session bandwidth in kilobits per second. In SDP, the RTP session bandwidth gets signaled with a b=AS line 📝. An RTP Session bandwidth of 72 kbps gives you a Tmin of 5 seconds. An RTP session bandwidth of 360 kbps gives a Tmin of 1 second, of course 🙌. And if you want a Tmin equal to once every frame for a 25 frame-per-second video stream, you need an RTP session bandwidth of 9 Mbps 🎬. using the RTP/AVPF or RTP/SAVPF profile lets you send more frequent RTCP reports for the same bandwidth, which we'll get into below 💜.
  • c. Td scales with the number of SSRCs and the average size of the RTCP reports, so the overall RTCP bandwidth stays constant 📊.
  • d. The actual transmission interval for a given Td value lands in the range [0.5*Td/1.21828, 1.5*Td/1.21828], and the distribution is skewed 😳. because of reconsideration, most of the probability mass sits above Td. for example, with Td = 5 s, the actual transmission interval is spread across [2.052 s, 6.156 s], and it tends toward the upper half 🫠. also, the Tmin parameter limits the value of Td before randomization and reconsideration get applied, so the actual transmission interval can stretch below Tmin too 🎢.

Okay, so with all that, we can work out the number of SSRCs, n, that an RTP session can support when 5% of the session bandwidth is assigned to RTCP, while still keeping Td equal to Tmin 🧮. this tells us how many RTP streams we can report on without the RTCP overhead getting out of hand 💅. we make two assumptions to keep the math simple: all SSRCs are senders, and they all send compound RTCP packets made of an SR packet with n-1 report blocks, followed by an SDES packet holding a 16 octet CNAME value [RFC7022]. these packets vary in size between 54 and 798 octets depending on n, up to the maximum of 31 report blocks that an SR packet can carry 📦. if we plug this packet size and a 5% RTCP bandwidth fraction into the RTCP interval calculation in Section 6.3.1 of [RFC3550], and solve for the n that gives Td = Tmin for the scaled minimum interval, we get n=9 SSRCs 🎉. (this holds regardless of the interval, because the reporting interval scales with the session bandwidth.) if you want to support more SSRCs without changing the scaled minimum interval, you'd need to raise the RTCP bandwidth fraction above 5%. changing the session bandwidth to a higher value would just lower Tmin instead 🤔. still, if you stick with the default 5% RTCP allocation, bumping up that fraction means more SSRCs can be supported for a fixed Td target 📈.

so based on all this, when you're using the RTP/AVP or RTP/SAVP profile, the big limitation for rapid RTCP reporting in small unicast sessions is going to be the Tmin value 😤. the RTP session bandwidth configured for RTCP has to be high enough to hit the reporting goals your application has, while still following the rules for the scaled minimal RTCP interval 💖.

7.2.2. RTP/AVPF and RTP/SAVPF 🦋

okay, when you use RTP/AVPF or RTP/SAVPF, you get a seriously powerful extra tool for tuning RTCP transmissions: the T_rr_interval parameter 👑. this parameter lets you have short RTCP reporting intervals, or alternatively, lets you send frequent RTCP feedback without sending frequent regular RTCP reports 🫶.

using RTP/AVPF or RTP/SAVPF with T_rr_interval set above zero but below Tmin allows more frequent RTCP feedback than RTP/AVP or RTP/SAVP for the same RTCP bandwidth 🚀. here's why: Tmin is set to zero after the initial RTCP report is sent, so the reporting interval for later packets gets determined by the usual bandwidth-based RTCP calculation, using Tmin=0 and T_rr_interval 🧠. now you're no longer held back by the minimal interval (whether that's the default 5-second minimum or the reduced minimum interval). instead, the RTCP bandwidth and T_rr_interval are the things running the show, and that means faster feedback ⚡. apps that care about rapid regular RTCP feedback should seriously consider RTP/AVPF or RTP/SAVPF, even if they don't use the feedback features of that profile 💅.

using RTP/AVPF or RTP/SAVPF means RTCP feedback packets can go out frequently without also needing regular RTCP reports to go out frequently 🥰. T_rr_interval limits how often regular RTCP packets can be sent, while still letting RTCP feedback packets be sent 🎀. say an app wants feedback packets for some RTP streams, like video, but doesn't want frequent regular reporting for other streams. it can set T_rr_interval to a value where regular reporting for both audio and video sits at a level that's acceptable for the audio 🎧. then it can use feedback packets for the video reporting, and those feedback packets will include RTCP SR/RR packets unless reduced size RTCP feedback packets [RFC5506] are used 📨. this way, the available RTCP bandwidth gets spent on the feedback that's most useful to the app 💜.

using T_rr_interval still means you have to pick suitable values for the RTCP bandwidth 🧮. honestly, it might make that choice even MORE important (oops, lowercase only for me 😅), since it's more likely to affect RTCP behavior and performance than it is with RTP/AVP or RTP/SAVP, because there are fewer limitations on RTCP transmission 🫠.

when T_rr_interval is non-zero, there are some configurations you need to avoid 🚫. if the RTCP bandwidth you pick makes the Td value smaller than, but close to, T_rr_interval, then the actual regular RTCP packet transmission interval can get really large, as covered in Section 7.1.1 😱. so for configurations where you want Td to be smaller than T_rr_interval, Td is RECOMMENDED to be targeted at values less than 1/4th of T_rr_interval. that makes the range become [0.5*T_rr_interval, 1.81*T_rr_interval] 🎯.

with RTP/AVPF or RTP/SAVPF, setting T_rr_interval = 0 is useful too 🙌. this gives a behavior where RTCP transmission is only limited by the bandwidth, meaning no Tmin limitations at all 🏃‍♀️. that allows more frequent regular RTCP reporting than RTP/AVP can ever reach. lots of RTCP configurations don't end up using all the bandwidth they've been given, but this one will use whatever it's been handed 💸. also, the same behavior happens as long as T_rr_interval is smaller than 1/3 of Td, since that stops T_rr_interval from affecting the transmission 🧘‍♀️.

last thing: there's no way to use different regular RTCP reporting intervals based on the media type or individual RTP stream, unless you put each type or stream in its own RTP session 🗂️. so plan accordingly, bestie 💖.

8. Security Considerations 🔐

okay, this part is serious, so let's go 🫡. when you use the secure RTP protocol (RTP/SAVP) [RFC3711], or the secure variant of the feedback profile (RTP/SAVPF) [RFC5124], the cryptographic context of a compound secure RTCP packet is the SSRC of the sender of the first RTCP (sub-)packet 🔑. this could matter in some cases, especially for keying mechanisms like MIKEY [RFC3830] that allow per-SSRC keying 😳.

otherwise, the standard security considerations of RTP still apply. sending multiple RTP streams from a single endpoint in a single RTP session doesn't seem to have different security consequences than sending the same number of RTP streams spread across different RTP sessions 🌸.

9. References ✨

The reference entries keep going in the next part 🧚.

9.1. Normative References ✨

These are the must-reads, the ones you need in your back pocket before anything else makes sense 📚

9.2. Informative References 🔍

These ones are the background reading. Super useful for the deep dive, but you don't need them to get the main idea 🧠

Acknowledgments 🫶

The authors would like to give a big shoutout to Harald Alvestrand and everyone else who helped out with developing this document 💜

Authors' Addresses 🖋️

Jonathan Lennox
Vidyo, Inc.
433 Hackensack Avenue
Seventh Floor
Hackensack, NJ  07601
United States of America

Email: jonathan@vidyo.com


Magnus Westerlund
Ericsson
Farogatan 2
SE-164 80 Kista
Sweden

Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com


Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China

Email: bill.wu@huawei.com


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

Email: csp@csperkins.org

That's the whole RFC, bestie! 🌈✨

📦 where this page comes from