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

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/