RFC 7941

RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items

📅 published August 2016, from ietf

Part 1 of 4. More parts are coming, bestie! 🎀

RFC 7941: RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items ✨

Okay, so this one is from the IETF (Internet Engineering Task Force) 🌸 and it's dated August 2016. It's a Standards Track document, which means it's a real Internet standard and not just a vibe. The authors are M. Westerlund, B. Burman (Ericsson), R. Even (Huawei Technologies), and M. Zanaty (Cisco Systems). The ISSN is 2070-1721. The title block doesn't list anything this RFC obsoletes or updates, so there's nothing to chase there. 💅

Abstract 🫶

Source Description (SDES) items usually travel in the RTP Control Protocol (RTCP), but sometimes it's way better to get them to receivers faster 🚀. The big example is when a new synchronization source (SSRC) joins an RTP session. Receivers need to know who this source is, how it relates to other sources, or its synchronization context, and SDES items can fully or partially tell them all of that. To make this speedy, this doc defines a new RTP header extension that can carry SDES items. ⚡

Status of This Memo 📜

This is an Internet Standards Track document. 🌈

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. You can read more about Internet Standards in 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/rfc7941. 🦋

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
  2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
  2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   4
4.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   5
  4.1.  SDES Item Header Extension  . . . . . . . . . . . . . . .   5
    4.1.1.  One-Byte Format . . . . . . . . . . . . . . . . . . .   6
    4.1.2.  Two-Byte Format . . . . . . . . . . . . . . . . . . .   6
  4.2.  Usage of the SDES Item Header Extension . . . . . . . . .   6
    4.2.1.  One-Byte or Two-Byte Headers  . . . . . . . . . . . .   6
    4.2.2.  MTU and Packet Expansion  . . . . . . . . . . . . . .   7
    4.2.3.  Transmission Considerations . . . . . . . . . . . . .   8
    4.2.4.  Different Usages  . . . . . . . . . . . . . . . . . .   9
    4.2.5.  SDES Items in RTCP  . . . . . . . . . . . . . . . . .  10
    4.2.6.  Update Flaps  . . . . . . . . . . . . . . . . . . . .  10
    4.2.7.  RTP Header Compression  . . . . . . . . . . . . . . .  11
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
  5.1.  Registration of an SDES Base URN  . . . . . . . . . . . .  11
  5.2.  Creation of the "RTP SDES Compact Header Extensions"
        Sub-Registry  . . . . . . . . . . . . . . . . . . . . . .  12
  5.3.  Registration of SDES Item . . . . . . . . . . . . . . . .  12
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction 🌸

This spec defines an RTP header extension [RFC3550][RFC5285] that can carry RTCP Source Description (SDES) items. Normally, SDES items ride in their own RTCP packet type [RFC3550]. By putting selected SDES items into a header extension, we can speed up how receivers figure out the relationship and synchronization context for new RTP streams (SSRCs) in an RTP session. Which relationship and what info you get depends on which SDES items are carried. This is a complement to using only RTCP for SDES delivery, so it's not replacing anything 🫶.

Not every SDES item is a good fit for header extensions, so pay attention here 👀. Some SDES items handle binding or identify synchronization contexts and have strict timeliness requirements, while lots of other items don't. Security and privacy also matter for SDES item info. For example, the Name and Location items are super sensitive from a privacy angle and should not be transported over the network without strong security 🔒. No use case has shown that this info is needed the moment the first RTP packets arrive, and a delay of a few seconds before the receiver has it seems fine 🙆. So only appropriate items, like CNAME, get registered for use with this header extension. 💅

Requirements language and terminology are defined in Section 2. Section 3 explains why this header extension is sometimes required, or at least gives a big improvement over waiting for the regular RTCP packets to carry the info. Section 4 specifies the header extension and gives usage recommendations. Section 5 defines a subspace of the header extension URN for existing and future SDES items, and it registers the existing SDES items that apply. 🦋

2. Definitions 📖

2.1. Requirements Language

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 RFC 2119 [RFC2119]. 🧠

2.2. Terminology 🏷️

This document uses terminology defined in "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources" [RFC7656]. These are the specific terms it uses:

  • Media Source
  • RTP Stream
  • Media Encoder
  • Participant

3. Motivation 🧚

SDES items are tied to a particular SSRC and therefore to a particular RTP stream. The Source Description items carry various metadata about that SSRC. How soon you need that data, like by the first RTP packet, depends on the item. The CNAME item is the one that's commonly needed either when the first RTP packet for this SSRC arrives, or at least by the time the first media can be played out. Without it, the synchronization context can't be determined, so related streams can't be synchronized correctly. That makes CNAME a great example of why having this info early is valuable when a new RTP stream shows up 🎶.

New SSRCs in an RTP session mostly show up when media sources get added. That can happen because an endpoint adds a new actual media source, or because more participants join a multi-party session. Another reason for a new SSRC is an SSRC collision, which forces both colliding parties to pick new SSRCs 💥.

For rapid media synchronization, you can use the RTP header extension for rapid synchronization of RTP flows [RFC6051]. That extension carries the clock info found in RTCP sender report (SR) packets. The catch is that it assumes the CNAME binding is already known, and that can be provided via signaling [RFC5576] in some cases but not all of them 😩. So an RTP header extension that carries SDES items like CNAME is a powerful combo, and it makes rapid synchronization work in all cases ⚡.

The "Rapid Synchronisation of RTP Flows" spec [RFC6051] does analyze the initial synchronization delay for different sessions, depending on the number of receivers and the session bandwidth (Section 2.1 of [RFC6051]). Those results also apply to other SDES items with a similar time dependency until the info can be sent over RTCP. You can use these figures to work out how much you'd gain by cutting the initial delay before info is available for some use cases 📊.

[RFC6051] also covers late joiners and defines an RTCP Feedback format to request synchronization info. That's another potential use case for SDES items in the RTP header extension. For example, it would be natural to include a CNAME SDES item with the header extension that carries the NTP-formatted reference clock, so synchronization is guaranteed 🕰️.

The ongoing work on bundling Session Description Protocol (SDP) media descriptions [SDP-BUNDLE] has identified a new SDES item that benefits from timely delivery. That's why a matching RTP SDES compact header extension is also defined and registered in that document:

  • MID: This is a media description identifier that matches the value of the SDP [RFC4566] a=mid attribute [RFC5888], so RTP streams multiplexed on the same transport can be associated with their respective SDP media description. 🎀

4. Specification 💖

This section first specifies the SDES item RTP header extension format, then covers some usage considerations.

4.1. SDES Item Header Extension 🦄

An RTP header extension scheme that allows multiple extensions is defined in "A General Mechanism for RTP Header Extensions" [RFC5285]. That spec defines both short and long item headers. Short headers (one byte) are limited to 1 to 16 bytes of data, while the long format (two bytes) supports a data length of 0 to 255 bytes. So from a data length perspective, the RTP header extension formats can support any SDES item, which is honestly iconic 👑.

The ID field, whether it's the short or long format, identifies both the type of RTP header extension and, for the SDES item header extension, the type of SDES item. The mapping happens in signaling, where the header extension and SDES item type are identified using a URN. The URN is defined in Section 5 ("IANA Considerations") for the known SDES items that are appropriate to use. 🧩

4.1.1. One-Byte Format ✨

okay so the one-byte header for an SDES item extension element is the one-byte header from Section 4.2 of [RFC5285] 💖 it's a 4-bit ID followed by a 4-bit len field, and len tells you how many data bytes come after the header (it's the len value plus one, so there's always at least one byte). The data part is len+1 bytes of UTF-8 [RFC3629] text. Which type of text it is, and which SDES item it maps to, is decided by the ID value 🦋

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ID   |  len  | SDES item text value ...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1

4.1.2. Two-Byte Format 🌸

the two-byte version is the two-byte header from Section 4.3 of [RFC5285] 🎀 it's an 8-bit ID followed by an 8-bit len field that tells you how many data bytes follow the header. The data part is len bytes of UTF-8 text. The type of text and its mapping to the SDES item type are, once again, determined by the ID field value 💅

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      ID       |      len      |  SDES item text value ...     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2

4.2. Usage of the SDES Item Header Extension 🧚

this section is all about the usage considerations: which form of the header extension to pick, the packet expansion, and when to actually send SDES items in the header extension 👑

4.2.1. One-Byte or Two-Byte Headers 💜

the RTP header extensions for SDES items MAY use either the one-byte or two-byte header formats 🦋 it depends on the text value size for the SDES items being used and on the requirements of any other header extensions in play. The one-byte header SHOULD be used when all non-SDES item header extensions support the one-byte format and all SDES item text values contain at most 16 bytes. Note that the RTP header extension specification [RFC5285] does not allow mixing one-byte and two-byte headers for the same RTP stream (SSRC), so if any SDES item requires the two-byte header, then all other header extensions MUST also use the two-byte header format 🚫

For example, say you're using CNAMEs generated according to "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" [RFC7022], you're using short-term persistent values, and 96-bit random values before base64 encoding are enough. Then they'll fit into the one-byte header format ✨

An RTP middlebox has to think carefully about one-byte versus two-byte headers when it creates the first packets for an outgoing stream (SSRC) with header extensions 🧠 First, it needs to consider all the header extensions that might potentially be used. Second, it needs to know the size of the SDES items that are going to be included, and use two-byte headers if any of them are longer than 16 bytes. An RTP middlebox that forwards a stream, i.e., one that isn't mixing it or combining it with other streams, may be able to base its choice on the header size in the incoming streams. This assumes the middlebox doesn't modify the stream or add additional header extensions to the stream it sends. If it does, it needs to make its own decision 💖

4.2.2. MTU and Packet Expansion 📦

the RTP packet size is going to clearly increase when a header extension is included 📈 How much depends on the type of header extensions and their data content. SDES items can vary in size, and some use cases need several SDES items in the same packet so all the relevant data reaches the receiver. An example is when a CNAME, a MID, and the rapid time synchronization extension from RFC 6051 are all needed. That combo is quite likely to give at least 16+3+8 bytes of data plus the headers, which adds another 7 bytes for one-byte headers, plus two bytes of header padding to make the complete header extension 32-bit word aligned, so 36 bytes in total 😭

If the packet expansion can't be taken into account when producing the RTP payload, it can cause an issue 🙈 An RTP payload created to meet a particular IP-level Maximum Transmission Unit (MTU), taking the IP/UDP/RTP headers into account but not the RTP header extensions, could exceed the MTU once the header extensions are present, and that results in IP fragmentation. IP fragmentation is known to hurt the loss rate, because some middleboxes are unwilling or unable to deal with IP fragments, and it also increases the target surface for other types of packet losses 💀

This is a real issue, so the media encoder and payload packetizer should be flexible and capable of handling dynamically varying payload size restrictions to counter the packet expansion caused by header extensions. If that isn't possible, some reasonable worst-case packet expansion should be calculated and used to reduce the RTP payload size of all RTP packets the sender transmits 🫶

4.2.3. Transmission Considerations 📬

the general recommendation is to only send header extensions when they're needed 🌷 This is especially true for SDES items that can be sent in periodic repetitions of RTCP throughout the whole session. So the different usages (Section 4.2.4) have different recommendations. Here are some general considerations for getting the header extensions delivered to the receiver:

  1. The probability of packet loss and burst loss determine how many repetitions of the header extensions will be required to reach a targeted delivery probability. If burst loss is likely, they also determine what distribution would be needed to avoid getting all repetitions of the header extensions lost in a single burst.
  2. If a set of packets are all needed to enable decoding, there's commonly no reason to include the header extension in all of them, since they share fate. Instead, at most one instance of the header extension per independently decodable set of media data would be a more efficient use of bandwidth 🧃
  3. How early the SDES item information is needed, whether from the first received RTP data or only after some set of packets have been received, can guide whether the header extension(s) should be in all of the first N packets or included only once per set of packets. For example, once per video frame 🎞️
  4. Use of RTP-level robustness mechanisms, such as RTP retransmission [RFC4588] or forward error correction [RFC5109], may treat packets differently from a robustness perspective. SDES header extensions should be added to packets that get a treatment corresponding to the relative importance of receiving the information 🛡️

As a summary, the number of header extension transmissions should be tailored to a desired probability of delivery, taking the receiver population size into account. For the very basic case, N repetitions of the header extensions should be sufficient, but that may not be optimal 🌈

N is selected so that the header extension target delivery probability reaches 1-P^N, where P is the probability of packet loss. For point-to-point or small receiver populations, it might also be possible to use feedback, such as RTCP, to figure out when the information in the header extensions has reached all receivers and then stop further repetitions 🔁 Feedback that can be used includes the RTCP Extended Report (XR) Loss RLE Report Block [RFC3611], which indicates successful delivery of particular packets. If the RTP/AVPF transport-layer feedback message for generic NACK [RFC4585] is used, it can indicate a failure to deliver an RTP packet with the header extension, which signals the need for further repetitions. The normal RTCP report blocks can also give an indicator of successful delivery, if no losses are indicated for a reporting interval covering the RTP packets with the header extension. Note that losing an RTCP packet reporting on an interval where RTP header extension packets were sent does not necessarily mean the RTP header extension packets themselves were lost 🤔

4.2.4. Different Usages 💅

4.2.4.1. New SSRC 🐣

a new SSRC joins an RTP session 👋 As this SSRC is completely new to everyone, the goal is to ensure, with high probability, that all RTP session participants receive the information in the header extension. So header extension transmission strategies that allow some margin in the delivery probability should be considered 💜

4.2.4.2. Late Joiner 🙋‍♀️

in a multi-party RTP session, one or a small number of receivers may join a session where the majority of receivers already have all the necessary information. In that case, the use of header extensions to deliver relevant information should be tailored to reach the new receivers 🎯 The trigger to send header extensions can be either RTCP from the new receiver(s) or an explicit request, like the Rapid Resynchronization Request defined in [RFC6051]. In centralized topologies where an RTP middlebox is present, it can be responsible for sending the known information, possibly stored, to the new session participant only, and not repeat it to all the session participants 🫧

4.2.4.3. Information Change 🔄

if the SDES information is tightly coupled with the RTP data and the SDES information needs to be updated, then using the RTP header extension is superior to RTCP 👑 Using the RTP header extension ensures the information is updated on reception of the related RTP media, which keeps the two in sync. Continued use of the old SDES information can lead to undesired effects in the application 😬 So header extension transmission strategies with a high probability of delivery should be chosen.

4.2.5. SDES Items in RTCP 🌙

the RTP header extension information, i.e., the SDES items, can and will also be sent in RTCP 🫶 So it's worth reflecting a bit on this interaction. As an alternative to the header extension, it's possible to schedule a non-regular RTCP packet transmission containing important SDES items, if you use an RTP-/AVPF-based RTP profile. Depending on the mode your RTCP feedback transmitter is working in, extra RTCP packets may be sent as immediate or early packets, which enables more timely SDES information delivery ⏰

There are, however, two aspects that differ between using RTP header extensions and any non-regular transmission of RTCP packets 👀 First, because the RTCP packet is a separate packet, there's no direct relation and no fate sharing between the relevant media data and the SDES information. The order of arrival for the packets will matter. With a header extension, the SDES items can be ensured to arrive if the media data to play out arrives 💖 Second, it's difficult to determine whether an RTCP packet is actually delivered, because RTCP packets lack both a sequence number and a mechanism providing feedback on the RTCP packets themselves 🥺

4.2.6. Update Flaps ✨

Okay so bestie, SDES items can show up in BOTH RTCP packets AND RTP header extensions 🦋, which means the value can literally flip-flop back and forth right when it gets updated 😭. There are at least two reasons this happens. Reason one: packet reordering 🌀, where an old RTP or RTCP packet carrying the previous SDES value arrives AFTER the first packet with the new value. Reason two: the RTP and RTCP code paths in implementations are different 💅, so an update to the sender's SDES item can take a different amount of time to reach the receiver than the media data does. Like, an RTCP packet that was made before the update can still be sitting in a buffer and get sent unchanged 🙈. Meanwhile the new value is already showing up in RTP packets with the header extension, before that RTCP packet even leaves. Chaotic, I know 💀.

BUT the good news is most of this drama can be avoided if the receiver does a few checks before it updates its stored value 🫶. To deal with flaps caused by reordering, SDES items received in RTP packets with the same or a lower extended sequence number than the last change MUST NOT be applied 🚫. Basically, throw out anything that can be figured out to be older than the current one 🗑️. For compound RTCP packets, which will contain an SR packet (assuming there's an active RTP sender) 📡, the receiver can look at the RTCP SR timestamp field to estimate roughly when it was sent ⏰. If that timestamp is earlier than the last received RTP packet with a header extension carrying an SDES item, and especially if it's carrying a value that was used before 👀, the SDES item in the RTCP SDES packet can be ignored. Ngl, this is so smart. Also, heads up: media processing and transmission pacing can easily make the RTP header timestamp field AND the RTCP SR timestamp field not match the actual transmission time ⚠️, so don't treat them as perfectly accurate clocks 🙃.

4.2.7. RTP Header Compression 🗜️

When Robust Header Compression (ROHC) [RFC5225] is used with RTP, the RTP header extension [RFC5285] data itself is NOT part of what gets compressed 🙌, so it doesn't affect header compression performance at all. The extension indicator (X) bit in the RTP header, though, is compressed 🎀. It gets classified as rarely changing, and that might not be true for every RTP header extension usage 😬, which can lead to lower header compression efficiency 📉.

5. IANA Considerations 📋

This section details the following updates made by IANA 🧚:

  • Creation of a new sub-registry reserved for RTCP SDES items with the URN subspace "urn:ietf:params:rtp-hdrext:sdes:" in the "RTP Compact Header Extensions" registry 🌸.
  • Registration of the SDES items appropriate for use with the RTP header extension defined in this document 💜.

5.1. Registration of an SDES Base URN 🍓

IANA has registered the following entry in the "RTP Compact Header Extensions" registry:

Extension URI: urn:ietf:params:rtp-hdrext:sdes
Description:   Reserved as base URN for RTCP SDES items that are also
               defined as RTP compact header extensions.
Contact:       Authors of RFC 7941
Reference:     RFC 7941

The reason to register a base URN for an SDES subspace is that the name represents an RTCP Source Description item 🎯, and for those a specification is strongly recommended [RFC3550] ✨.

5.2. Creation of the "RTP SDES Compact Header Extensions" Sub-Registry 🦄

IANA has created a sub-registry to the "RTP Compact Header Extensions" registry, with the same basic requirements, structure, and layout as the "RTP Compact Header Extensions" registry 💖.

  • Registry name: RTP SDES Compact Header Extensions
  • Specification: RFC 7941
  • Information required: Same as for the "RTP Compact Header Extensions" registry [RFC5285]
  • Review process: Same as for the "RTP Compact Header Extensions" registry [RFC5285], with the following requirements added to the Expert Review [RFC5226]:
    1. Any registration using an extension URI that starts with "urn:ietf:params:rtp-hdrext:sdes:" (Section 5.1) MUST also have a registered Source Description item in the "RTP SDES item types" registry.
    2. Security and privacy considerations for the SDES item MUST be provided with the registration.
    3. Information MUST be provided on why this SDES item requires timely delivery, motivating it to be transported in a header extension rather than as RTCP only.
  • Size and format of entries: Same as for the "RTP Compact Header Extensions" registry [RFC5285].
  • Initial assignments: See Section 5.3 of this document.

5.3. Registration of SDES Item 🎀

IANA has registered the following SDES item in the newly formed "RTP SDES Compact Header Extensions" registry:

Extension URI: urn:ietf:params:rtp-hdrext:sdes:cname
Description:   Source Description: Canonical End-Point Identifier
               (SDES CNAME)
Contact:       Authors of RFC 7941
Reference:     RFC 7941

6. Security Considerations 🔐

Okay, serious moment, bestie 😤. Security is not a vibe-only topic. Read this part carefully 🫡.

Source Description items may contain data that are sensitive from a security perspective 🚨. There are SDES items that are or may be sensitive from a user privacy perspective, like CNAME, NAME, EMAIL, PHONE, LOC, and H323-CADDR 🕵️. Some may contain sensitive information, like NOTE and PRIV 🤫, while others may be sensitive from profiling implementations for vulnerability or other reasons, like TOOL 🔍. The CNAME sensitivity can vary depending on how it is generated and what persistence it has 🧠. A short-term CNAME identifier generated using a random number generator [RFC7022] may have minimal security implications 🎲, while a CNAME of the form user@host has privacy concerns 😰, and a CNAME generated from a Media Access Control (MAC) address has long-term tracking potential 📍💀.

In RTP sessions where any type of confidentiality protection is enabled for RTCP, the SDES item header extensions MUST also be protected 🔒. This implies that to provide confidentiality, users of the Secure Real-time Transport Protocol (SRTP) need to implement and use encrypted header extensions per [RFC6904] 🛡️. SDES items carried as RTP header extensions MUST then use commensurate strength algorithms and SHOULD use the same cryptographic primitives (algorithms, modes) as applied to RTCP packets carrying corresponding SDES items 🧁. If the security level is chosen to be different for an SDES item in RTCP and an RTP header extension, it is important to justify the exception and to consider the security properties as the worst in each aspect for the different configurations 🧐. It is worth noting that the current SRTP [RFC3711] only provides protection for the next trusted RTP/RTCP hop, which is not necessarily end to end 🔗.

The general RTP header extension mechanism [RFC5285] does not itself contain any functionality that is a significant risk for a denial-of-service attack, neither from processing nor from storage requirements 👍. The extension for SDES items defined in this document can potentially be a risk 😬. The risk depends on the received SDES item and its content. If the SDES item causes the receiver to perform a large amount of processing, create significant storage structures, or emit network traffic, such a risk does exist 🚩. The CNAME SDES item in the RTP header extension is only a minor risk, as reception of a CNAME item will create an association between the stream carrying the SDES item and other RTP streams with the same SDES item 🔁. This usually results in time synchronizing the media streams; thus, some additional processing is performed ⏱️. However, the application's media quality is likely more affected by an erroneous or changing association and media synchronization than the application quality impact caused by the additional processing 📺.

As the SDES items are used by the RTP-based application to establish relationships between RTP streams or between an RTP stream and information about the originating participant, there SHOULD be strong integrity protection and source authentication of the header extensions 🪪. If not, an attacker can modify the SDES item value to create erroneous relationship bindings in the receiving application 👾. For information regarding options for securing RTP, see [RFC7201] 📚.

7. References 📖

7.1. Normative References 🌟

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

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

[RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
           Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
           2008, <http://www.rfc-editor.org/info/rfc5285>.

[RFC6904]  Lennox, J., "Encryption of Header Extensions in the Secure
           Real-time Transport Protocol (SRTP)", RFC 6904,
           DOI 10.17487/RFC6904, April 2013,
           <http://www.rfc-editor.org/info/rfc6904>.

7.2. Informative References

okay, these are the "fyi, go read this if you're curious" sources 📚💅 they're not required reading, but they're the receipts behind the whole spec ✨

Acknowledgments ✨

the authors wanted to give a big shoutout to Colin Perkins, Ben Campbell, and Samuel Weiler for their feedback and suggestions 🫶 they're the reason this spec is as clean as it is 💖

Authors' Addresses 🦋

here's where to find the people who wrote this 💜

Magnus Westerlund
Ericsson
Farogatan 6
SE-164 80 Stockholm
Sweden

Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com
Bo Burman
Ericsson
Gronlandsgatan 31
Stockholm  16480
Sweden

Email: bo.burman@ericsson.com
Roni Even
Huawei Technologies
Tel Aviv
Israel

Email: roni.even@mail01.huawei.com
Mo Zanaty
Cisco Systems
7100 Kit Creek
RTP, NC  27709
United States of America

Email: mzanaty@cisco.com
📦 where this page comes from