RFC 8079

Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs)

📅 published February 2017, from ietf

RFC 8079: Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs) 🎀

Okay bestie, let's get into RFC 8079 💅. It's an IETF document from February 2017, and it's on the Standards Track 🔥. The authors are L. Miniero from Meetecho, S. Garcia Murillo from Medooze, and V. Pascual from Oracle. It has ISSN 2070-1721. The header doesn't list an Obsoletes or Updates line, so it isn't replacing or changing any other RFC. It just stands on its own ✨.

Abstract 🦋

SIP Back-to-Back User Agents (B2BUAs) are often built to sit on the media path too, not just to catch signalling 👀. So they usually end up running an RTP or RTP Control Protocol (RTCP) stack as well, which creates separate multimedia sessions that the B2BUA has to correlate and bridge together. If that isn't handled carefully, the call experience can get wrecked 💀, especially when the statistics and feedback in RTCP messages go missing because the reported data doesn't match up.

This document defines how B2BUAs should behave when they're acting on both the signalling plane and the media plane, so that RTCP keeps working end to end 🫶.

Status of This Memo 🌸

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841.

Info about the current status of this document, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc8079 🔗.

Copyright Notice 🍓

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, since they spell out your rights and restrictions for this document. 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 without warranty, as the Simplified BSD License describes 📜.

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Signalling/Media Plane B2BUAs . . . . . . . . . . . . . . . .   4
  3.1.  Media Relay . . . . . . . . . . . . . . . . . . . . . . .   5
  3.2.  Media-Aware Relay . . . . . . . . . . . . . . . . . . . .   6
  3.3.  Media Terminator  . . . . . . . . . . . . . . . . . . . .  11
4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
  6.2.  Informative References  . . . . . . . . . . . . . . . . .  14
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  15
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1. Introduction ✨

Okay so, Session Initiation Protocol (SIP) [RFC3261] Back-to-Back User Agents (B2BUAs) are SIP entities that can act as a combo of a User Agent Server (UAS) and a User Agent Client (UAC) 🧩. Because of that, they don't always follow the standards perfectly, and it can get messy in unexpected ways 🙈. [RFC7092] is a taxonomy of the most commonly deployed B2BUA implementations, and it explains how they differ in the features and functionality they offer 💖.

These components usually don't just touch the signalling plane (catching and sometimes changing SIP messages). They also get into the media plane 🎧. That means that to receive and manage all the RTP and RTCP [RFC3550] packets in a session, they also end up manipulating the session descriptions [RFC4566] in the related offer/answer exchanges [RFC3264]. The reasons vary. A B2BUA might want to provide transcoding for participants with incompatible codecs, or it might need the traffic handled directly for other reasons 🤷‍♀️. This can lead to several different topologies for RTP-based communication, as documented in [RFC7667] 🗺️.

Here's the catch, though. Whenever a media-aware component sits between two or more participants who want to talk over RTP/RTCP, the end-to-end nature of those protocols gets broken 😭. RTP packets can be relayed pretty easily, so that part might be fine. RTCP is where it gets serious, because RTCP carries important information and feedback about the communication quality the participants are experiencing 🚨. Take the simple scenario with two participants and a single RTP session in Figure 1 👀:

+--------+              +---------+              +---------+
|        |=== SSRC1 ===>|         |=== SSRC3 ===>|         |
| Alice  |              |  B2BUA  |              |   Bob   |
|        |<=== SSRC2 ===|         |<=== SSRC4 ===|         |
+--------+              +---------+              +---------+

                 Figure 1: B2BUA Modifying RTP Headers

In this very common setup, Alice is talking to Bob because a signalling session was set up by a B2BUA. That B2BUA is also on the media path between them, acting as a Media Relay 🔁. So two separate RTP sessions are involved, one per side, and each one carries two RTP streams, one for each media direction. The B2BUA also rewrites some of the RTP header information as it goes 🪄. In this example, only the Synchronization Source (SSRC) of the incoming RTP streams gets changed, but other info could be modified too, like sequence numbers, timestamps, and so on. Specifically, whenever Alice sends an RTP packet, she puts her SSRC (SSRC1) in the RTP header of her source stream. The B2BUA rewrites that to SSRC3 before relaying the packet to Bob. At the same time, RTP packets from Bob (SSRC4) get their SSRC rewritten to SSRC2 before going to Alice 💫.

Now say Alice needs to tell Bob she's lost a bunch of packets in the last few seconds 😩. She'll put the SSRC of the received RTP stream she knows about (SSRC2) together with her own (SSRC1) in RTCP Reports and/or NACKs. Since the B2BUA uses different SSRCs for the RTP streams in each RTP session it set up with each participant, blindly relaying Alice's incoming RTCP messages to Bob causes problems ⚠️. Those RTCP messages reference SSRCs that Bob doesn't know about, so precious feedback gets dropped 🥲. Bob only knows SSRC4 (the one his source stream uses) and SSRC3 (the one he gets from the B2BUA in the stream he receives). He knows nothing about SSRC1 and SSRC2, even though they show up in the messages he got. That dropped feedback can hold important stuff about packet loss, congestion, and other network issues. If he can't take it into account, things can go very wrong 💔. For example, Bob might flood Alice with more media packets than she can handle, or he might not retransmit the packets she missed and asked for. That can easily make the call a really bad experience, and in the worst case it could end the communication entirely 📴.

This is just a simple example, and more scenarios get covered in the following sections 🧚‍♀️. Still, it shows how a small mishandling of important information can have serious consequences 😤. It gets even more intense with bigger setups, like several participants at once, multiple RTP sessions (say, a video stream alongside audio), redundancy RTP streams, SSRC multiplexing, and more 🌈. B2BUA deployments are super common, so it really matters that they handle RTCP messages properly. That way their activity on the media plane doesn't break or interfere with anything that matters to the session 👑.

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] 🔑.

On top of that, this document uses the RTP-related terminology defined in [RFC7656] wherever it's relevant 🎀.

3. Signalling/Media Plane B2BUAs 🦋

As we covered in the Introduction (Section 1), it's super common for B2BUA deployments to act on the media plane, not just the signalling plane 🎧. [RFC7092] describes three categories of these B2BUAs 🗂️:

A simple Media Relay that's basically unaware of anything it transports 📦.
A Media-aware Relay that inspects and/or modifies RTP and RTCP messages as they flow by 🔍.
A full-fledged media termination entity that terminates and generates RTP and RTCP messages as needed 🧠.

[RFC3550] and [RFC7667] already set out some specific behaviours for certain topologies 📐. But because B2BUAs are such a mixed bag, they sometimes can't or won't implement every relevant specification 😬. That means it's pretty common to run into issues that could've been avoided with more disciplined behaviour. Those issues would be much less likely if B2BUAs followed at least a set of guidelines that make sure no known problems happen 🛠️. So the subsections below describe the behaviour that B2BUAs should follow, whichever category they fall into, so they don't hurt the end-to-end effectiveness of RTCP 💜.

3.1. Media Relay 🎀

Okay so a Media Relay, the one [RFC7092] talks about, just forwards every RTP and RTCP message it gets without peeking inside or changing anything 💅. In the "RTP Topologies" [RFC7667] lingo, this is basically an RTP Transport Translator ✨. So B2BUAs acting as Media Relays have no clue what traffic they're handling 🙈. Both the packet payloads and the packet headers are opaque to them. Lots of Session Border Controllers (SBCs) do this, like when they're bridging an inner network and an outer network 🌸.

Since every header and identifier in RTP and RTCP stays untouched, the SSRC mismatch from the last section can't happen. But similar problems can still pop off for other reasons 😭. For example, the session description the B2BUA prepares, whether it was modified or not, might end up giving wrong info. That could happen if the Session Description Protocol (SDP) on either side has 'ssrc' [RFC5576] attributes that don't match the SSRC actually being advertised on the media plane. It could also happen if the B2BUA says it supports NACK because it implements it, even though the original INVITE didn't 🙃. This is most likely when the Media Relay B2BUA generates a brand-new session description while bridging an incoming call, instead of using the original one. The result is participants spotting a mismatch between the SSRCs in the SDP and the ones they actually see in RTP and RTCP messages. They might also ignore RTCP feedback packets that were never advertised as supported, or go ahead and generate them anyway 💀.

To stop this, a Media Relay B2BUA SHOULD forward all the SSRC- and RTCP-related SDP attributes when it handles a multimedia session setup between participants. That covers attributes like 'ssrc' [RFC3261], 'rtcp-fb' [RFC4585], 'rtcp-xr-attrib' [RFC3611], and others 🦋. But some SDP attributes can cause call failures when a Media Relay forwards them, because they quietly assume the attribute describes the immediate peer. A clear example is the 'rtcp' [RFC3605] attribute, which describes the expected RTCP peer port. Other attributes might include the immediate peer's IP address, the preferred transport, and so on. The overall rule is to rewrite attributes that implicitly describe the immediate peer. B2BUAs SHOULD forward all other SDP attributes so they don't break extra functionality that endpoints might be relying on 🧚. If implementors aren't sure whether this guidance applies to a specific attribute, they should test it to see if call failures happen 🍓.

The 'rtcp' example also matters whenever RTP/RTCP multiplexing [RFC5761] support is being negotiated. If the B2BUA acting as a Media Relay doesn't understand the traffic it's handling, and might not have RTP/RTCP parsing capabilities, it SHOULD reject RTP/RTCP multiplexing by removing the 'rtcp-mux' SDP attribute. But if the Media Relay can parse RTP/RTCP and verify that demultiplexing works without any RTP Payload Type rewrites (meaning no overlap between any RTP Payload Types and the RTCP Payload Type space has been detected), then the B2BUA SHOULD negotiate RTP/RTCP multiplexing support if it's advertised 🔥.

Also, by leaving RTCP messages untouched, a Media Relay may leak information that policies say should be hidden or masqueraded, like domain names in CNAME items 👀. These CNAME items may even contain IP addresses. That means if a NAT is involved, you can get CNAME collisions, which could really break the end-to-end RTCP behaviour 😱. [RFC7022] can prevent this, but some implementations don't use it. So a B2BUA MAY rewrite CNAME items if any potential collision is detected, even in the Media Relay case. If a B2BUA does decide to rewrite CNAME items, it MUST generate new CNAMEs following [RFC7022]. The same SHOULD be done if RTP extensions involving CNAMEs are in play, like urn:ietf:params:rtp-hdrext:sdes:cname [RFC7941] ✨. And if that isn't possible, say because the Media Relay doesn't have RTP header editing capabilities or doesn't support these extensions, then the B2BUA MUST reject the negotiation of those extensions when it negotiates the session 🚫.

3.2. Media-Aware Relay 🦋

A Media-aware Relay is different from the Media Relay in the previous section, because it's aware of the media traffic it's handling 👑. It inspects the RTP and RTCP messages flowing by and may even modify their headers. In [RFC3550] terms, this is an RTP Translator. A B2BUA in this role usually doesn't inspect the RTP payloads, which stay opaque to it. So the actual media isn't manipulated, meaning no transcoding 💜.

That makes these guys really different from the Media Relays we just covered, especially when it comes to RTCP issues 😤. Since they can modify RTP and RTCP headers, these B2BUAs might change RTP-related info like the SSRC / Contributing Source (CSRC), sequence numbers, timestamps, and more, before they forward the modified packets to the other participants. So if it isn't handled carefully, this can easily lead to the kind of issue described in the introduction 💀. That's why it's super important for a B2BUA that modifies RTP-related info across two related RTP streams to also modify the same info in RTCP messages, in a coherent way 🫶.

Also, a B2BUA like this doesn't necessarily forward every packet it gets. Selective Forwarding Units (SFUs) [RFC7667], for example, may aggregate or drop incoming RTCP messages while also originating new ones on their own 🌈. To be clear, a B2BUA SHOULD NOT randomly drop or forward RTCP feedback of the same type (like a specific XR block type or specific Feedback messages) within the same session. That can lead to confusing, if not broken, feedback for the recipients because of gaps in the communication 😭. As for the messages that do get forwarded and/or aggregated, it's important to make sure the information stays coherent ✨.

Besides the behaviour already required for RTCP translators in Section 7.2 of [RFC3550], a media-aware B2BUA MUST handle incoming RTCP messages to forward following these guidelines 💅:

Sender Report (SR) [RFC3550]: If the B2BUA has changed the SSRC of the sender RTP stream a Sender Report refers to, it MUST update the SSRC in the SR packet header as well. If the B2BUA has changed the SSRCs of other RTP streams too, and any of those streams are addressed in any of the SR Report Blocks, it MUST update the related values in the SR Report Blocks as well. If the B2BUA has also changed the base RTP sequence number when forwarding RTP packets, then this change MUST be reflected in the 'extended highest sequence number received' field in the Report Blocks. And if the B2BUA is acting as a Selective Forwarding Unit (SFU) [RFC7667], it needs to track, in the outgoing SR, the relevant number of packets sent and the total number of bytes sent to the receiver 📊.

Receiver Report (RR) [RFC3550]: The guidelines for SR apply to RR as well 🔁.

Source Description (SDES) [RFC3550]: If the B2BUA has changed the SSRC of any RTP stream addressed in any of the chunks of an incoming SDES message, it MUST update the related SSRCs in all the chunks. The same CNAME collision considerations from the end of Section 3.1 apply here too 🙈.

BYE [RFC3550]: If the B2BUA has changed the SSRC of any RTP stream addressed in the SSRC/CSRC identifiers included in a BYE packet, it MUST update them in the message 👋.

APP [RFC3550]: If the B2BUA has changed the SSRC of any RTP stream addressed in the header of an APP packet, it MUST update the identifier in the message. Should the B2BUA be aware of any specific APP message format that contains additional SSRC-related information, it SHOULD update that information accordingly as well 🧚.

Extended Reports (XRs) [RFC3611]: If the B2BUA has changed the SSRC of the RTP stream associated with the originator of an XR packet, it MUST update the SSRC in the XR message header. The same guidelines given for SR/RR, regarding SSRC identifiers in Report Blocks, apply to all the Report Block types in the XR message as well. If the B2BUA has also changed the base RTP sequence number when forwarding RTP packets, then this change MUST be reflected in the begin_seq and end_seq fields, which are available in most of the Report Block types in the XR specification 🌸.

Receiver Summary Information (RSI) [RFC5760]: If the B2BUA has changed any SSRC of RTP streams addressed in an RSI packet, it MUST update the SSRC identifiers in the message. This includes the distribution source SSRC, which MUST be rewritten with the one the B2BUA uses to send RTP packets to each sender participant, the summarized SSRC, and, when a Collision Sub-Report Block is available, the SSRCs in the related list 🍓.

Port Mapping (TOKEN) [RFC6284]: If the B2BUA has changed any SSRC of RTP streams addressed in a TOKEN packet, it MUST update the SSRC identifiers in the message. This includes the Packet Sender SSRC, which MUST be rewritten with the one the B2BUA uses to send RTP packets to each sender participant, and the Requesting Client SSRC when the message is a response, which MUST be rewritten using the related sender participant(s) SSRC 🗺️.

Feedback Messages [RFC4585]: All Feedback messages share a common packet format, which includes the SSRC identifier of the Packet Sender and the SSRC identifier of the media source the feedback relates to. Just like the previous messages, these SSRC identifiers MUST be updated in the message if the B2BUA has changed the SSRC of the RTP streams addressed there. It MUST NOT, however, change a media source SSRC that was originally set to zero, unless zero is actually the SSRC one of the involved endpoints chose, in which case the SSRC rewriting rules above apply 🤓. Since many Feedback messages also include extra data in their specific Feedback Control Information (FCI), a media-aware B2BUA MUST take care of that data accordingly, if it can parse and regenerate it, following these guidelines 🌟:

NACK [RFC4585]: A media-aware B2BUA MUST properly rewrite the Packet ID (PID) of all addressed lost packets in the NACK FCI if it changed the RTP sequence numbers 🎯.
TMMBR/TMMBN/FIR/TSTR/TSTN/VBCM [RFC5104]: A media-aware B2BUA MUST properly rewrite the additional SSRC identifier in the specific FCI if it changed the related RTP SSRC of the media sender 💖.

Receiver Estimated Max Bitrate (REMB) [RTCP-REMB]: okay so [RTCP-REMB] describes an RTCP payload-specific Feedback message that reports the receiver's available bandwidth back to the sender 📡. As of the time of this writing, REMB is widely deployed but has not been standardized 🙈. The REMB mechanism will not function correctly across a media-aware B2BUA that changes the SSRC of the media sender, unless it also changes the SSRC values in the REMB packet 💀.

Explicit Congestion Notification (ECN) [RFC6679]: the same guidelines for SR/RR management apply here, since the ECN Feedback Report format has sequence numbers too 🔢. For RTCP XR ECN Summary Report messages, the same guidelines for generic XR messages apply 🦋.

Apart from the generic guidelines for Feedback messages, no additional modifications are needed for Picture Loss Indication (PLI), Slice Lost Indication (SLI), and Reference Picture Selection Indication (RPSI) Feedback messages 🎀. Honestly, these ones are chill and need nothing extra ✨.

Of course, the same need for SDP and RTP/RTCP information to be coherent applies to media-aware B2BUAs 💅. This means that, if a B2BUA changes any SSRC, it MUST update the related ssrc attributes, if present, before sending it to the recipient 🫶. Besides, it MUST rewrite the rtcp attribute if provided 🌸. At the same time, while a media-aware B2BUA is typically able to inspect/modify RTCP messages, it may not support all RTCP messages 🙈. This means that a B2BUA may choose to drop RTCP messages it can't parse 🗑️. In that case, a media-aware B2BUA MUST advertise its RTCP level of support in the SDP in a coherent way, so that it can prevent, for instance, a UAC from sending NACK messages that would never reach the intended recipients 😭. It's important to point out that, if a compound RTCP packet was received and any RTCP message in it needs to be dropped, then the B2BUA SHOULD NOT drop the whole compound RTCP packet, but only the selected messages 🧚.

The same considerations on CNAMEs made for Media Relays apply to Media-aware Relays as well 🍓. Specifically, if RTP extensions involving CNAMEs are involved (e.g., urn:ietf:params:rtp-hdrext:sdes:cname [RFC7941]) and negotiated because the B2BUA supports them, then the B2BUA MUST update the CNAME value in there as well, if it was changed 💜. It is worth pointing out that, if the new CNAME is larger than the old one, this would result in a larger RTP packet than originally received 📦. If the length of the updated packet exceeds the MTU of any of the networks the packet will traverse, this can result in the packet being dropped and lost by the recipient 💀.

A different set of considerations is worthwhile for RTP/RTCP multiplexing [RFC5761] and Reduced-Size RTCP [RFC5506] 👑. The former allows for a better management of network resources by multiplexing RTP packets and RTCP messages over the same transport 🔥, while the latter compresses RTCP messages, which leads to less network traffic 🌈. For RTP/RTCP multiplexing, a B2BUA acting as a Media Relay may use it on either RTP session independently 🦋. This means that, for instance, a Media Relay B2BUA may use RTP/RTCP multiplexing on one side of the communication and not use it on the other side, if that endpoint does not support it 🙌. This allows for a better management of network resources on the side that does support it ✨. In case any of the parties in the communication supports it and the B2BUA does too, the related rtcp-mux SDP attribute MUST be forwarded on the other side(s) 💖. If the B2BUA detects that any of the parties in the communication do not support the feature, it may decide to either disable it entirely or still advertise it for the RTP sessions with parties that do support it 🤷‍♀️. In case the B2BUA decides to involve RTP/RTCP multiplexing, it MUST ensure that there are no conflicting RTP Payload Type numbers on either side 🎯. When there are, it MUST rewrite RTP Payload Type numbers to prevent conflicts in the session where RTP/RTCP multiplexing is applied 🔁. Should RTP Payload Types be rewritten, the related information in the SDP MUST be updated accordingly 📝.

For Reduced-Size RTCP, the vibe is a bit different 🙃. While a Media Relay B2BUA may choose to use it on the side that supports it and not on the side that doesn't, there are several reasons for discouraging that behaviour 🚫. Reduced-Size allows for less RTCP traffic in general, but this gain may lead a Reduced-Size RTCP implementation to also issue a higher rate of RTCP Feedback messages 📈. That would mean more RTCP traffic on the side that does not support Reduced-Size, which could actually be counterproductive if the available bandwidth is different on the two sides 😬. Negotiating a session with both sides would let the B2BUA discover which side supports Reduced-Size and which doesn't, so it can decide whether or not to let the sides use it independently 🕵️‍♀️. If the B2BUA decides to disable the feature on all sides, which is suggested in case Reduced-Size is not supported by all parties involved, it MUST NOT advertise support for Reduced-Size RTCP functionality on either side, by removing the rtcp-rsize attribute from the SDP 🚫💅.

3.3. Media Terminator

A Media Terminator B2BUA is giving main character energy, because unlike simple Media Relays and media-aware ones, it is able to terminate media itself 👑. As such, it can inspect and/or modify RTP payloads as well 🧠. This means such components can, for instance, act as media transcoders and/or originate specific RTP media 🎬. Using the terminology in "RTP Topologies" [RFC7667], this can be seen as an RTP Media Translator 🌍. Such a topology can also be seen as a back-to-back RTP session through a middlebox, as described in Section 3.2.2 of [RFC7667] 🪞. This capability makes them quite different from the previously introduced B2BUA typologies 🦄. Since such a B2BUA would terminate RTP itself, it can take care of the related statistics and feedback functionality directly, with no need to simply relay any message between the participants in the multimedia session 🫧.

For this reason, no specific guideline is needed to ensure proper end-to-end RTCP behaviour in such scenarios, because most of the time there would be no end-to-end RTCP interaction among the participants in the first place 🙌. Nevertheless, should any RTCP message actually need to be forwarded to another participant in the multimedia session, the same guidelines provided for the media-aware B2BUA case apply 📨.

For RTP/RTCP multiplexing support, the same considerations already given for Media Relay management also apply to Media Terminators 💜.

Some different considerations might apply to Reduced-Size RTCP, though 🌷. In the Media Terminator case, it is safe to use the feature independently on each side, since the B2BUA would terminate RTCP 🦋. In that case, the B2BUA SHOULD advertise and negotiate support for Reduced-Size if available, and MUST NOT otherwise 🎀.

4. IANA Considerations ✨

This document does not require any IANA actions 🌸.

5. Security Considerations 💀

Okay, this section is serious, bestie 😭. The discussion in the previous sections on managing RTCP messages through a B2BUA assumed that the B2BUA has actual access to the RTP/RTCP information itself 🔐. That's true if we assume plain RTP and RTCP are being handled, but it may not be true once any security is enforced on RTP packets and RTCP messages by means of Secure RTP (SRTP) [RFC3711] 🚨.

This is typically not an issue in the Media Relay case, where RTP and RTCP packets are forwarded without modification, regardless of whether security is involved 🙆‍♀️. It could definitely have an impact on Media-aware Relays and Media Terminator B2BUAs, though 😱. As a simple example, imagine an SRTP / Secure RTCP (SRTCP) session across a B2BUA where the B2BUA itself has no access to the keys used to secure the session 🔑. There would be no way to manipulate SRTP headers without violating the hashing on the packet 🙅‍♀️. At the same time, there would be no way to rewrite the RTCP information accordingly either 💔.

So it's important to point out that the operations described in the previous sections are only possible if the B2BUA has a way to effectively manipulate the packets and messages flowing by 🧩. This means that, when media security is involved, only the Media Relay scenario can be properly addressed 🛡️. Trying to cover Media-aware Relay and Media Termination scenarios with secure sessions will inevitably lead to the B2BUA acting as a man in the middle, so its behaviour is unspecified and discouraged 🚩. More considerations on this are provided in [RFC7879] 📚.

It is also worth pointing out that there are scenarios where improper management of RTCP messaging across a B2BUA may lead, willingly or not, to situations not unlike an attack 👀. As a simple example, improper management of a REMB Feedback message containing, e.g., information on the limited bandwidth available to a user may lead to missing or misleading information for its peer 📉. This may cause the peer to increase the encoder bitrate, maybe up to a point where a user with poor connectivity will inevitably be choked by an amount of data it cannot process 🥀. This scenario may thus result in what looks like a Denial-of-Service (DoS) attack towards that user 🚨💀.

6. References 📚

6.1. Normative References 📚✨

Okay bestie, these are the references the spec leans on hardest, so no skipping 🫶

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.

[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <http://www.rfc-editor.org/info/rfc3611>.

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.

[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, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.

[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>.

[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences", RFC 5506, DOI 10.17487/RFC5506, April 2009, <http://www.rfc-editor.org/info/rfc5506>.

[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback", RFC 5760, DOI 10.17487/RFC5760, February 2010, <http://www.rfc-editor.org/info/rfc5760>.

[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>.

[RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping between Unicast and Multicast RTP Sessions", RFC 6284, DOI 10.17487/RFC6284, June 2011, <http://www.rfc-editor.org/info/rfc6284>.

[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 2012, <http://www.rfc-editor.org/info/rfc6679>.

[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, <http://www.rfc-editor.org/info/rfc7022>.

[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <http://www.rfc-editor.org/info/rfc7656>.

[RFC7941] Westerlund, M., Burman, B., Even, R., and M. Zanaty, "RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items", RFC 7941, DOI 10.17487/RFC7941, August 2016, <http://www.rfc-editor.org/info/rfc7941>.

6.2. Informative References 🦋

These are the extra-helpful reads, the ones that give you the backstory and the vibes 🌸

[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, <http://www.rfc-editor.org/info/rfc3605>.

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.

[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <http://www.rfc-editor.org/info/rfc5576>.

[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013, <http://www.rfc-editor.org/info/rfc7092>.

[RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015, <http://www.rfc-editor.org/info/rfc7667>.

[RFC7879] Ravindranath, R., Reddy, T., Salgueiro, G., Pascual, V., and P. Ravindran, "DTLS-SRTP Handling in SIP Back-to-Back User Agents", RFC 7879, DOI 10.17487/RFC7879, May 2016, <http://www.rfc-editor.org/info/rfc7879>.

[RTCP-REMB] Alvestrand, H., Ed., "RTCP message for Receiver Estimated Maximum Bitrate", Work in Progress, draft-alvestrand-rmcat-remb-03, October 2013.

Acknowledgements 🙌

The authors want to give a huge shoutout to Flavio Battimo and Pierluigi Palma for their invaluable feedback in the early stages of this document. 💖

They also want to thank Colin Perkins, Bernard Aboba, Albrecht Schwarz, Hadriel Kaplan, Keith Drage, Jonathan Lennox, Stephen Farrell, Magnus Westerlund, Simon Perreault, and Ben Campbell for their constructive comments, suggestions, and reviews. Those were genuinely critical to shaping this document into what it is ✨

Authors' Addresses 💌

Lorenzo Miniero Meetecho Email: lorenzo@meetecho.com

Sergio Garcia Murillo Medooze Email: sergio.garcia.murillo@gmail.com

Victor Pascual Oracle Email: victor.pascual.avila@oracle.com

📦 where this page comes from

ietf: rfc8079 2017-02
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms