RFC 3556

RFC 3556 💖 Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth

Okay bestie, here's the tea 🎀 This one's by S. Casner at Packet Design, it's a Standards Track doc from the Network Working Group, and it's dated July 2003. The title block doesn't list anything it obsoletes or updates, so no drama there ✨

---

Status of This Memo 📜

This is an Internet standards track protocol for the Internet community, and the doc is asking for discussion and suggestions for improvements 🫶 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) edition. Distribution of this memo is unlimited 🌸

Copyright Notice 🎀

Copyright (C) The Internet Society (2003). All Rights Reserved. 💅

Abstract ✨

So this doc adds an extension to the Session Description Protocol (SDP) that gives the bandwidth attribute two extra modifiers 🧚 Those modifiers let you set the bandwidth for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session. Iconic, honestly 👑

---

1. Introduction 🦋

Okay so RTP (that's RFC 3550 [1]) has a control protocol called RTCP. It sends synchronization info from data senders and feedback info from data receivers. It's literally the vibe check of the whole session 💅

Normally, RTCP gets 5% of the session bandwidth. But sometimes it makes sense to set the RTCP bandwidth on its own, separate from the session bandwidth. That's a big deal for rate-adaptive apps, because they can set RTCP to match a "typical" data bandwidth that's lower than the session maximum. That keeps RTCP under 5% of the data bandwidth once the rate has been adapted downward 🍓

Then there are the apps on the other side of the spectrum. They send data at very low rates but still need to share extra RTCP info, like APP packets. These apps might need RTCP bandwidth higher than 5% of the data bandwidth 🔥

The RTP spec lets a profile split the RTCP bandwidth into two session parameters: one for active data senders, and one for everyone else. Why does that matter? Setting the non-sender RTCP bandwidth to zero turns off reception reports entirely, while the sender RTCP bandwidth stays non-zero so sender reports can still go out for inter-media synchronization 🌈

Now, turning off RTCP reception reports is not recommended, because the RTP spec needs them for things like reception quality feedback and congestion control. ngl that's a big deal 🙈 Doing it can still be fine for systems on unidirectional links, or for sessions that don't need feedback on reception quality or receiver liveness and have other ways to avoid congestion ✨

This memo defines an extension to the Session Description Protocol (SDP) [3] that sets RTCP bandwidth for senders and for non-senders (receivers) 💖

---

2. SDP Extensions 🌈

The Session Description Protocol has an optional bandwidth attribute, and its syntax looks like this:

b=<modifier>:<bandwidth-value>

Here, <modifier> is a single alphanumeric word that says what the bandwidth number means, and the default units for <bandwidth-value> are kilobits per second. This attribute gives the proposed bandwidth for the session or the media 🎀

A classic use is the modifier "AS" (for Application Specific Maximum), which can set the total bandwidth for one media stream from one site (source) 🫶

This memo adds two more bandwidth modifiers:

b=RS:<bandwidth-value>

b=RR:<bandwidth-value>

"RS" is the RTCP bandwidth for active data senders (as the RTP spec defines them), and "RR" is the RTCP bandwidth for everyone else in the RTP session, aka receivers 🦋 What actually happens when you set these depends on the algorithm used to calculate the RTCP reporting interval. Different RTP profiles can specify different algorithms 🧚

For the RTP A/V Profile [2], which says the default RTCP interval algorithm from the RTP spec [1] is used, at least RS/(RS+RR) of the RTCP bandwidth goes to active data senders. If the share of senders out of all participants is less than or equal to RS/(RS+RR), each sender gets RS divided by the number of senders. When the share of senders is greater than RS/(RS+RR), the senders get their share of the sum of these parameters. That means a sender and a non-sender each get the same allocation 😭 So you can't make data senders use less RTCP bandwidth than non-senders. Some special cases are worth knowing about:

• If RR is zero, then the share of participants that are senders can never be greater than RS/(RS+RR), so non-senders never get any RTCP bandwidth, no matter how many senders there are.
• Setting RS to zero doesn't stop data senders from sending RTCP packets. It just means they're treated the same as non-senders. If RR is non-zero, the share of senders (if there are any) would always be greater than RS/(RS+RR).
• If RS and RR are both zero, it would be unwise to try calculating the fraction RS/(RS+RR) 💀

The bandwidth that RS and RR set covers the total bandwidth used by all RTCP packet types, including SR, RR, SDES, BYE, APP, and any new types defined in the future 👑 The <bandwidth-value> for these modifiers is in bits per second and has to be an integer 💅

NOTE: This spec clashed with the original SDP spec in RFC 2327, which says the <bandwidth-value> for all bandwidth modifiers should be an integer number of kilobits per second. The mismatch happened because the RTCP bandwidth you want might be less than 1 kb/s 🙈 At the 44th IETF meeting in Minneapolis, there were two options: allow fractional values, or make the units for these particular modifiers bits per second. People liked the second one better, since it means the syntax doesn't change. The SDP spec is being updated [4] to advance to Draft Standard, and that will allow this change in semantics ✨

---

3. Default values 🎀

If either or both of the RS and RR bandwidth specifiers get left out, the default values come from whatever RTP profile the session is using 🍓 For the Audio/Video Profile, RFC 3551 [2], the defaults follow the RTP spec's recommendations:

• The total RTCP bandwidth is 5% of the session bandwidth. If one of these RTCP bandwidth specifiers is left out, its value is 5% minus the value of the other one, but never less than zero. If both are left out, the sender and receiver RTCP bandwidths are 1.25% and 3.75% of the session bandwidth, respectively 🦋
• At least RS/(RS+RR) of the RTCP bandwidth goes to active data senders. When the share of senders is greater than RS/(RS+RR) of the participants, the senders get their share of the sum of these parameters 🌸

This memo doesn't put limits on the values for the RR and RS modifiers, except that they must be non-negative. The RTP spec and the matching RTP profile might still set limits 🫶

---

4. Precedence 👑

An SDP description has a session-level description (details that apply to the whole session and all media streams) and zero or more media-level descriptions (details for just one media stream) 🧚 Bandwidth specifiers can show up at the session level to set the total bandwidth shared by all media, in the media sections to set the bandwidth for each medium, or in both places. That goes for the two RTCP bandwidth modifiers defined here too 💖

The RTCP bandwidth is a fraction of the session bandwidth when the modifiers defined here aren't set explicitly. So the session bandwidth and RTCP bandwidth specifiers at the session and media levels can interact. Here's the precedence order, with (1) being the highest:

1. Explicit RR or RS specifier at media level
2. Explicit RR or RS specifier at session level
3. Default based on session bandwidth specifier at media level
4. Default based on session bandwidth specifier at session level

Specifically, the relationship between (2) and (3) means that if the RR bandwidth is set to zero at the session level, RTCP transmission turns off for non-data-senders in all media 🙈✨

8.1. Normative References

Okay bestie, these are the must-reads 📚 that the spec leans on hard:

• [1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications," RFC 3550, July 2003.
• [2] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 3551, July 2003.
• [3] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.

8.2. Informative References

These one's more like extra reading for the curious 🧚

• [4] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", Work in Progress.

9. Author's Address ✨

Here's where you can find the author, Stephen L. Casner, over at Packet Design 💌

Stephen L. Casner
Packet Design
3400 Hillview Avenue, Building 3
Palo Alto, CA 94304
United States

Phone: +1 650 739-1843
EMail: casner@acm.org

10. Full Copyright Statement 🎀

Copyright (C) The Internet Society (2003). All Rights Reserved.

Okay so the legal bit, but make it cute 💅 This document and its translations can be copied and handed out to others, and derivative works that comment on it, explain it, or help people implement it can be written, copied, published and shared, in whole or in part, with no restriction of any kind. The one condition is that the copyright notice and this paragraph have to be on every copy and every derivative work. BUT the document itself may not be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed to develop Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's translated into languages other than English.

The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Forever and ever 🌈

This document and the information in it are provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 💜