doc: Add RFC documents

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]
+