RFC 5968

Guidelines for Extending the RTP Control Protocol (RTCP)

📅 published September 2010, from ietf

RFC 5968: Guidelines for Extending the RTP Control Protocol (RTCP) 🎀

Okay bestie, let's get the vitals first 💅 This is an Informational RFC, so it's published for information and isn't an Internet Standards Track spec ✨ The authors are J. Ott from Aalto University and C. Perkins from the University of Glasgow 🧚 It came out in September 2010 with ISSN 2070-1721. The title block doesn't list anything this one obsoletes or updates, so it stands on its own 🌸

Abstract 🌸

RTCP is the RTP Control Protocol, and it works alongside RTP (the Real-time Transport Protocol) to give media senders and receivers a control channel 🦋 That lets you build a feedback loop for things like application adaptation and monitoring, plus other stuff. RTCP's basic reporting mechanisms are generic but seriously powerful, and they cover a bunch of use cases ✨ This doc is here to give guidelines for extending RTCP in case those basic mechanisms aren't enough 💖

Status of This Memo 📝

Not an Internet Standards Track spec, just informational vibes 🌈

This is an IETF product 💜 It reflects what the IETF community agreed on, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🔥

For current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5968 🧚

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 💅

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date 📜 Read those carefully, bestie, because they spell out your rights and restrictions for this document 🫶 If you pull Code Components out of this doc, they have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🔥

Table of Contents 📑

1. Introduction ....................................................3
2. Terminology .....................................................4
3. RTP and RTCP Operation Overview .................................4
   3.1. RTCP Capabilities ..........................................5
   3.2. RTCP Limitations ...........................................7
   3.3. Interactions with Network- and Transport-Layer Mechanisms ..8
4. Issues with RTCP Extensions .....................................9
5. Guidelines .....................................................10
6. Security Considerations ........................................14
7. Acknowledgements ...............................................15
8. References .....................................................15
   8.1. Normative References ......................................15
   8.2. Informative References ....................................16

1. Introduction ✨

Okay so RTP ([RFC3550]) is what carries time-dependent media, usually continuous stuff like audio or video, across a packet network in an RTP session 🎧 It normally rides on top of an unreliable transport like UDP, Datagram Transport Layer Security (DTLS), or the Datagram Congestion Control Protocol (DCCP) 💀 So RTP packets can get lost, reordered, or duplicated, which is giving chaos 😭

Then there's RTCP, which is the control channel for each session 🦋 Media senders share what they're currently sending (that's the "feed forward" part), and media receivers report their reception stats (that's "feedback") in terms of received packets, losses, and jitter 📊 Senders and receivers also give self-descriptions so every entity in an RTP session can be told apart, and so they can match synchronisation source (SSRC) identifiers to specific application instances 🫶 RTCP rides the same transport as RTP and is inherently best-effort, so its reports are built for an unreliable environment. They're "for information only" 🙈

The RTCP control channel gives coarse-grained info about the session in two ways 🍓 First, the RTCP sender report (SR) and receiver report (RR) packets only have cumulative information or means over a period of time. Second, that period is on the order of seconds, so the resolution isn't high and the feedback doesn't come back instantly 🐢 Both of these limits come from RTP being scalable and generic, which is honestly a power move 💪 Even these basic mechanisms (which still aren't implemented everywhere, even though they're simple and precisely specified, sample code included 😤) give a ton of info for designing adaptive apps and monitoring, among other things 👑

Lately, people have proposed loads of extensions to RTCP in different contexts 🌸 These make the protocol way more complex, change the kind of values it reports, push it toward a command channel, and/or try to turn it into a reliable messaging protocol 🔥 The reasons can be legit, but a lot of these designs look ill-advised once you consider the RTP architecture 🤔 Plus, extensions are often badly motivated and end up unnecessary, because RTCP's current mechanisms can already do the job 💅

So this doc gives guidelines for designing RTCP extensions 💖 The big goal is to avoid extension creep for corner cases, because those can only hurt interoperability and the future evolution of the protocol as a whole 🚫 First we go over how RTCP works and how to build feedback loops with its basic mechanisms 🧩 Next we cover the categories of extensions that have been proposed (and some already accepted) and talk through the issues and alternative ways of thinking, with examples 🎀 Finally we give some guidelines and a list of questions to ask (and answer!) before you write up an RTCP extension 📝✨

2. Terminology 📖

The terminology from "RTP: A Transport Protocol for Real-Time Applications" [RFC3550], "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551], and "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585] applies here 🧚 Go read those if you want the full picture, bestie 📚

3. RTP and RTCP Operation Overview 🦋

One of the twelve networking truths in [RFC1925] says: "In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away". 💅 Yes, this is an April 1st RFC, but honestly, this truth is 100% valid and it applies to RTCP too 🌈

In this section we'll quickly look at what the basic RTP/RTCP specs already give us ✨ We only count the generic specs, meaning the ones that don't depend on a particular media type 🎀 That includes the RTP base spec [RFC3550] and profile [RFC3551], the RTCP bandwidth modifiers for session descriptions [RFC3556], the timely feedback extensions (RFC 4585), and the extensions for running RTCP over source-specific multicast (SSM) networks [RFC5760] 💖 RTCP extended reports (XRs) [RFC3611] also give extended reporting, which is partly generic and partly specific to a certain media stream 📊

We're not going to discuss RTP-related docs that are orthogonal to RTCP 🙈 The Secure RTP Profile [RFC3711] can secure RTCP the same way it secures RTP data, but otherwise it doesn't change how RTCP behaves 🔐 The transport protocol barely matters either, since RTCP is still a group communication protocol even over a unicast transport (like TCP [RFC4571] or DCCP [RFC5762]), and congestion control doesn't affect it much because its rate is low compared to the media 🐢 The description of RTP topologies [RFC5117] is useful knowledge, but it's functionally not relevant here 🗺️ The various RTP error correction mechanisms (e.g., [RFC2198], [RFC4588], [RFC5109]) are great for protecting RTP media streams and can be turned on because of RTCP feedback, but they don't directly change RTCP behaviour 🛡️ Last one: RTP and RTCP can be multiplexed inside the same transport connection or on the same port number [RFC5761]. That doesn't change how RTCP operates, though. You can tell RTP and RTCP packets apart because the code points for RTCP and the payload types for RTP use disjoint number spaces 🧠✨

3.1. RTCP Capabilities ✨

okay bestie, so the RTP/RTCP specs we just covered come with feedback mechanisms that have these properties 🧚 and they're basically the building blocks for adaptive real-time apps over IP networks 🔥

  • Sender reports (SRs) tell receivers the total number of packets and octets sent so far (since the session started or since the sender's SSRC last changed) 💅 From those numbers you can work out the mean data rate and mean packet size for the whole session, and if someone keeps monitoring, for every transmission interval 📈 They also let a receiver tell apart a gap in reception caused by network problems from one caused by the sender just pausing 🙈
  • Receiver reports (RRs) and SRs carry reception statistics from each receiver for every sender 🫶 The stats include:
    • The packet loss rate since the last SR or RR was sent.
    • The total number of packets lost since the session started, which can also be broken down per reporting period.
    • The highest sequence number received so far 🦋 This lets a sender roughly estimate how much data is in flight when combined with the SR and RR timestamps, and it also shows whether the path still works and at what rate packets are reaching the receiver.
    • The moving average of the inter-arrival jitter of media packets 🌸 This gives the sender an indirect look at how big an adaptive playout buffer the receiver is using ([RFC3611] has the precise figures for Voice over IP (VoIP) sessions).
  • Sender reports also carry NTP and RTP format timestamps ⏱️ These let receivers synchronise multiple RTP streams, and (when paired with receiver reports) let the sender calculate the current round-trip time (RTT) to each receiver 💜 You can watch that value over time to spot trends at a coarse level. [RFC3611] has a similar mechanism so receivers can calculate the RTT to senders.

RTCP sender reports and receiver reports go out, and the stats get sampled, at random intervals picked uniformly from 0.5 to 1.5 times the deterministic calculated interval, T ✨ T is worked out from the media bitrate, the mean RTCP packet size, whether the sampling node is a sender or a receiver, and the number of participants, and it stays constant as long as the participant count stays constant 🎀 The lower bound on the base inter-report interval, T, is five seconds, or 360 seconds divided by the session bandwidth in kilobits/second. That means the interval dips below 5 seconds for bandwidths greater than 72 kbits/s [RFC3550] 👑

This lower limit can be dropped, allowing more frequent feedback, when you use the early feedback profile for RTCP [RFC4585] 🔥 Then the RTCP frequency is only limited by the available bitrate (usually 5% of the media stream bitrate is set aside for RTCP). If that fraction isn't enough, the RTCP bitrate can be bumped up in the session description to get more frequent feedback [RFC3556] 💅 The considerations in [RFC5506] can help shrink the mean RTCP packet size, which pushes feedback frequency even higher 🦋

The mechanisms defined in [RFC4585] even let a receiver give close-to-instant feedback to a sender about observed events in the media stream (like picture or slice loss), statistically speaking 🙈✨

RTCP works for both unicast and multicast 🫶 All the basic functions are designed with group communication in mind. Traditional (any-source) multicast (ASM) is clearly not available across the Internet at large, but source-specific multicast (SSM) and overlay multicast are both real and commercially relevant 💖 RTCP extensions have been defined to run over SSM, and you can build complex topologies by interconnecting RTP mixers and translators 🧚 The group communication nature of RTP and RTCP is also essential for Multipoint Control Units to work 👑

All of these mechanisms together make a pretty flexible feedback loop, so you can react quickly to observed events and also adapt over the long term to changes in the networking environment 🌈 On the sender side, the adaptation options include (but aren't limited to) picking different codecs, tweaking codec parameters (spatial or temporal resolution for video, audible quality for audio and voice), and using different packet sizes to adjust the bitrate 🎀 Then there's various forward error correction (FEC) mechanisms and, if RTTs are short and the app can handle extra delay, even reactive error control like retransmissions 💅 Long-term feedback comes in regular RTCP reports at configurable intervals, while (close-to-)instant feedback comes through the early feedback profile. Figure 1 below sketches out the whole idea 🦋

 Long-term adaptation:      RTCP sender reports      Media processing:
 - Codec+parameter choice  - Data rate, pkt count    - De-jittering
 - Packet size             - Timing and sync info    - Synchronisation
 - FEC, interleaving       - Traffic characteristics - Error concealment
                   -------------------------------->   - Playout
 +---------------+/                                 \+---------------+
 |               | RTP media stream (codec, repair) |                |
 |  Media sender |=================================>| Media receiver |
 |               |                                  |                |
 +---------------+\         RTCP receiver reports   /+---------------+
                   <--------------------------------
 Short-term reaction:      - long-term statistics    Control functions:
 - Retransmissions         - event information       - RTP monitoring
 - Retroactive FEC         - media-specific info       and reporting
 - Adaptive source coding  - "congestion info"(*)    - Instant event
 - Congestion control(*)                                 notifications

 (*) RTCP feedback is insufficient for the purposes of TCP-friendly
     congestion control due to the infrequent nature of reporting
     (which should be in the order of once per RTT), but can still be
     used to adapt to the available bandwidth on slower time-scales.

                Figure 1: Outline of an RTCP Feedback Loop
It's important to note that not all information needs to be signalled explicitly, ever or in every RTCP packet 🙈 A lot of it can be derived locally from other pieces of information and from how that information changes over time 🧠

3.2. RTCP Limitations 🌸

RTP's design limits what you can meaningfully do with RTCP (and so what you should do with it) 💅 The design leans toward scalability and loose coupling rather than tightly controlled feedback loops 🫶 Some of these limitations are below, and you'll need to take them into account when designing extensions 👀

  • RTCP is built to give occasional feedback, which is very different from something like TCP ACKs that can be sent in response to every (other) packet 😭 It doesn't offer per-packet feedback. Even with [RFC4585] and a bigger RTCP bandwidth fraction, the feedback guarantees are only statistical in nature.
  • RTCP can't give truly instant feedback 🙈
  • RTCP is inherently unreliable and doesn't guarantee any consistency between the observed state at multiple members of a group 💀

It's important to note that these features are intentional design choices, and they're what let RTCP scale to large groups 👑

3.3. Interactions with Network- and Transport-Layer Mechanisms 🦋

As we talked about above, RTCP flows are used to measure, infer, and convey information about how an RTP media stream is performing 💖

Inference in baseline RTCP is mostly limited to working out the path RTT from pairs of RTCP SR and RR packets 🧚 That inference quietly assumes that RTP and RTCP get treated equally: they're routed along the same path, mapped to the same (DiffServ) traffic classes, and treated as part of the same fair queuing classification 🎀 That's true in lots of cases, but since RTP and RTCP usually go out on different ports, any flow classification based on the 5-tuple (source and destination IP addresses, source and destination port numbers, and the transport protocol) could split RTP and RTCP flows apart, and that messes up the statistics 😭

Some networks might want to deliberately prioritise RTCP over RTP (for quicker feedback), or RTP over RTCP (since the media matters more than control) 💅 But we recommend treating them identically where possible, so the inference of network performance still works and apps can keep adapting 🫶

When reliable transport connections are used for (RTP and) RTCP [RFC2326] [RFC4571], retransmissions and head-of-line blocking can also lead to inaccurate RTT estimates derived by RTCP 🙈 (They may still properly reflect the mean RTT for a media packet, retransmissions included.)

The conveyance of information in RTCP is only affected by all of this once prioritisation leads to a disproportionately high number of RTCP packets being dropped 🌈

All of this really hammers home how unreliable RTCP is 💀 Multiplexing on the same port number [RFC5761] or inside the same transport connection might help mitigate some of these effects, but that's still speculation at this point, so it shouldn't be relied upon 🧠✨

4. Issues with RTCP Extensions 💅✨

okay so bestie, this section is basically the "things people have messed up before, so please don't repeat them" list 🫶 It's not exhaustive, and it's definitely not saying every extension idea is bad. It's more like, "hey, these are the traps, let's avoid them." Here we go 🦋

Issues that have come up in the past with extensions to RTP and RTCP include (but are probably not limited to) the following:

  • Defining RTP or RTCP extensions only or primarily for unicast two-party sessions. 🌸 RTP is inherently a group communication protocol, even when it's running on a unicast connection. Extensions might become super useful way outside the area they were originally meant for, so think about that ahead of time. Saying something "works for unicast only" is not acceptable 🙅‍♀️, especially since various flavours of multicast are relevant again, and since middleboxes like repair servers, mixers, and RTCP-supporting Multipoint Control Units (MCUs) [RFC5117] are getting more popular.
  • Assuming reliable (instant) state synchronisation. ⏳ RTCP reports are sent irregularly and may be lost. So there can be a significant time lag (several seconds) between deciding to send a state update to the RTP peer(s) and the packet actually being received. In some cases, the packet may never arrive at all 😭
  • Requiring reliable delivery of RTCP reports. 🔁 You can build reliability on top of RTCP using acknowledgements, but it comes with a big cost in extra delay, which can totally defeat the whole point of giving feedback in the first place 💀 Also, because RTCP is group-based, those ACKs have to be adaptively rate limited or aimed at a subgroup or single entity so they don't implode as group sizes grow. RTCP is not intended or suitable for use as a reliable control channel 🚫
  • Issuing commands, rather than giving hints. 🧚 RTCP is about reporting observations between RTP entities, in a best-effort manner. Making things happen on the remote side needs some form of reliability (see above), and you can't verify that it was followed.
  • Expanding RTCP reporting, to use it as a network management tool. 📊 RTCP is sensitive to the size of its reports, because report size decides the mean reporting interval for a given RTCP bitrate share. (That said, RTCP can also be used to report information with fine-grained temporal characteristics, if summarisation or data reduction by the endpoint would lose essential resolution 🔍.) The information in RTCP reports should mainly target the peer(s), so it should include stuff they can meaningfully react to. Those reports may still be useful to help out other network management tools 🙌. Gathering and reporting statistics beyond that is not an RTCP job, and should be handled by out-of-band protocols 📦
  • Creating serious complexity. 🧩 Related to the last point, RTCP reports that carry all kinds of data have to gather and calculate or infer that information first, which needs very precise specifications. Baseline RTCP is already hard enough to implement, so any extra complexity can only discourage implementers 😩, may lead to buggy implementations (and then the reports don't do their job), and can hinder interoperability.
  • Introducing architectural issues. 🏛️ Some extensions get written without considering the architectural concepts of RTP. For example, point-to-point communication is assumed, yet third-party monitors are expected to listen in. Besides being a bad idea to rely on eavesdropping entities on the path, this is obviously not possible if Secure RTP (SRTP) is being used with encrypted SRTCP packets 🔒

This list is surely not exhaustive. Also, the authors do not claim that the suggested extensions (even if using acknowledgements) would not serve a legitimate purpose. We rather want to draw attention to the fact that the same results may be achievable in a way that is architecturally cleaner and conceptually more RTP/RTCP-compliant ✨ The following section contains a first attempt to provide some guidelines on what to consider when thinking about extensions to RTP and RTCP 🎀

5. Guidelines ✨

okay bestie, this section is basically the "before you start coding, read this" list 🎀 designing RTCP extensions takes a lot of thought and a deep understanding of how RTP mechanisms actually work. tbh a lot is still not covered by RTCP reporting, but quite a bit of functionality is already sitting there ready to use 💅 other mechanisms should probably never become part of the RTP family, even if their equivalents exist in other environments. so here's some guidance to think about when (and before!!) you build an RTCP extension 🫶

first up, a short checklist about whether RTCP is even the right tool 🧚

  • check what you can already do with the existing mechanisms, using the info RTCP already gives you. is the need only perceived (lazy implementers, or fake constraints in endpoints)? or is the function or data genuinely not available, or derivable from existing reports? 🙈 redundant info is risky because it can become inconsistent at some point, and different implementations might handle that differently (like giving precedence to different values). also, there should be exactly one well-specified way to do every function and operation of the protocol 💜
  • is the extension for RTP entities running anywhere on the Internet, or is it specific to a link or environment? for the second kind, local extensions (like header compression, or non-RTP protocols) may be the better pick 🌸 RTCP should not be used to carry info specific to a particular (access) link.
  • is the extension useful in a group communication environment, or only point-to-point? RTP and RTCP are inherently group protocols, so extensions must scale gracefully as groups get bigger 👑

next, the big conceptual questions every designer should ask (and ANSWER, periodt) 🔥

  • how will this new building block work with the other parts of RTCP? are all the interactions fully specified? 💅
  • will this extension work with all the different profiles, like the Secure RTP profile [RFC3711] and the extended RTP profile for RTCP-based feedback [RFC4585]? are any feature interactions expected? 🦋
  • should this stay in line with baseline RTP and its existing profiles, or does it stray so far that an incompatible new profile has to be defined? 😭 using and defining incompatible profiles is strongly discouraged, but if you really need them, how do nodes on different profiles talk to each other? what are the failure modes, and how do you make sure the system fails safely? 💀
  • how does the extension interoperate with other nodes when the peers don't understand it? 🍓
  • how will it handle different networking conditions? like, how does performance degrade as losses and latency go up, possibly across orders of magnitude? ✨
  • how will it work with group scenarios like multicast? will it degrade gracefully as group sizes grow? what happens to RTCP report frequency and bitrate allocation? 🌈

now the specific design considerations. these are a mix of general protocol design advice and RTCP-specific stuff 💖

  • if there's a mechanism from a different networking environment (and for RTCP this happens a LOT), don't try to recreate it directly in RTP/RTCP 🙅‍♀️ the Internet is super heterogeneous and often behaves in totally different ways from other network environments. instead, ask what the actual semantics are, and what result the application or user needs to perceive. then design a mechanism that gets that result in a way that works with RTP/RTCP. and don't forget that every mechanism breaks when no packets get through, because the Internet doesn't guarantee connectivity or performance 🥺
  • target reusability. think broader than one use case, and solve the general problem whenever that makes sense. point solutions need a really good motivation before the IETF will even look at them 🧠 so build building blocks when you can, so they can be combined in environments you didn't originally have in mind. where possible, avoid mechanisms tied to specific payload formats, media types, or link and network types 🎀
  • for everything you define (packet format, value, procedure, timer, etc.), define it properly so independent, interoperable implementations can be built. it's not enough that you can implement the feature. it has to be implementable years later by someone who doesn't know the working group discussion or the industry context 📚 fields need to be both generated AND reacted upon, mechanisms need to be implemented, and all of that adds complexity. features that are too complex won't get implemented (correctly) in the first place 😭
  • extensions that define new metrics and parameters should reference existing standards whenever possible, instead of inventing something new or proprietary 🫧
  • not every bit or action has to be signalled explicitly. some info can be inferred from other values or how they change over time. TCP congestion control is a super iconic example of this 👑 so you can sometimes decouple bits on the wire from local actions, which cuts down on overhead 🦋
  • with media streams, reliability can often be "soft" 🌸 instead of building explicit acknowledgements, you can sometimes notice that a hint was received from changed behaviour. like when a requested intra-frame arrives, or the video reference frame changes, or the codec changes 🎬 message semantics should be idempotent, so the same message can be sent repeatedly. hard reliability doesn't scale with group size, and it doesn't degrade gracefully when network performance drops 💅
  • choose the right extension point. depending on what kind of RTCP extension you're building, new data items can travel in several different ways 🧚‍♀️
    • a new RTCP Source Description (SDES) item is right for data that describes the source (or the user behind it), rather than the ongoing media transmission. new SDES items may be registered to carry source description info of general interest (see [RFC3550], Section 15), or the PRIV item ([RFC3550], Section 6.5.8) can be used for proprietary extensions 🔐
    • a new RTCP XR block type is right for new metrics about media transmission or reception quality (see [RFC3611], Section 6.2) 📊
    • new RTP profiles may define a profile-specific extension to RTCP SR and/or RR packets, to give extra feedback (see [RFC3550], Section 6.4.3). it's important to know that while these have low overhead, they are NOT backwards compatible with other profiles 🙈 where compatibility is needed, it's generally better to define a new RTCP XR block or a new RTCP packet type instead 💖
    • new RTCP AVPF (Audio-Visual Profile with Feedback) transport-layer feedback messages should be used for general-purpose feedback that the RTP transport generates and processes. examples include (negative) acknowledgements for particular packets, or requests to limit the transmission rate. this info is meant to be independent of the codec or application in use (see [RFC4585], Sections 6.2 and 9) 🦋
    • new RTCP AVPF payload-specific feedback messages should be used to convey feedback that's specific to a particular media codec, RTP payload format, or category of payload formats. examples include video picture loss indication or reference picture selection, which are useful for lots of video codecs (see [RFC4585], Sections 6.3 and 9) 🎥
    • new RTCP AVPF application layer feedback messages should be used for higher-level feedback, from one application to another, above the level of codecs or transport (see [RFC4585], Sections 6.4 and 9) 🌈
    • a new RTCP application-defined (APP) packet is right for private use by applications that don't need to interoperate with others, or for experimenting before you register a new RTCP packet type ([RFC3550], Section 6.7) 🧪 it is NOT appropriate to define a new RTCP APP packet in a standards document. use one of the other extension points, or define a new RTCP packet type instead 🙅‍♀️
    • finally, new RTCP packet types can be registered with IANA if none of the other RTCP extension points fit (see [RFC3550], Section 15) 👑

and the last bit, the philosophy behind it all 🫶 the RTP framework was designed around the principle of application level framing with integrated layer processing, proposed by Clark and Tennenhouse [ALF]. to use RTP well, extensions and implementations need to follow the same philosophy. it's quite different from a lot of earlier systems in this space, so you really need to understand those differences to make RTP work for you ✨

6. Security Considerations 🔐

okay bestie, this memo doesn't specify any new protocol mechanisms or procedures, so there are no explicit security considerations 🫶 BUT when you're designing RTCP extensions, these points are literally a must-check list 💅

  • Privacy: RTCP extensions, especially new Source Description (SDES) items, can potentially reveal info that end users consider sensitive 😬 Extensions should carefully think about what the info they release could be used for, and should be designed to reveal the minimum amount of extra info needed for them to work correctly 🎀
  • Congestion control: RTCP transmission timers were carefully designed so that the total traffic RTCP generates is a small fraction of the media data rate 🌸 The result is that each individual RTCP reporting interval scales with both the media data rate and the group size. The RTCP timing algorithms have been shown to scale all the way from two-party unicast sessions to groups with tens of thousands of participants, and to handle flash crowds and sudden departures gracefully [TimerRecon] ✨ Proposals that change the RTCP timer algorithms have to be careful to avoid congestion, which could potentially lead to denial of service, across the full range of environments where RTCP gets used 🚨
  • Denial of service: RTCP extensions that change where feedback gets sent need to be carefully designed to prevent denial of service attacks against third-party nodes 💀 When those extensions get signalled, for example in the Session Description Protocol (SDP), this typically needs some form of authentication of the signalling messages (e.g., see the security considerations of [RFC5760]) 🔒

The security considerations of the RTP specification [RFC3550] apply, along with any applicable profile (e.g., [RFC3551]) 💜

7. Acknowledgements 🌷

This document was motivated by many discussions in the AVT WG 🦋 The authors want to acknowledge the active members of the group for providing the inspiration 🫶

8. References 📚

8.1. Normative References

[RFC2198]      Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
               Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
               Parisis, "RTP Payload for Redundant Audio Data",
               RFC 2198, September 1997.

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

[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.

[RFC3556]      Casner, S., "Session Description Protocol (SDP)
               Bandwidth Modifiers for RTP Control Protocol (RTCP)
               Bandwidth", RFC 3556, July 2003.

[RFC3611]      Friedman, T., Caceres, R., and A. Clark, "RTP Control
               Protocol Extended Reports (RTCP XR)", RFC 3611,
               November 2003.

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

[RFC4571]      Lazzaro, J., "Framing Real-time Transport Protocol
               (RTP) and RTP Control Protocol (RTCP) Packets over
               Connection-Oriented Transport", RFC 4571, July 2006.

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

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

[RFC5109]      Li, A., "RTP Payload Format for Generic Forward Error
               Correction", RFC 5109, December 2007.

[RFC5506]      Johansson, I. and M. Westerlund, "Support for Reduced-
               Size Real-Time Transport Control Protocol (RTCP):
               Opportunities and Consequences", RFC 5506, April 2009.

8.2. Informative References

[RFC1925]      Callon, R., "The Twelve Networking Truths", RFC 1925,
               April 1996.

[RFC5117]      Westerlund, M. and S. Wenger, "RTP Topologies",
               RFC 5117, January 2008.

[RFC5760]      Ott, J., Chesterfield, J., and E. Schooler, "RTP
               Control Protocol (RTCP) Extensions for Single-Source
               Multicast Sessions with Unicast Feedback", RFC 5760,
               February 2010.

[RFC5761]      Perkins, C. and M. Westerlund, "Multiplexing RTP Data
               and Control Packets on a Single Port", RFC 5761,
               April 2010.

[RFC5762]      Perkins, C., "RTP and the Datagram Congestion Control
               Protocol (DCCP)", RFC 5762, April 2010.

[ALF]          Clark, D. and D. Tennenhouse, "Architectural
               Considerations for a New Generation of Protocols",
               Proceedings of ACM SIGCOMM 1990, September 1990.

[TimerRecon]   Schulzrinne, H. and J. Rosenberg, "Timer
               Reconsideration for Enhanced RTP Scalability",
               Proceedings of IEEE Infocom 1998, March 1998.

Authors' Addresses 💌

Joerg Ott
Aalto University
School of Science and Technology
Otakaari 5 A
Espoo, FIN  02150
Finland

EMail: jo@netlab.tkk.fi


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

EMail: csp@csperkins.org
📦 where this page comes from