RFC 5506

Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences

📅 published April 2009, from ietf

Network Working Group I. Johansson Request for Comments: 5506 M. Westerlund Updates: 3550, 3711, 4585 Ericsson AB Category: Standards Track April 2009

Okay bestie, let's talk about RFC 5506 🎀 It's a Standards Track doc from April 2009, written by I. Johansson and M. Westerlund at Ericsson AB, and it is literally about Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences 🦋 It updates RFC 3550, RFC 3711, and RFC 4585, so those three are getting a glow-up too ✨

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Abstract 🌸

This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This document updates RFC 3550, RFC 3711, and RFC 4585.

Table of Contents 🧚

1. Introduction ....................................................3
2. Terminology .....................................................3
3. Use Cases and Design Rationale ..................................4
   3.1. RTCP Compound Packets (Background) .........................4
   3.2. Use Cases for Reduced-Size RTCP ............................6
   3.3. Benefits of Reduced-Size RTCP ..............................7
   3.4. Issues with Reduced-Size RTCP ..............................8
        3.4.1. Middle Boxes ........................................9
        3.4.2. Packet Validation ...................................9
        3.4.3. Encryption/Authentication ..........................10
        3.4.4. RTP and RTCP Multiplex on the Same Port ............10
        3.4.5. Header Compression .................................11
4. Use of Reduced-Size RTCP with AVPF .............................11
   4.1. Definition of Reduced-Size RTCP ...........................12
   4.2. Algorithm Considerations ..................................12
        4.2.1. Verification of Delivery ...........................12
        4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP .....13
        4.2.3. Enforcing Compound RTCP ............................13
        4.2.4. Immediate Feedback Mode ............................14
5. Signaling ......................................................14
6. Security Considerations ........................................14
7. IANA Considerations ............................................14
8. Acknowledgements ...............................................15
9. References .....................................................15
   9.1. Normative References ......................................15
   9.2. Informative References ....................................16

1. Introduction 💖

Okay so in RTP [RFC3550], it is currently MUST-level mandatory to send RTP Control Protocol (RTCP) packets as compound packets containing at least a sender report (SR) or receiver report (RR), followed by a source description (SDES) packet containing at least the CNAME item. There are good reasons for this, as discussed below (see Section 3.1). However, it does result in the minimal RTCP packets being quite large 😭

The RTP/AVPF profile [RFC4585] specifies new RTCP packet types for feedback messages. Some of these feedback messages would benefit from being transmitted with minimal delay. AVPF provides some mechanisms to support this, however for environments with low-bitrate links, these messages can still consume a large amount of resources and can introduce extra delay in the time it takes to completely send the compound packet in the network. It is therefore desirable to send just the feedback, without the other parts of a compound RTCP packet. This memo proposes such a mechanism for this and other use cases, as discussed in Section 3.2.

There are a number of benefits with Reduced-Size RTCP; these are discussed in Section 3.3.

The use of Reduced-Size RTCP is not without issues. This is discussed in Section 3.4. These issues need to be considered and are part of the motivation for this document.

Finally, this document defines how AVPF is updated to allow for the transmission of Reduced-Size RTCP in a way that would not substantially affect the mechanisms that compound packets provide; see Section 4 for more details. The connection to AVPF (or SAVPF [RFC5124]) is motivated by the fact that Reduced-Size RTCP is mainly beneficial for event-driven feedback purposes and that the AVPF Early RTCP and Immediate Feedback modes make this possible.

This document updates [RFC3550], [RFC3711], and [RFC4585].

2. Terminology 🦋

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Okay the naming for RTCP is honestly kinda confusing, so here's a list of the terms and what they mean 🫶 See also Section 6.1 in [RFC3550] and Section 3.1 in [RFC4585] for the full details.

RTCP packet: Can be of different types. It contains a fixed header part followed by structured elements depending on the RTCP packet type.

Lower layer datagram: Can be interpreted as the UDP payload. It may however, depending on the transport, be a TCP or Datagram Congestion Control Protocol (DCCP) payload or something else. This is synonymous to the "underlying protocol" defined in Section 3 in [RFC3550].

Compound RTCP packet: A collection of two or more RTCP packets. A compound RTCP packet is transmitted in a lower-layer datagram. It must contain at least an RTCP RR or SR packet and an SDES packet with the CNAME item. Often "compound" is left out, so the interpretation of RTCP packet is dependent on the context.

Minimal compound RTCP packet: A compound RTCP packet that contains the RTCP RR or SR packet and the SDES packet with the CNAME item with a specified ordering.

(Full) compound RTCP packet: A compound RTCP packet that conforms to the requirements on minimal compound RTCP packets and contains more RTCP packets.

Reduced-Size RTCP packet: May contain one or more RTCP packets but does not follow the compound RTCP rules defined in Section 6.1 in [RFC3550] and is thus neither a minimal nor a full compound RTCP. See Section 4.1 for a full definition.

3. Use Cases and Design Rationale 🌈

(Part 1 ends here, more to come in the next part, periodt!) 💅

3.1. RTCP Compound Packets (Background) 🎀

okay so bestie, Section 6.1 in [RFC3550] says an RTCP packet must be sent as a compound RTCP packet made of at least two individual RTCP packets 💌. First comes a sender report (SR) or receiver report (RR), then extra packets, including a mandatory SDES packet with a CNAME item for the transmitting source identifier. Here's what each of these packet types does, lowkey my favorite part 🫶

  1. The sender and receiver reports (see Section 6.4 of [RFC3550]) give each RTP session participant the synchronization source (SSRC) identifier of all the other participants ✨. When everyone sends these periodically, everyone can figure out how many people are in the session right now. That count feeds into the transmission scheduling algorithm, so it's extra important for new joiners, who can quickly build a good estimate of the group size. Skip this and RTCP senders would end up eating way too much bandwidth 💀
  2. Before a new session participant has sent any RTP or RTCP packet, it can also avoid SSRC collisions with all the SSRCs it sees before that transmission 🦋. Seeing a big chunk of the participating sources means the risk of a collision when picking an SSRC is minimized. So smart!
  3. The sender and receiver reports carry basic statistics for monitoring the transport, which enables adaptation 📊. These reports get more useful when they're sent regularly, because the receiver can spot trends between individual reports. For media transmission adaptation, the info gets more useful the more often it's received, at least until you hit one report per round-trip time (RTT) 🌸. So in most cases, there's no reason not to include the sender or receiver report in all RTCP packets.
  4. The CNAME SDES item (see Section 6.5.1 of [RFC3550]) exists so receivers can figure out which media flows should be synchronized with each other 🎶. That includes flows within an RTP session and flows across different RTP sessions carrying different media types. So it's important to get this quickly for each media sender when you join an RTP session 🏃‍♀️
  5. Sender reports (SR) team up with the CNAME mechanism to synchronize multiple RTP streams, like audio and video 🎬. Once the receiver has worked out which streams should be synced using the CNAME field, it uses the sender report's NTP and RTP timestamp fields to actually establish the synchronization ⏰
  6. The CNAME SDES item also lets a session participant detect SSRC collisions and tell them apart from routing loops 🧩. The 32-bit SSRC is randomly selected, so it has some probability of colliding. The CNAME is the longer canonical identifier of a particular endpoint instance, bound to an SSRC. If that binding isn't received and kept current, the receiver may not detect an SSRC collision, i.e., two different CNAMEs using the same SSRC. It also can't detect an RTP-level routing loop, which is when the same SSRC and CNAME arrive from multiple lower-layer source addresses 😭

Reviewing all of this, it's obvious that both the SR/RR and the CNAME are super important 👑. They're how new session participants can actually use any received media, and how the network avoids getting flooded with RTCP reports. On top of that, the info they carry is dynamic, so it gets less useful if it isn't sent regularly.

The following sections will describe the cases where Reduced-Size RTCP is beneficial, and they'll also show the possible issues you need to consider 🔍

3.2. Use Cases for Reduced-Size RTCP 🧁

Here are a few use cases for Reduced-Size RTCP, bestie 💖

  • Control Plane Signaling: The Open Mobile Alliance (OMA) Push-to-talk over Cellular (PoC) [OMA-PoC] makes use of Reduced-Size RTCP when transmitting certain events 📞. The OMA PoC service is mainly used over cellular links that can carry IP transport, like the Global System for Mobile Connections (GSM) General Packet Radio Service (GPRS).
  • Codec Control Signaling: An example is the Temporary Maximum Media Stream Bitrate Request (TMMBR) messages specified in [RFC5104], which signal a request to change the codec bitrate 🎚️. These messages benefit from Reduced-Size RTCP in bad channel conditions, because Reduced-Size RTCP is much more likely to get through successfully than a larger compound RTCP. This is critical, since these messages tend to show up when channel conditions are poor 🥺. Other examples of codec control usage for Reduced-Size RTCP can be found in [MTSI-3GPP].
  • Feedback: A feedback scenario that would benefit from Reduced-Size RTCP is video streams with generic NACK 🎥. When the RTT is shorter than the receiver buffer depth, generic NACK can request retransmission of missing packets, which seriously improves playout quality ✨. If the generic NACK packets go out as Reduced-Size RTCP, the bandwidth needed for RTCP is minimal, which makes room for more frequent feedback. Like the codec control case, it's important that these packets can be transmitted with as little delay as possible ⚡. Another interesting use is when regular feedback is needed, as described in Section 3.3.
  • Status Reports: One proposed idea is to send small measurement or status reports in Reduced-Size RTCP, and to split the minimal compound RTCP so the individual RTCP packets go out separately 📦. The status reports can be used by the endpoints or by other network monitoring boxes in the network 🖥️. The benefit is that, with some radio access technologies, small packets hold up better to poor radio conditions than large ones 📶. Also, with small report packets, there's a smaller risk that the reports will affect the channel they're reporting on. Another perk: with Reduced-Size RTCP, it's possible to let something like anonymous status reporting go out unencrypted 🔓. That could be really useful for network monitoring purposes, iykyk 🙈

3.3. Benefits of Reduced-Size RTCP 💜

As I mentioned in the intro, most of the advantages of Reduced-Size RTCP packets show up when the available RTCP bitrate is limited 🪫. That's because they can end up way smaller than compound packets. A compound packet is forced to contain both an RR or an SR and the CNAME SDES item. An RR with a report block for a single source is 32 bytes, and an SR is 52 bytes. Both can get bigger if they contain report blocks for multiple sources 📈. The SDES packet with a CNAME item is 10 bytes plus the length of the CNAME string. It's reasonable for the CNAME string to be at least 10 bytes so you get decent collision resistance 🛡️. If the recommended form of user@host is used, most strings will be longer than 20 characters. So a Reduced-Size RTCP can end up at least 70-80 bytes smaller than the compound packet 🤏

For low bitrate links, the benefits of this size reduction look like this:

  • For links where the packet-loss rate grows with the packet size, smaller packets are less likely to get dropped 📉. Radio links are a great example. In the cellular world, some links are optimized to handle RTP packets sized for compressed speech 🎙️. That boosts the capacity and coverage for voice services in a given wireless network. Minimal compound RTCP packets are commonly 2-3 times the size of an RTP packet carrying compressed speech. If the speech packet over such a bearer has a packet-loss probability of p, the RTCP packet will experience a loss probability of 1-(1-p)^x, where x is the number of fragments the compound packet gets split into on the link layer, i.e., commonly 2 or 3 fragments 🧩
  • There's a shorter serialization time, which is how long it takes the link to transmit the packet ⏳. For slower links this can be substantial. For example, transmitting 120 bytes over a link interface capable of 30 kbps takes 32 milliseconds (ms), assuming a uniform transmission rate 🐢
When Reduced-Size RTCP carries important, time-sensitive feedback, both the shorter serialization time and the lower loss probability really matter for getting the best possible functionality 🚨 If the feedback packets have a much higher packet-loss rate than the media packets, it hurts media adaptation. For example, that could mean handling changed performance at the cell border in a cellular system 🗼

For high-bitrate applications, there's usually no problem supplying RTCP with sufficient bitrates 🚀. When using AVPF, you can use the "trr-int" parameter to restrict the regular reporting interval to approximately once per RTT or less often. In most cases there's little reason to send regular reports denser than that, so any extra bandwidth can go to feedback messages 💅. The benefit of Reduced-Size RTCP here is limited, but it does exist. One typical example is video using generic NACK when the RTT is low. Using Reduced-Size RTCP would cut down the total number of bits used for RTCP 🧮. That mainly matters when the number of reports is large. It would also mean lower processing delay and less complexity for the feedback packets, since they don't need to query the RTCP database to build the right messages 🧠

Since message size is usually a smaller issue at higher bitrates, it's also possible to transmit multiple RTCP packets in each lower-layer datagram 📬. In this case, the motivation for Reduced-Size RTCP isn't size. It's about avoiding the extra overhead caused by including the SR/RR and SDES CNAME items in every transmitted RTCP packet 🙅‍♀️

Regardless of link type, there are extra benefits to sending feedback in small Reduced-Size RTCP 🌈. Applications that use RTCP AVPF in Early RTCP or Immediate Feedback mode need to send frequent, event-driven feedback. Under these circumstances, the risk is reduced that the RTCP bandwidth becomes too high during periods of heavy feedback signaling 🔥

When regular feedback is needed, like the profile under development for TCP friendly rate control (TFRC) for RTP [TCP-FRIEND], the size of compound RTCPs can lead to very high bandwidth requirements if the round-trip time is short 😵. For this particular application, Reduced-Size RTCP gives a very substantial improvement 🏆

3.4. Issues with Reduced-Size RTCP 🔎

This section walks through the known issues with Reduced-Size RTCP 🧐. It also gives a brief analysis of their effects and how to mitigate them.

3.4.1. Middle Boxes 🦋

Okay so middle boxes in the network are like sneaky little gatekeepers 👀, and they may throw away RTCP that doesn't follow the rules in Section 6.1 of RFC 3550. Newer report types might look totally unknown to them. For example, if the payload type number is 207 instead of 200 or 201, the box may treat it as unknown 😭. The result could be that compound RTCP gets through just fine while the Reduced-Size RTCP gets lost. Not fair, honestly 💅.

Checking whether Reduced-Size RTCP actually gets delivered is covered in Section 4.2.1 🔍.

3.4.2. Packet Validation 🧚

Okay this one is a whole saga. A Reduced-Size RTCP packet will get discarded by the packet validation code in Appendix A of [RFC3550] 💀. That causes a few different problems:

Weakened Packet Validation: The packet validation code needs to be rewritten so it accepts Reduced-Size RTCP. This especially touches Section 9.1 in [RFC3550], because the header verification has to account for the fact that the payload type number of the (first) RTCP in the lower-layer datagram may be something other than 200 or 201 (SR or RR). One possible side effect is way weaker validation, where a receiver can't really be sure that a packet is RTCP and not some other packet type that got delivered by mistake 🙈. So some thought should be given to making sure the best possible validation is available. For example, Reduced-Size RTCP could be restricted to only certain RTCP packet types, ideally signalled on a per-session basis. However, applying a security mechanism for source authentication to the packets will provide much stronger protection 🔐.

Old RTP Receivers: Any RTCP receiver without updated packet validation code will discard the Reduced-Size RTCP, which means it won't see things like the feedback messages inside it. How bad this is depends on the feedback message type and the receiver's role. For instance, sending a Reduced-Size NACK message (see Section 6.2.1 of [RFC4585]) to a non-updated media sender in a session that uses the retransmission scheme from [RFC4588] could cause complete function loss 😱. This kind of discarding would also affect the feedback suppression defined in AVPF. The session would end up partitioned, with the old receivers only seeing the compound RTCP feedback messages and the newer ones seeing both. In that case, the old receivers may send feedback for events that were already reported in Reduced-Size RTCP 🙃.

Bandwidth Considerations: Discarding Reduced-Size RTCP would throw off the RTCP transmission calculation. The avg_rtcp_size value would end up larger than it is for RTP receivers that leave the Reduced-Size RTCP out of this calculation (assuming Reduced-Size RTCP is smaller than compound RTCP). So these senders would under-utilize the available bitrate and send at a longer interval than the updated receivers. For most sessions this shouldn't be a problem 🌸. But in sessions with a large portion of Reduced-Size RTCP, the updated receivers might time out non-updated senders too early. This isn't very likely, though, because the time between compound RTCP transmissions would need to be 5 times that used by the Reduced-Size RTCP senders for it to happen.

Computation of avg_rtcp_size: Long gaps between compound RTCP packets, with lots of Reduced-Size RTCP in between, can make the computed avg_rtcp_size value vary a lot over time 📈. The investigation found that even though it varies, it isn't enough of a problem to justify further changes or extra complexity in the RTCP scheduling algorithm ✨.

3.4.3. Encryption/Authentication 🔐

The Secure Real-time Transport Protocol (SRTP) is a bit of a problem for Reduced-Size RTCP 😬. Section 3.4 of [RFC3711] says, "SRTCP MUST be given packets according to that requirement in the sense that the first part MUST be a sender report or a receiver report".

But once you look at how SRTP actually processes packets, it's pretty obvious that SRTP doesn't really depend on whether the first packet is an SR or an RR 🤯. What it needs is the common RTCP packet header, which is in every packet type and carries a source SSRC. So the conclusion is that Reduced-Size RTCP can be used with SRTP, yay 🎉. Still, because this changes the rules in [RFC3711], changes in SRTP implementations MAY become necessary.

3.4.4. RTP and RTCP Multiplex on the Same Port 🎀

When RTP and RTCP are multiplexed on the same port, as defined in [MULTI-RTP], you have to be careful that de-multiplexing still works properly even though the RTCP packets are reduced size 🧩. The downside of Reduced-Size RTCP is that there are more values representing RTCP packets, which eats into the available RTP payload type space. Good news though: Section 4 in [MULTI-RTP] already requires that the corresponding RTP payload type range not be used when doing this multiplexing 💜.

3.4.5. Header Compression 🌈

Two issues are related to header compression. Possible changes for these are left for future work 🛠️:

  • Payload type number identification: The Robust Header Compression (RoHC) algorithm [RFC3095] needs to create different compression contexts for RTP and RTCP to perform optimally. If RTP and RTCP are multiplexed on the same port, the classification may be based on payload type numbers. The classification algorithm has to account for the fact that the payload type number for (the first) RTCP may be something other than 200 or 201.
  • Compression of RTCP: No IETF-defined header compression method compresses RTCP. However, if such methods are developed in the future, they must take Reduced-Size RTCP into account 🫶.

4. Use of Reduced-Size RTCP with AVPF 💖

Based on the analysis above, it seems feasible to allow Reduced-Size RTCP to be transmitted, under some restrictions 🌟:

  • First of all, compound RTCP needs to be transmitted at regular intervals so that the mechanisms the compound packets maintain, like feedback reporting, keep working. Tracking the session size and number of participants is worth mentioning again here, because it keeps the RTCP bandwidth bounded no matter how many participants there are 📊.
  • Second, because compound RTCP packets are also used to establish and maintain synchronization between media, any newly joining participant needs to receive compound RTCP from the media sender(s) 🧑‍🤝‍🧑.

This means the regular transmission of compound RTCP MUST be maintained throughout an RTP session. Reduced-Size RTCP SHOULD be restricted to use as extra RTCP (for example, feedback), sent in cases where a regular compound RTCP packet would not otherwise have been sent 💅.

Reduced-Size RTCP SHALL only be used in RTP sessions operating in AVPF [RFC4585] or SAVPF [RFC5124] Early RTCP or Immediate Feedback mode. Reduced-Size RTCP SHALL NOT be sent until at least one compound RTCP has been sent. In Immediate Feedback mode, all feedback messages MAY be sent as Reduced-Size RTCP. In Early RTCP mode, a feedback message scheduled for transmission as an Early RTCP, i.e., not a Regular RTCP, MAY be sent as Reduced-Size RTCP. All RTCP that is scheduled for transmission as Regular RTCP SHALL be sent as compound RTCP, as indicated by AVPF [RFC4585] 📜.

4.1. Definition of Reduced-Size RTCP 🦋

A Reduced-Size RTCP packet is an RTCP packet with the following properties, which make it deviate from the compound RTCP packet definition given in Section 6.1 in [RFC3550] 👀:

  • contains one or more RTCP packet(s)
  • allows any RTCP packet type; however, see Section 4.2.1
  • MUST NOT be used for Regular (scheduled) RTCP report purposes
  • MUST NOT be used with the RTP/AVP profile [RFC3551] or the RTP/SAVP profile [RFC3711]

4.2. Algorithm Considerations ✨

4.2.1. Verification of Delivery 🔍

If an application is going to use Reduced-Size RTCP, it's really important to verify that the Reduced-Size RTCP packets actually reach the session participants. As outlined in Section 3.4.1 and Section 3.4.2 above, packets may be discarded along the path or at the endpoint 😤.

A few verification rules are RECOMMENDED to keep RTCP transmission and reception robust and to solve the identified issues when Reduced-Size RTCP is used 🛡️:

  • The endpoint issue can be solved by introducing signaling that tells whether all session participants are capable of Reduced-Size RTCP. See Section 5.
  • The middle box issue is trickier, and here one will be required to use heuristics to determine whether or not the Reduced-Size RTCP packets are delivered. The method used to detect successful delivery of Reduced-Size RTCP packets depends on the packet type. The RTCP packet types for which successful delivery can be detected are:
    • Sender reports (SR): Successful transmission of a sender report can be verified by inspecting the echoed timestamp in the received receiver report (RR). This can also be used as a way to verify whether Reduced-Size RTCP can be used at all.
    • Feedback RTCP packets: In many cases, feedback messages sent using Reduced-Size RTCP will result in explicit or implicit indications that they were received. An example is the RTP retransmission [RFC4588] that results from a NACK message [RFC4585]. Another example is the Temporary Maximum Media Stream Bitrate Notification (TMMBN) message resulting from a Temporary Maximum Media Stream Bitrate Request (TMMBR) [RFC5104]. A third example is the presence of a decoder refresh point [RFC5104] in the video media stream resulting from the Full Intra Request that was sent.

RTCP packet types for which it is not possible to detect successful delivery SHOULD NOT be transmitted as Reduced-Size RTCP packets, unless they are transmitted in the same lower-layer datagram as another RTCP packet type for which successful delivery can be detected.

  • An algorithm to detect consistent failure of delivery of Reduced-Size RTCP MUST be used by any application using Reduced-Size RTCP. The details of this algorithm are application dependent and therefore outside the scope of this document 🙏.

If the verification fails, it is strongly RECOMMENDED that only compound RTCP, according to the rules outlined in RFC 3550, is transmitted 🫠.

4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP 🍓

The definition in Section 4.1 may mean that a Reduced-Size RTCP packet can end up larger than a regularly scheduled compound RTCP packet 📦. For applications that use access types that are sensitive to packet size (see Paragraph 2 in Section 3.3), it is strongly RECOMMENDED that Reduced-Size RTCP is limited to the transmission of a single RTCP packet in each lower-layer datagram. The method to determine whether this is needed is outside the scope of this document.

In general, since the benefit of large Reduced-Size RTCP packets is very limited, it is strongly RECOMMENDED to transmit large Reduced-Size RTCP packets as compound RTCP packets instead 🌷.

4.2.3. Enforcing Compound RTCP ✨

Okay, so remember how it's super important that compound RTCP gets sent at regular intervals? 🫶 Good news: that keeps happening as long as RTCP senders follow the AVPF scheduling algorithm from Section 3.5 of [RFC4585]. Why? Because all Regular RTCP MUST be full compound RTCP 💅. Also, heads up, there's a requirement on sending Regular RTCP in Immediate Feedback mode too, so don't skip that bit 👀.

4.2.4. Immediate Feedback Mode 🦋

Section 3.3 of [RFC4585] lets you use AVPF Immediate Feedback mode as long as the group size is under a certain limit 🌸. Reduced-Size RTCP can lower the bandwidth demand, and that means these transmissions open the door to a more liberal use of Immediate Feedback mode. ngl, that's so iconic 😭

5. Signaling 💌

This document defines the a=rtcp-rsize Session Description Protocol (SDP) [RFC4566] attribute. It tells everyone whether a session participant can support Reduced-Size RTCP, for applications that use SDP to configure RTP sessions 🧚. It is REQUIRED that a participant that proposes the use of Reduced-Size RTCP shall itself support the reception of Reduced-Size RTCP. Bestie, that's the rule: if you're proposing it, you have to be able to receive it too 🫶.

An offering client that wants to use Reduced-Size RTCP MUST include the attribute a=rtcp-rsize in the SDP offer. If a=rtcp-rsize is present in the offer SDP, then an answerer that supports Reduced-Size RTCP and wants to use it SHALL include the a=rtcp-rsize attribute in the answer 🤝.

In declarative usage of SDP, such as the Real Time Streaming Protocol (RTSP) [RFC2326] and the Session Announcement Protocol (SAP) [RFC2974], the presence of the attribute means the session participant MAY use Reduced-Size RTCP packets in its RTCP transmissions 🌈.

6. Security Considerations 🚨

The security considerations of RTP [RFC3550] and AVPF [RFC4585] apply to Reduced-Size RTCP too. The reduction in validation strength for received packets on the RTCP port may result in a higher degree of acceptance of spurious data as real RTCP. Yikes 💀.

This vulnerability can mostly be addressed by using any security mechanism that provides authentication. One such mechanism is SRTP [RFC3711]. Please, please use authentication 🔐😭.

7. IANA Considerations 📋

Following the guidelines in [RFC4566], the IANA has registered a new SDP attribute:

  • Contact name, email address, and telephone number: Authors of RFC 5506
  • Attribute-name: rtcp-rsize
  • Long-form attribute name: Reduced-Size RTCP
  • Type of attribute: media-level
  • Subject to charset: no

This attribute defines the support for Reduced-Size RTCP, i.e., the possibility to transmit RTCP that does not conform to the rules for compound RTCP defined in RFC 3550. It is a property attribute, which does not take a value 🎀.

8. Acknowledgements 🙏

The authors would like to thank all the people who gave feedback on this document. Special thanks go to Colin Perkins 💜.

This document also contains some text copied from [RFC3550], [RFC4585], and [RFC3711]. We take this opportunity to thank the authors of said documents 🫶.

9. References 📚

9.1. Normative References

[RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3550]     Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

[RFC3551]     Schulzrinne, H. and S. Casner, "RTP Profile for Audio
              and Video Conferences with Minimal Control", STD 65,
              RFC 3551, July 2003.

[RFC4585]     Ott, J., Wenger, S., Sato, N., Burmeister, C., and J.
              Rey, "Extended RTP Profile for Real-time Transport
              Control Protocol (RTCP)-Based Feedback (RTP/AVPF)",
              RFC 4585, July 2006.

[RFC5124]     Ott, J. and E. Carrara, "Extended Secure RTP Profile
              for Real-time Transport Control Protocol (RTCP)-Based
              Feedback (RTP/SAVPF)", RFC 5124, February 2008.

9.2. Informative References

[MTSI-3GPP]   3GPP, "Specification : 3GPP TS 26.114 (v8.2.0 or
              later), http://www.3gpp.org/ftp/Specs/html-info/
              26-series.htm", March 2007.

[MULTI-RTP]   Perkins, C. and M. Westerlund, "Multiplexing RTP Data
              and Control Packets on a Single Port", Work
              in Progress, August 2007.

[OMA-PoC]     Open Mobile Alliance, "Specification : Push to talk
              Over Cellular User Plane, http://
              member.openmobilealliance.org/ftp/public_documents/poc/
              Permanent_documents/
              OMA-TS-PoC_UserPlane-V2_0-20080507-C.zip",
              November 2006.

[RFC2326]     Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
              Streaming Protocol (RTSP)", RFC 2326, April 1998.

[RFC2974]     Handley, M., Perkins, C., and E. Whelan, "Session
              Announcement Protocol", RFC 2974, October 2000.

[RFC3095]     Bormann, C., Burmeister, C., Degermark, M., Fukushima,
              H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T.,
              Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro,
              K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust
              Header Compression (ROHC): Framework and four profiles:
              RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.

[RFC3711]     Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
              K. Norrman, "The Secure Real-time Transport Protocol
              (SRTP)", RFC 3711, March 2004.

[RFC4566]     Handley, M., Jacobson, V., and C. Perkins, "SDP:
              Session Description Protocol", RFC 4566, July 2006.

[RFC4588]     Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format",
              RFC 4588, July 2006.

[RFC5104]     Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback (AVPF)", RFC 5104, February 2008.

[TCP-FRIEND]  Gharai, L., "RTP with TCP Friendly Rate Control", Work
              in Progress, July 2007.

Authors' Addresses 🎀

Ingemar Johansson
Ericsson AB
Laboratoriegrand 11
SE-971 28 Lulea
SWEDEN

Phone: +46 73 0783289
EMail: ingemar.s.johansson@ericsson.com


Magnus Westerlund
Ericsson AB
Faeroegatan 6
SE-164 80 Stockholm
SWEDEN

Phone: +46 10 7148287
EMail: magnus.westerlund@ericsson.com
📦 where this page comes from