diff options
Diffstat (limited to 'doc/rfc/rfc8285.txt')
| -rw-r--r-- | doc/rfc/rfc8285.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc8285.txt b/doc/rfc/rfc8285.txt new file mode 100644 index 0000000..8661e1d --- /dev/null +++ b/doc/rfc/rfc8285.txt @@ -0,0 +1,1403 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Singer +Request for Comments: 8285 Apple, Inc. +Obsoletes: 5285 H. Desineni +Category: Standards Track Qualcomm +ISSN: 2070-1721 R. Even, Ed. + Huawei Technologies + October 2017 + + + A General Mechanism for RTP Header Extensions + +Abstract + + This document provides a general mechanism to use the header + extension feature of RTP (the Real-time Transport Protocol). It + provides the option to use a small number of small extensions in each + RTP packet, where the universe of possible extensions is large and + registration is decentralized. The actual extensions in use in a + session are signaled in the setup information for that session. This + document obsoletes RFC 5285. + +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 + https://www.rfc-editor.org/info/rfc8285. + + + + + + + + + + + + + + + + + +Singer, et al. Standards Track [Page 1] + +RFC 8285 RTP Header Extensions October 2017 + + +Copyright Notice + + Copyright (c) 2017 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 + (https://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. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Requirements Notation ...........................................3 + 3. Design Goals ....................................................3 + 4. Packet Design ...................................................4 + 4.1. General ....................................................4 + 4.1.1. Transmission Considerations .........................5 + 4.1.2. Header Extension Type Considerations ................6 + 4.2. One-Byte Header ............................................8 + 4.3. Two-Byte Header ............................................9 + 5. SDP Signaling Design ...........................................10 + 6. SDP Signaling for Support of Mixed One-Byte and Two-Byte + Header Extensions ..........................................12 + 7. SDP Offer/Answer ...............................................13 + 8. BNF Syntax .....................................................17 + 9. Security Considerations ........................................17 + 10. IANA Considerations ...........................................18 + 10.1. Identifier Space for IANA to Manage ......................18 + 10.2. Registration of the SDP "extmap" Attribute ...............20 + 10.3. Registration of the SDP "extmap-allow-mixed" Attribute ...20 + 11. Changes from RFC 5285 .........................................21 + 12. References ....................................................21 + 12.1. Normative References .....................................21 + 12.2. Informative References ...................................23 + Acknowledgments ...................................................24 + Authors' Addresses ................................................25 + + + + + + + + + +Singer, et al. Standards Track [Page 2] + +RFC 8285 RTP Header Extensions October 2017 + + +1. Introduction + + The RTP specification [RFC3550] provides a capability to extend the + RTP header. Section 5.3.1 of [RFC3550] defines the header extension + format and rules for its use. The existing header extension method + permits at most one extension per RTP packet, identified by a 16-bit + identifier and a 16-bit length field specifying the length of the + header extension in 32-bit words. + + This mechanism has two conspicuous drawbacks. First, it permits only + one header extension in a single RTP packet. Second, the + specification gives no guidance as to how the 16-bit header extension + identifiers are allocated to avoid collisions. + + This specification removes the first drawback by defining a backward- + compatible and extensible means to carry multiple header extension + elements in a single RTP packet. It removes the second drawback by + defining that these extension elements are named by URIs, defining an + IANA registry for extension elements defined in IETF specifications, + and providing a Session Description Protocol (SDP) method for mapping + between the naming URIs and the identifier values carried in the RTP + packets. + + This header extension applies to RTP/AVP (the Audio/Visual Profile) + and its extensions. + + This document obsoletes [RFC5285] and removes a limitation from + RFC 5285 that did not allow sending both one-byte and two-byte header + extensions in the same RTP stream. + +2. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Design Goals + + The goal of this design is to provide a simple mechanism whereby + multiple identified extensions can be used in RTP packets, without + the need for formal registration of those extensions but nonetheless + avoiding collisions. + + This mechanism provides an alternative to the practice of burying + associated metadata into the media format bitstream. This has often + been done in media data sent over fixed-bandwidth channels. Once + + + +Singer, et al. Standards Track [Page 3] + +RFC 8285 RTP Header Extensions October 2017 + + + this is done, a decoder for the specific media format needs to + extract the metadata. Also, depending on the media format, the + metadata can be added at the time of encoding the media so that the + bit-rate used for the metadata is taken into account. But the + metadata can be unknown at that time. Inserting metadata at a later + time can cause a decode and re-encode to meet bit-rate requirements. + + In some cases, a more appropriate and higher-level mechanism may be + available, and if so, it can be used. For cases where a higher-level + mechanism is not available, it is better to provide a mechanism at + the RTP level than to have the metadata be tied to a specific form of + media data. + +4. Packet Design + +4.1. General + + The following design is fit into the "header extension" of the RTP + extension, as described above. + + The presence and format of this header extension and its contents are + negotiated or defined out of band, such as through signaling (see + below for SDP signaling). The 16-bit identifier for the two forms of + the RTP extension defined here is only an architectural constant + (e.g., for use by network analyzers); it is the negotiation/ + definition (e.g., in SDP) that is the definitive indication that this + header extension is present. + + The RTP specification [RFC3550] states that RTP "is designed so that + the header extension may be ignored by other interoperating + implementations that have not been extended." The intent of this + restriction is that RTP header extensions MUST NOT be used to extend + RTP itself in a manner that is backward incompatible with + non-extended implementations. For example, a header extension is not + allowed to change the meaning or interpretation of the standard RTP + header fields or of the RTP Control Protocol (RTCP). Header + extensions MAY carry metadata in addition to the usual RTP header + information, provided the RTP layer can function if that metadata is + missing. For example, RTP header extensions can be used to carry + data that's also sent in RTCP, as an optimization to lower latency, + since they'll fall back to the original non-optimized behavior if the + header extension is not present. The use of header extensions to + convey information that will, if missing, disrupt the behavior of a + higher-layer application that builds on top of RTP is only acceptable + if this doesn't affect interoperability at the RTP layer. For + example, applications that use the SDP BUNDLE extension with the + Media Identification (MID) RTP header extension [SDP-BUNDLE] to + correlate RTP streams with SDP "m=" lines likely won't work with full + + + +Singer, et al. Standards Track [Page 4] + +RFC 8285 RTP Header Extensions October 2017 + + + functionality if the MID is missing, but the operation of the RTP + layer of those applications will be unaffected. Support for RTP + header extensions based on this memo is negotiated using, for + example, SDP Offer/Answer [RFC3264]; intermediaries aware of the RTP + header extensions are advised to be cautious when removing or + generating RTP header extensions. See Section 4.7 of [RFC7667]. + + The RTP header extension is formed as a sequence of extension + elements, with possible padding. Each extension element has a local + identifier and a length. The local identifiers MAY be mapped to a + larger namespace in the negotiation (e.g., session signaling). + +4.1.1. Transmission Considerations + + As is good network practice, data should only be transmitted when + needed. The RTP header extension SHOULD only be present in a packet + if that packet also contains one or more extension elements, as + defined here. An extension element SHOULD only be present in a + packet when needed; the signaling setup of extension elements + indicates only that those elements can be present in some packets, + not that they are in fact present in all (or indeed, any) packets. + + Some general considerations for getting the header extensions + delivered to the receiver are as follows: + + 1. The probability for packet loss and burst loss determines 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 losing all + repetitions of the header extensions 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 header extension item information is needed, from + the first received RTP data or only after some set of packets are + received, can guide whether the header extension(s) should be + (1) in all of the first N packets or (2) included only once per + set of packets -- for example, once per video frame. + + + + + + + + + +Singer, et al. Standards Track [Page 5] + +RFC 8285 RTP Header Extensions October 2017 + + + 4. The use of RTP-level robustness mechanisms, such as RTP + retransmission [RFC4588] or Forward Error Correction (e.g., + [RFC5109]) may treat packets differently from a robustness + perspective, and 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 + stop further repetitions. Feedback that can be used includes the + RTCP Extended Report (XR) Loss RLE Report Block [RFC3611], which will + indicate successful delivery of particular packets. If the RTP/AVPF + transport-layer feedback messages for generic NACK [RFC4585] are + used, they can indicate 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. + +4.1.2. Header Extension Type Considerations + + Each extension element in a packet has a local identifier (ID) and a + length. The local identifiers present in the stream MUST have been + negotiated or defined out of band. There are no static allocations + of local identifiers. Each distinct extension MUST have a unique ID. + The ID value 0 is reserved for padding and MUST NOT be used as a + local identifier. + + An extension element with an ID value equal to 0 MUST NOT have an + associated length field greater than 0. If such an extension element + is encountered, its length field MUST be ignored, processing of the + entire extension MUST terminate at that point, and only the extension + elements present prior to the element with ID 0 and a length field + greater than 0 SHOULD be considered. + + There are two variants of the extension: one-byte and two-byte + headers. Since it is expected that (a) the number of extensions in + any given RTP session is small and (b) the extensions themselves are + + + +Singer, et al. Standards Track [Page 6] + +RFC 8285 RTP Header Extensions October 2017 + + + small, the one-byte header form is preferred and MUST be supported by + all receivers. A stream MUST contain only one-byte headers or only + two-byte headers unless it is known that all recipients support + mixing, by either SDP Offer/Answer [RFC3264] negotiation (see + Section 6) or out-of-band knowledge. Each RTP packet with an RTP + header extension following this specification will indicate whether + it contains one-byte or two-byte header extensions through the use of + the "defined by profile" field. Extension element types that do not + match the header extension format, i.e., one-byte or two-byte, + MUST NOT be used in that RTP packet. Transmitters SHOULD NOT use the + two-byte header form when all extensions are small enough for the + one-byte header form. Transmitters that intend to send the two-byte + form SHOULD negotiate the use of IDs above 14 if they want to let the + receivers know that they intend to use the two-byte form -- for + example, if the RTP header extension is longer than 16 bytes. A + transmitter may be aware that an intermediary may add RTP header + extensions; in this case, the transmitter SHOULD use the two-byte + form. + + A sequence of extension elements, possibly with padding, forms the + header extension defined in the RTP specification. There are as many + extension elements as will fit in the RTP header extension, as + indicated by the RTP header extension length. Since this length is + signaled in full 32-bit words, padding bytes are used to pad to a + 32-bit boundary. The entire extension is parsed byte by byte to find + each extension element (no alignment is needed), and parsing stops + (1) at the end of the entire header extension or (2) in the "one-byte + headers only" case, on encountering an identifier with the reserved + value of 15 -- whichever happens earlier. + + In both forms, padding bytes have the value of 0 (zero). They MAY be + placed between extension elements, if desired for alignment, or after + the last extension element, if needed for padding. A padding byte + does not supply the ID of an element, nor does it supply the length + field. When a padding byte is found, it is ignored, and the parser + moves on to interpreting the next byte. + + Note carefully that the one-byte header form allows for data lengths + between 1 and 16 bytes, by adding 1 to the signaled length value + (thus, 0 in the length field indicates that one byte of data + follows). This allows for the important case of 16-byte payloads. + This addition is not performed for the two-byte headers, where the + length field signals data lengths between 0 and 255 bytes. + + Use of RTP header extensions will reduce the efficiency of RTP header + compression, since the header extension will be sent uncompressed + unless the RTP header compression module is updated to recognize the + extension header. If header extensions are present in some packets + + + +Singer, et al. Standards Track [Page 7] + +RFC 8285 RTP Header Extensions October 2017 + + + but not in others, this can also reduce compression efficiency by + requiring an update to the fixed header to be conveyed when header + extensions start or stop being sent. The interactions of the RTP + header extension and header compression are explored further in + [RFC2508] and [RFC3095]. + +4.2. One-Byte Header + + In the one-byte header form of extensions, the 16-bit value required + by the RTP specification for a header extension, labeled in the RTP + specification as "defined by profile", MUST have the fixed bit + pattern 0xBEDE (the pattern was picked for the trivial reason that + the first version of this specification was written on May 25th -- + the feast day of the Venerable Bede). + + Each extension element MUST start with a byte containing an ID and a + length: + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | ID | len | + +-+-+-+-+-+-+-+-+ + + The 4-bit ID is the local identifier of this element in the range + 1-14 inclusive. In the signaling section, this is referred to as the + valid range. + + The local identifier value 15 is reserved for a future extension and + MUST NOT be used as an identifier. If the ID value 15 is + encountered, its length field MUST be ignored, processing of the + entire extension MUST terminate at that point, and only the extension + elements present prior to the element with ID 15 SHOULD be + considered. + + The 4-bit length is the number, minus one, of data bytes of this + header extension element following the one-byte header. Therefore, + the value zero (0) in this field indicates that one byte of data + follows, and a value of 15 (the maximum) indicates element data of + 16 bytes. (This permits carriage of 16-byte values, which is a + common length of labels and identifiers, while losing the possibility + of zero-length values, which would often be padded anyway.) + + + + + + + + + +Singer, et al. Standards Track [Page 8] + +RFC 8285 RTP Header Extensions October 2017 + + + An example header extension, with three extension elements and some + padding, follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0xBE | 0xDE | length=3 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ID | L=0 | data | ID | L=1 | data... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ...data | 0 (pad) | 0 (pad) | ID | L=3 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.3. Two-Byte Header + + In the two-byte header form, the 16-bit value defined by the RTP + specification for a header extension, labeled in the RTP + specification as "defined by profile", is defined as shown below. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0x100 |appbits| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The appbits field is 4 bits that are application dependent and MAY be + defined to be any value or meaning; this topic is outside the scope + of this specification. For the purposes of signaling, this field is + treated as a special extension value assigned to the local identifier + 256. If no extension has been specified through configuration or + signaling for this local identifier value (256), the appbits field + SHOULD be set to all 0s (zeros) by the sender and MUST be ignored by + the receiver. + + Each extension element starts with a byte containing an ID and a byte + containing a length: + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ID | length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The 8-bit ID is the local identifier of this element in the range + 1-255 inclusive. In the signaling section, the range 1-256 is + referred to as the valid range, with the values 1-255 referring to + + + +Singer, et al. Standards Track [Page 9] + +RFC 8285 RTP Header Extensions October 2017 + + + extension elements and the value 256 referring to the 4-bit appbits + field (above). Note that there is one ID space for both the one-byte + form and the two-byte form. This means that the lower values (1-14) + can be used in the 4-bit ID field in the one-byte header format with + the same meanings. + + The 8-bit length field is the length of extension data in bytes, not + including the ID and length fields. The value zero (0) indicates + that there is no subsequent data. + + An example header extension, with three extension elements and some + padding, follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0x10 | 0x00 | length=3 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ID | L=0 | ID | L=1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | 0 (pad) | ID | L=4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | data | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +5. SDP Signaling Design + + The indication of the presence of this extension, and the mapping of + local identifiers used in the header extension to a larger namespace, + MUST be performed out of band -- for example, as part of an SDP + Offer/Answer [RFC3264]. This section defines such signaling in SDP. + + A usable mapping MUST use IDs in the valid range, and each ID in this + range MUST be used only once for each media section (or only once if + the mappings are session level). Mappings that do not conform to + these rules MAY be presented, for instance, during SDP Offer/Answer + [RFC3264] negotiation as described in the next section, but remapping + to conformant values is necessary before they can be applied. + + Each extension is named by a URI. That URI MUST be absolute; it + precisely identifies the format and meaning of the extension. URIs + that contain a domain name SHOULD also contain a month-date in the + form mmyyyy. The definition of the element and assignment of the URI + MUST have been authorized by the owner of the domain name on or very + close to that date. (This avoids problems when domain names change + ownership.) If the resource or document defines several extensions, + + + + + +Singer, et al. Standards Track [Page 10] + +RFC 8285 RTP Header Extensions October 2017 + + + then the URI MUST identify the actual extension in use, e.g., using a + fragment or query identifier (characters after a "#" or "?" in + the URI). + + Rationale: The use of URIs provides for a large, unallocated space + and gives documentation on the extension. The URIs do not have to be + dereferencable, in order to permit confidential or experimental use, + or to cover the case when extensions continue to be used after the + organization that defined them ceases to exist. + + An extension URI with the same attributes MUST NOT appear more than + once applying to the same stream, i.e., at session level or in the + declarations for a single stream at media level. (The same extension + can, of course, be used for several streams and can appear with + different <extensionattributes> for the same stream.) + + For extensions defined in RFCs, the URI used SHOULD be a URN starting + with "urn:ietf:params:rtp-hdrext:" followed by a registered, + descriptive name. + + The registration requirements are detailed in Section 10 ("IANA + Considerations"). + + An example where "avt-example-metadata" is the hypothetical name of a + header extension might be: + + urn:ietf:params:rtp-hdrext:avt-example-metadata + + An example name not from the IETF might be: + + http://example.com/082005/ext.htm#example-metadata + + The mapping MAY be provided per media stream (in the media-level + section(s) of SDP, i.e., after an "m=" line) or globally for all + streams (i.e., before the first "m=" line, at session level). The + definitions MUST be either all session level or all media level; it + is not permitted to mix the two styles. In addition, as noted above, + the IDs used MUST be unique in each media section of the SDP or + unique in the session for session-level SDP declarations. + + + + + + + + + + + + +Singer, et al. Standards Track [Page 11] + +RFC 8285 RTP Header Extensions October 2017 + + + Each local identifier potentially used in the stream is mapped to an + extension identified by a URI using an attribute of the form: + + a=extmap:<value>["/"<direction>] <URI> <extensionattributes> + + where + + o <value> is the local identifier (ID) of this extension and is an + integer in the valid range (0 is reserved for padding in both + forms, and 15 is reserved in the one-byte header form, as noted + above). + + o <direction> is one of "sendonly", "recvonly", "sendrecv", or + "inactive" (without the quotes) with relation to the device being + configured. + + o <URI> is a URI, as above. + + The formal BNF syntax is presented in Section 8 of this + specification. + + Example: + + a=extmap:1 http://example.com/082005/ext.htm#ttime + + a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short + + When SDP signaling is used for the RTP session, it is the presence of + the "extmap" attribute(s) that is diagnostic that this style of + header extensions is used, not the magic number ("BEDE" or "100") + indicated above. + +6. SDP Signaling for Support of Mixed One-Byte and Two-Byte Header + Extensions + + In order to allow for backward interoperability with systems that + do not support the mixing of one-byte and two-byte header extensions, + this document defines the "a=extmap-allow-mixed" Session Description + Protocol (SDP) [RFC4566] attribute to indicate if the participant is + capable of supporting this new mode. The attribute takes no value. + This attribute can be used at the session level or the media level. + A participant that proposes the use of this mode SHALL itself support + the reception of mixed one-byte and two-byte header extensions. + + If SDP Offer/Answer [RFC3264] is supported and used, the negotiation + for mixed one-byte and two-byte extensions MUST be negotiated using + SDP Offer/Answer per [RFC3264]. In the absence of negotiations using + + + + +Singer, et al. Standards Track [Page 12] + +RFC 8285 RTP Header Extensions October 2017 + + + SDP Offer/Answer -- for example, when declarative SDP is used -- + mixed headers MUST NOT occur unless the transmitter has some + (out-of-band) knowledge that all potential recipients support + this mode. + + The formal definition of this attribute is: + + Name: extmap-allow-mixed + + Value: None + + Usage Level: session, media + + Charset Dependent: No + + Example: + + a=extmap-allow-mixed + + When doing SDP Offer/Answer [RFC3264], an offering client that wishes + to use both one-byte and two-byte extensions MUST include the + attribute "a=extmap-allow-mixed" in the SDP offer. If + "a=extmap-allow-mixed" is present in the SDP offer, the answerer that + supports this mode and wishes to use it SHALL include the + "a=extmap-allow-mixed" attribute in the answer. In the cases where + the attribute has been excluded, both clients SHALL NOT use mixed + one-byte and two-byte extensions in the same RTP stream but MAY use + the one-byte or two-byte form exclusively (see Section 4.1.2). + + When used per [SDP-BUNDLE], this attribute is specified as the + IDENTICAL category [SDP-MUX]. + +7. SDP Offer/Answer + + The simple signaling described above for the "extmap" attribute MAY + be enhanced in an SDP Offer/Answer [RFC3264] context, to permit: + + o asymmetric behavior (extensions sent in only one direction), + + o the offer of mutually exclusive alternatives, or + + o the offer of more extensions than can be sent in a single session. + + A direction attribute MAY be included in an "extmap"; without it, the + direction implicitly inherits, of course, from the stream direction + or is "sendrecv" for session-level attributes or extensions of + "inactive" streams. The direction MUST be one of "sendonly", + "recvonly", "sendrecv", or "inactive" as specified in [RFC3264]. + + + +Singer, et al. Standards Track [Page 13] + +RFC 8285 RTP Header Extensions October 2017 + + + Extensions, with their directions, MAY be signaled for an "inactive" + stream. It is an error to use an extension direction incompatible + with the stream direction (e.g., a "sendonly" attribute for a + "recvonly" stream). + + If an offer or answer contains session-level mappings (and hence no + media-level mappings) and different behavior is desired for each + stream, then the entire set of extension map declarations MAY be + moved into the media-level section(s) of the SDP. (Note that this + specification does not permit mixing global and local declarations, + to make identifier management easier.) + + If an extension map is offered as "sendrecv", explicitly or + implicitly, and asymmetric behavior is desired, the SDP answer MAY be + changed to modify or add direction qualifiers for that extension. + + If an extension is marked as "sendonly" and the answerer desires to + receive it, the extension MUST be marked as "recvonly" in the SDP + answer. An answerer that has no desire to receive the extension or + does not understand the extension SHOULD remove it from the SDP + answer. An answerer MAY want to respond that he supports the + extension and does not want to receive it at the moment, but he may + indicate a desire to receive it in a future offer and will mark the + extension as "inactive". + + If an extension is marked as "recvonly" and the answerer desires to + send it, the extension MUST be marked as "sendonly" in the SDP + answer. An answerer that has no desire to, or is unable to, send the + extension SHOULD remove it from the SDP answer. An answerer MAY want + to respond that he supports this extension but has no intention of + sending it now; he may indicate a desire to send it in a future offer + by marking the extension as "inactive". + + Local identifiers in the valid range inclusive in an offer or answer + must not be used more than once per media section (including the + session-level section). The local identifiers MUST be unique in an + RTP session, and the same identifier MUST be used for the same + offered extension in the answer. A session update MAY change the + direction qualifiers of extensions being used. A session update MAY + add or remove extension(s). Identifier values in the valid range + MUST NOT be altered (remapped). + + Note that, under this rule, the same local identifier cannot be used + for two extensions for the same media, even when one is "sendonly" + and the other "recvonly", as it would then be impossible to make + either of them "sendrecv" (since renumbering is not permitted + either). + + + + +Singer, et al. Standards Track [Page 14] + +RFC 8285 RTP Header Extensions October 2017 + + + If a party wishes to offer mutually exclusive alternatives, then + multiple extensions with the same identifier in the extended range + 4096-4351 MAY be offered. The answerer SHOULD select, at most, one + of the offered extensions with the same identifier and remap it to a + free identifier in the valid range for that extension to be usable. + + Similarly, if more extensions are offered than can be fit in the + valid range, identifiers in the range 4096-4351 MAY be offered; the + answerer SHOULD choose those that are desired and remap them to a + free identifier in the valid range. + + An answerer may copy an "extmap" for an identifier in the extended + range into the answer to indicate to the offerer that it supports + that extension. Of course, such an extension cannot be used, since + there is no way to specify it in an extension header. If needed, the + offerer or answerer can update the session to assign a valid + identifier to that extension URI. + + Rationale: The range 4096-4351 for these negotiation identifiers is + deliberately restricted to allow expansion of the range of valid + identifiers in the future. + + Either party MAY include extensions in the stream other than those + negotiated, or those negotiated as "inactive" (for example, for the + benefit of intermediate nodes). Only extensions that appeared with + an identifier in the valid range in SDP originated by the sender can + be sent. + + Example (port numbers, RTP profiles, payload IDs, rtpmaps, etc. all + omitted for brevity): + + The offer: + + a=extmap:1 URI-toffset + a=extmap:14 URI-obscure + a=extmap:4096 URI-gps-string + a=extmap:4096 URI-gps-binary + a=extmap:4097 URI-frametype + m=video + a=sendrecv + m=audio + a=sendrecv + + + + + + + + + +Singer, et al. Standards Track [Page 15] + +RFC 8285 RTP Header Extensions October 2017 + + + The answerer is interested in receiving GPS in string format only on + video but cannot send GPS at all. It is not interested in + transmission offsets on audio and does not understand the URI-obscure + extension. It therefore moves the extensions from session level to + media level and adjusts the declarations: + + m=video + a=sendrecv + a=extmap:1 URI-toffset + a=extmap:2/recvonly URI-gps-string + a=extmap:3 URI-frametype + m=audio + a=sendrecv + a=extmap:1/sendonly URI-toffset + + When using [SDP-BUNDLE] to bundle multiple "m=" lines, the "extmap" + attribute falls under the SPECIAL category of [SDP-MUX]. All the + "m=" lines in a BUNDLE group are considered to be part of the same + local identifier (ID) space. If an RTP header extension, i.e., a + particular extension URI and configuration using + <extensionattributes>, is offered in multiple "m=" lines that are + part of the same BUNDLE group, it MUST use the same ID in all of + these "m=" lines. Each "m=" line in a BUNDLE group can include + different RTP header extensions allowing, for example, audio and + video sources to use different sets of RTP header extensions. A + difference in configuration using any of the <extensionattributes> is + important. Unless an RTP header extension explicitly states + otherwise, any such difference SHALL be communicated to all receivers + and SHALL cause assignment of different IDs. An RTP header extension + that does not follow this rule MUST explicitly define what would + constitute compatible configurations that can be sent with the + same ID. The directionality of the RTP header extensions in each + "m=" line of the BUNDLE group is handled in the same way as handling + for non-bundled "m=" lines. This allows for specifying different + directionality for each of the repeated extension URIs in a BUNDLE + group. + + + + + + + + + + + + + + + +Singer, et al. Standards Track [Page 16] + +RFC 8285 RTP Header Extensions October 2017 + + +8. BNF Syntax + + The syntax definition below uses ABNF according to [RFC5234]. The + syntax element "URI" is defined in [RFC3986] (only absolute URIs are + permitted here). The syntax element "extmap" is an attribute as + defined in [RFC4566], i.e., "a=" precedes the "extmap" definition. + Specific <extensionattributes> are defined by the specification that + defines a specific extension name; there can be several. + + Name: extmap + + Value: extmap-value + + Syntax: + + extmap-value = mapentry SP extensionname + [SP extensionattributes] + + mapentry = "extmap:" 1*5DIGIT ["/" direction] + + extensionname = URI + + extensionattributes = byte-string + + direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" + + URI = <Defined in RFC 3986> + + byte-string = <Defined in RFC 4566> + + SP = <Defined in RFC 5234> + + DIGIT = <Defined in RFC 5234> + +9. Security Considerations + + This document defines only a place to transmit information; the + security implications of each of the extensions must be discussed + with those extensions. + + Extension usage is negotiated using [RFC3264], so integrity + protection and end-to-end authentication MUST be implemented. The + security considerations of [RFC3264] MUST be followed to prevent, for + example, extension-usage blocking. + + Header extensions have the same security coverage as the RTP header + itself. When the Secure Real-time Transport Protocol (SRTP) + [RFC3711] is used to protect RTP sessions, the RTP payload can be + + + +Singer, et al. Standards Track [Page 17] + +RFC 8285 RTP Header Extensions October 2017 + + + both encrypted and integrity protected, while the RTP header is + either unprotected or integrity protected. In order to prevent DoS + attacks (for example, by changing the header extension) integrity + protection SHOULD be used. Lower-layer security protection such as + Datagram Transport Layer Security (DTLS) [RFC6347] MAY be used. RTP + header extensions can carry sensitive information for which + participants in multimedia sessions want confidentiality. RFC 6904 + [RFC6904] provides a mechanism that extends the mechanisms of SRTP to + selectively encrypt RTP header extensions in SRTP. + + The RTP application designer needs to consider their security needs, + that includes cipher strength for SRTP packets in general and what + that means for the integrity and confidentiality of the RTP header + extensions. As defined by RFC 6904 [RFC6904], the encryption stream + cipher for the header extension is dependent on the chosen SRTP + cipher. + + Other options for securing RTP are discussed in [RFC7201]. + +10. IANA Considerations + + This document updates the references in three IANA registries to + point to this document instead of RFC 5285, and updates and adds new + SDP attributes in Sections 10.2 and 10.3, respectively. + +10.1. Identifier Space for IANA to Manage + + The mapping from the naming URI form to a reference to a + specification is managed by IANA. Insertion into this registry is + under the requirements of "Expert Review" as defined in [RFC8126]. + + IANA will also maintain a server that contains all of the registered + elements in a publicly accessible space. + + Here is the formal declaration to comply with the IETF URN + sub-namespace specification [RFC3553]. + + o Registry name: RTP Compact Header Extensions + + o Specification: RFC 5285 and RFCs updating RFC 5285 + + o Information required: + + A. The desired extension naming URI + + B. A formal reference to the publicly available specification + + + + + +Singer, et al. Standards Track [Page 18] + +RFC 8285 RTP Header Extensions October 2017 + + + C. A short phrase describing the function of the extension + + D. Contact information for the organization or person making the + registration + + For extensions defined in RFCs, the URI SHOULD be of the form + urn:ietf:params:rtp-hdrext:, and the formal reference is the RFC + number of the RFC documenting the extension. + + o Review process: Expert Review is REQUIRED. The expert reviewer + SHOULD check the following requirements: + + 1. that the specification is publicly available; + + 2. that the extension complies with the requirements of RTP, and + this specification, for header extensions (specifically, that + the header extension can be ignored or discarded without + breaking the RTP layer); + + 3. that the extension specification is technically consistent (in + itself and with RTP), complete, and comprehensible; + + 4. that the extension does not duplicate functionality in + existing IETF specifications (including RTP itself) or other + extensions already registered; + + 5. that the specification contains a security analysis regarding + the content of the header extension; + + 6. that the extension is generally applicable -- for example, + point-to-multipoint safe -- and the specification correctly + describes limitations if they exist; + + 7. that the suggested naming URI form is appropriately chosen and + unique; and + + 8. that for multiplexed "m=" lines [SDP-BUNDLE], any RTP header + extension with differences in configurations of + <extensionattributes> that do not require assignment of + different IDs MUST explicitly indicate this and provide rules + for what would constitute compatible configurations that can + be sent with the same ID. + + o Size and format of entries: A mapping from a naming URI string to + a formal reference to a publicly available specification, with a + descriptive phrase and contact information. + + o Initial assignments: None + + + +Singer, et al. Standards Track [Page 19] + +RFC 8285 RTP Header Extensions October 2017 + + +10.2. Registration of the SDP "extmap" Attribute + + IANA has updated the registration of the "extmap" SDP attribute + [RFC4566] in the "att-field (both session and media level)" + subregistry of the "Session Description Protocol (SDP) Parameters" + registry. + + o Contact Name and email address: IETF, contacted via + <mmusic@ietf.org> (or a successor address designated by the IESG) + + o Attribute Name: extmap + + o Attribute Syntax: See Section 8 of RFC 8285. + + o Attribute Semantics: The details of appropriate values are given + in RFC 8285. + + o Usage Level: Media or session level + + o Charset Dependent: No + + o Purpose: Defines the mapping from the extension numbers used in + packet headers into extension names. + + o Offer/Answer (O/A) Procedures: See Section 7 of RFC 8285. + + o MUX Category: SPECIAL + + o Reference: RFC 8285 + +10.3. Registration of the SDP "extmap-allow-mixed" Attribute + + IANA has registered one new SDP attribute in the "att-field (both + session and media level)" subregistry of the "Session Description + Protocol (SDP) Parameters" registry: + + o Contact Name and email address: IETF, contacted via + <mmusic@ietf.org> (or a successor address designated by the IESG) + + o Attribute Name: extmap-allow-mixed + + o Attribute Syntax: See Section 6 of RFC 8285. + + o Attribute Semantics: See Section 6 of RFC 8285. + + o Attribute Value: None + + o Usage Level: Media or session level + + + +Singer, et al. Standards Track [Page 20] + +RFC 8285 RTP Header Extensions October 2017 + + + o Charset Dependent: No + + o Purpose: Negotiate the use of one byte and two bytes in the same + RTP stream. + + o O/A Procedures: See Section 6 of RFC 8285. + + o MUX Category: IDENTICAL + + o Reference: RFC 8285 + +11. Changes from RFC 5285 + + The major motivation for updating [RFC5285] was to allow having + one-byte and two-byte RTP header extensions in the same RTP stream + (but not in the same RTP packet). The support for this case is + negotiated using a new SDP attribute, "extmap-allow-mixed", specified + in this document. + + The other major change is to update the requirement from the RTP + specifications [RFC3550] and [RFC5285] that the header extension "is + designed so that the header extension may be ignored." This is + described in Section 4.1. + + More text was added to Section 4.1.1 ("Transmission Considerations") + to clarify when and how many times to send the RTP header extension + to provide a higher probability of delivery. + + The Security Considerations section was expanded. + + The rest of the changes are editorial. + +12. References + +12.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, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP + Headers for Low-Speed Serial Links", RFC 2508, + DOI 10.17487/RFC2508, February 1999, + <https://www.rfc-editor.org/info/rfc2508>. + + + + + + +Singer, et al. Standards Track [Page 21] + +RFC 8285 RTP Header Extensions October 2017 + + + [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., + Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, + K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., + Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header + Compression (ROHC): Framework and four profiles: RTP, UDP, + ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, + July 2001, <https://www.rfc-editor.org/info/rfc3095>. + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + DOI 10.17487/RFC3264, June 2002, + <https://www.rfc-editor.org/info/rfc3264>. + + [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, + <https://www.rfc-editor.org/info/rfc3711>. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + <https://www.rfc-editor.org/info/rfc3986>. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, DOI 10.17487/RFC4566, + July 2006, <https://www.rfc-editor.org/info/rfc4566>. + + [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + <https://www.rfc-editor.org/info/rfc5234>. + + [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure + Real-time Transport Protocol (SRTP)", RFC 6904, + DOI 10.17487/RFC6904, April 2013, + <https://www.rfc-editor.org/info/rfc6904>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in + RFC 2119 Key Words", BCP 14, RFC 8174, + DOI 10.17487/RFC8174, May 2017, + <https://www.rfc-editor.org/info/rfc8174>. + + + + + + + + + + +Singer, et al. Standards Track [Page 22] + +RFC 8285 RTP Header Extensions October 2017 + + +12.2. Informative References + + [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, <https://www.rfc-editor.org/info/rfc3550>. + + [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An + IETF URN Sub-namespace for Registered Protocol + Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, + June 2003, <https://www.rfc-editor.org/info/rfc3553>. + + [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, + <https://www.rfc-editor.org/info/rfc3611>. + + [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, + <https://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, + <https://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, <https://www.rfc-editor.org/info/rfc5109>. + + [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP + Header Extensions", RFC 5285, DOI 10.17487/RFC5285, + July 2008, <https://www.rfc-editor.org/info/rfc5285>. + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, <https://www.rfc-editor.org/info/rfc6347>. + + [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP + Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, + <https://www.rfc-editor.org/info/rfc7201>. + + [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, + DOI 10.17487/RFC7667, November 2015, + <https://www.rfc-editor.org/info/rfc7667>. + + + + +Singer, et al. Standards Track [Page 23] + +RFC 8285 RTP Header Extensions October 2017 + + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [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-39, August 2017. + + [SDP-MUX] Nandakumar, S., "A Framework for SDP Attributes when + Multiplexing", Work in Progress, draft-ietf-mmusic-sdp- + mux-attributes-16, December 2016. + +Acknowledgments + + Both Brian Link and John Lazzaro provided helpful comments on an + initial draft of this document. Colin Perkins was helpful in + reviewing and dealing with the details. The use of URNs for + IETF-defined extensions was suggested by Jonathan Lennox, and Pete + Cordell was instrumental in improving the padding wording. Dave Oran + provided feedback and text in the review. Mike Dolan contributed the + two-byte header form. Magnus Westerlund and Tom Taylor were + instrumental in managing the registration text. + + + + + + + + + + + + + + + + + + + + + + + + + + +Singer, et al. Standards Track [Page 24] + +RFC 8285 RTP Header Extensions October 2017 + + +Authors' Addresses + + David Singer + Apple, Inc. + 1 Infinite Loop + Cupertino, CA 95014 + United States of America + + Phone: +1 408 996 1010 + Email: singer@apple.com + URI: https://support.apple.com/quicktime + + + Harikishan Desineni + Qualcomm + 10001 Pacific Heights Blvd. + San Diego, CA 92121 + United States of America + + Phone: +1 858 845 8996 + Email: h3dnvb@gmail.com + + + Roni Even (editor) + Huawei Technologies + Tel Aviv + Israel + + Email: Roni.even@huawei.com + + + + + + + + + + + + + + + + + + + + + + +Singer, et al. Standards Track [Page 25] + |