Internet Engineering Task Force (IETF) M. Westerlund Request for Comments: 7941 B. Burman Category: Standards Track Ericsson ISSN: 2070-1721 R. Even Huawei Technologies M. Zanaty Cisco Systems August 2016 RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items
AbstractSource Description (SDES) items are normally transported in the RTP Control Protocol (RTCP). In some cases, it can be beneficial to speed up the delivery of these items. The main case is when a new synchronization source (SSRC) joins an RTP session and the receivers need this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies 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 has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7941.
Copyright Notice 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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
RFC3550][RFC5285] that can carry RTCP Source Description (SDES) items. Normally, the SDES items are carried in their own RTCP packet type [RFC3550]. By including selected SDES items in a header extension, the determination of relationship and synchronization context for new RTP streams (SSRCs) in an RTP session can be optimized. Which relationship and what information depends on the SDES items carried. This becomes a complement to using only RTCP for SDES item delivery. It is important to note that not all SDES items are appropriate to transmit using RTP header extensions. Some SDES items perform binding or identify synchronization contexts with strict timeliness requirements, while many other SDES items do not have such requirements. In addition, security and privacy concerns for the SDES item information need to be considered. For example, the Name and Location SDES items are highly sensitive from a privacy perspective and should not be transported over the network without strong security. No use case has identified that such information is required when the first RTP packets arrive. A delay of a few seconds before such information is available to the receiver appears acceptable. Therefore, only appropriate SDES items, such as CNAME, will be registered for use with this header extension. Requirements language and terminology are defined in Section 2. Section 3 describes why this header extension is sometimes required or at least provides a significant improvement compared to waiting for regular RTCP packet transmissions of the information. Section 4 provides a specification of the header extension and usage recommendations. Section 5 defines a subspace of the header extension URN to be used for existing and future SDES items and registers the appropriate existing SDES items. RFC2119].
RFC7656]. In particular, the following terms are used: Media Source RTP Stream Media Encoder Participant RFC6051]. This header extension carries the clock information present in the RTCP sender report (SR) packets. However, it assumes that the CNAME binding is known, which can be provided via signaling [RFC5576] in some cases, but not all. Thus, an RTP header extension for carrying SDES items like CNAME is a powerful combination to enable rapid synchronization in all cases. The "Rapid Synchronisation of RTP Flows" specification [RFC6051] does provide an analysis of the initial synchronization delay for different sessions depending on the number of receivers as well as on session bandwidth (Section 2.1 of [RFC6051]). These results are also
applicable for other SDES items that have a similar time dependency until the information can be sent using RTCP. These figures can be used to determine the benefit of reducing the initial delay before information is available for some use cases. [RFC6051] also discusses the case of late joiners and defines an RTCP Feedback format to request synchronization information, which is another potential use case for SDES items in the RTP header extension. It would, for example, be natural to include a CNAME SDES item with the header extension containing the NTP-formatted reference clock to ensure synchronization. The ongoing work on bundling Session Description Protocol (SDP) media descriptions [SDP-BUNDLE] has identified a new SDES item that can benefit from timely delivery. A corresponding RTP SDES compact header extension is therefore 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], to associate RTP streams multiplexed on the same transport with their respective SDP media description. RFC5285]. That specification defines both short and long item headers. The short headers (one byte) are restricted to 1 to 16 bytes of data, while the long format (two bytes) supports a data length of 0 to 255 bytes. Thus, the RTP header extension formats are capable of supporting any SDES item from a data length perspective. The ID field, independent of a short or long format, identifies both the type of RTP header extension and, in the case of the SDES item header extension, the type of SDES item. The mapping is done in signaling by identifying the header extension and SDES item type using a URN, which is defined in Section 5 ("IANA Considerations") for the known SDES items appropriate to use.
Section 4.2 of [RFC5285]), which consists of a 4-bit ID followed by a 4-bit length field (len) that identifies the number of data bytes (len value +1) following the header. The data part consists of len+1 bytes of UTF-8 [RFC3629] text. The type of text and its mapping to the SDES item type are 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 1 Section 4.3 of [RFC5285]), which consists of an 8-bit ID followed by an 8-bit length field (len) that identifies the number of data bytes following the header. The data part consists of len bytes of UTF-8 text. The type of text and its mapping to the SDES item type are 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
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, if using CNAMEs that are generated according to "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" [RFC7022], if using short-term persistent values, and if 96-bit random values prior to base64 encoding are sufficient, then they will fit into the one-byte header format. An RTP middlebox needs to take care choosing between one-byte headers and two-byte headers when creating the first packets for an outgoing stream (SSRC) with header extensions. First of all, it needs to consider all the header extensions that may 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 are longer than 16 bytes. An RTP middlebox that forwards a stream, i.e., not mixing it or combining it with other streams, may be able to base its choice on the header size in incoming streams. This is assuming that the middlebox does not modify the stream or add additional header extensions to the stream it sends, in which case it needs to make its own decision. RFC 6051 are all needed. Such a combination is quite likely to result in at least 16+3+8 bytes of data plus the headers, which will be another 7 bytes for one-byte headers, plus two bytes of header padding to make the complete header extension 32-bit word aligned, thus 36 bytes in total. If the packet expansion cannot be taken into account when producing the RTP payload, it can cause an issue. An RTP payload that is created to meet a particular IP-level Maximum Transmission Unit (MTU), taking the addition of IP/UDP/RTP headers but not RTP header extensions into account, could exceed the MTU when the header extensions are present, thus resulting in IP fragmentation. IP fragmentation is known to negatively impact the loss rate due to middleboxes unwilling or not capable of dealing with IP fragments, as
well as increasing the target surface for other types of packet losses. As this is a real issue, the media encoder and payload packetizer should be flexible and be capable of handling dynamically varying payload size restrictions to counter the packet expansion caused by header extensions. If that is not 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. Section 4.2.4) have different recommendations. The following are some general considerations for getting the header extensions delivered to the receiver: 1. The probability for packet loss and burst loss determine how many repetitions of the header extensions will be required to reach a targeted delivery probability and, if burst loss is likely, 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 is commonly no reason for including the header extension in all of these packets, as 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 the bandwidth. 3. How early the SDES item information is needed, from the first received RTP data or only after some set of packets are received, can guide if the header extension(s) should be in all of the first N packets or be included only once per set of packets, for example, once per video frame. 4. The use of RTP-level robustness mechanisms, such as RTP retransmission [RFC4588] or forward error correction [RFC5109], may treat packets differently from a robustness perspective, and 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 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 determine when the information in the header extensions has reached all receivers and to 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 the failure to deliver an RTP packet with the header extension, thus indicating the need for further repetitions. The normal RTCP report blocks can also provide an indicator of successful delivery, if no losses are indicated for a reporting interval covering the RTP packets with the header extension. Note that loss of an RTCP packet reporting on an interval where RTP header extension packets were sent does not necessarily mean that the RTP header extension packets themselves were lost. RFC6051]. In centralized topologies where an RTP middlebox is present, it can be responsible for transmitting the known information, possibly stored, to the new session participant only and not repeat it to all the session participants.
RTP media, ensuring synchronization between the two. Continued use of the old SDES information can lead to undesired effects in the application. Thus, header extension transmission strategies with high probability of delivery should be chosen.
last change MUST NOT be applied, i.e., discard items that can be determined to be older than the current one. For compound RTCP packets, which will contain an SR packet (assuming an active RTP sender), the receiver can use the RTCP SR timestamp field to determine at what approximate time it was transmitted. If the timestamp is earlier than the last received RTP packet with a header extension carrying an SDES item, and especially if carrying a previously used value, the SDES item in the RTCP SDES packet can be ignored. Note that media processing and transmission pacing can easily cause the RTP header timestamp field as well as the RTCP SR timestamp field to not match with the actual transmission time. RFC5225] is used with RTP, the RTP header extension [RFC5285] data itself is not part of what is being compressed and thus does not impact header compression performance. The extension indicator (X) bit in the RTP header is, however, compressed. It is classified as rarely changing, which may no longer be true for all RTP header extension usage, in turn leading to lower header compression efficiency. RFC3550].
RFC5285] o 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. o Size and format of entries: Same as for the "RTP Compact Header Extensions" registry [RFC5285]. o Initial assignments: See Section 5.3 of this document.
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 potentials. 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]. [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>. [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>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>. [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>.
[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>. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <http://www.rfc-editor.org/info/rfc4588>. [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007, <http://www.rfc-editor.org/info/rfc5109>. [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite", RFC 5225, DOI 10.17487/RFC5225, April 2008, <http://www.rfc-editor.org/info/rfc5225>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [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>. [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <http://www.rfc-editor.org/info/rfc5888>. [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010, <http://www.rfc-editor.org/info/rfc6051>. [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>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, <http://www.rfc-editor.org/info/rfc7201>. [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>. [SDP-BUNDLE] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Work in Progress, draft-ietf-mmusic-sdp-bundle-negotiation-32, August 2016.