Internet DRAFT - draft-ietf-avtcore-rfc5285-bis

draft-ietf-avtcore-rfc5285-bis







AVTCore                                                        D. Singer
Internet-Draft                                               Apple, Inc.
Obsoletes: 5285 (if approved)                                H. Desineni
Intended status: Standards Track                                Qualcomm
Expires: February 3, 2018                                   R. Even, Ed.
                                                     Huawei Technologies
                                                          August 2, 2017


             A General Mechanism for RTP Header Extensions
                 draft-ietf-avtcore-rfc5285-bis-14.txt

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 de-centralized.  The actual extensions in use in a
   session are signaled in the setup information for that session.  This
   document obsoletes RFC5285.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 3, 2018.

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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Singer, et al.          Expires February 3, 2018                [Page 1]

Internet-Draft            RTP Header Extensions              August 2017


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   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 . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Two-Byte Header . . . . . . . . . . . . . . . . . . . . .   9
   5.  SDP Signaling Design  . . . . . . . . . . . . . . . . . . . .  10
   6.  SDP Signaling for support of mixed one byte and two bytes
       header extensions.  . . . . . . . . . . . . . . . . . . . . .  12
   7.  SDP Offer/Answer  . . . . . . . . . . . . . . . . . . . . . .  13
   8.  BNF Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .  16
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     10.1.  Identifier Space for IANA to Manage  . . . . . . . . . .  17
     10.2.  Registration of the SDP extmap Attribute . . . . . . . .  19
     10.3.  Registration of the SDP extmap-allow-mixed Attribute . .  19
   11. Changes from RFC5285  . . . . . . . . . . . . . . . . . . . .  20
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     13.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   The RTP specification [RFC3550] provides a capability to extend the
   RTP header.  It defines the header extension format and rules for its
   use in Section 5.3.1.  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.




Singer, et al.          Expires February 3, 2018                [Page 2]

Internet-Draft            RTP Header Extensions              August 2017


   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 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
   RFC5285 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", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

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

   This mechanism provides an alternative to the practice of burying
   associated metadata into the media format bit stream.  This has often
   been done in media data sent over fixed-bandwidth channels.  Once
   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, 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 have the metadata be tied to a specific form of
   media data.








Singer, et al.          Expires February 3, 2018                [Page 3]

Internet-Draft            RTP Header Extensions              August 2017


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
   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 backwards 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 RTCP 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 optimisation to lower latency,
   since they'll fall back to the original, non-optimised, behaviour if
   the header extension is not present.  The use of header extensions to
   convey information that will, if missing, disrupt the behaviour 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 MID
   RTP header extension [I-D.ietf-mmusic-sdp-bundle-negotiation] to
   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
   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).





Singer, et al.          Expires February 3, 2018                [Page 4]

Internet-Draft            RTP Header Extensions              August 2017


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:

   1.  The probability for packet loss and burst loss determine how many
       repetitions of the header extensions will be required to reach a
       targeted delivery probability, and if burst loss is likely, what
       distribution would be needed to avoid getting all repetitions of
       the header extensions lost in a single burst.

   2.  If a set of packets are all needed to enable decoding, there is
       commonly no reason for including the header extension in all of
       these packets, as they share fate.  Instead, at most one instance
       of the header extension per independently decodable set of media
       data would be a more efficient use of the bandwidth.

   3.  How early the Header Extension item information is needed, from
       the first received RTP data or only after some set of packets are
       received, can guide if the header extension(s) should be in all
       of the first N packets or be included only once per set of
       packets, for example once per video frame.

   4.  The use of RTP level robustness mechanisms, such as RTP
       retransmission [RFC4588], or Forward Error Correction, 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



Singer, et al.          Expires February 3, 2018                [Page 5]

Internet-Draft            RTP Header Extensions              August 2017


   RTCP 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] is used, it can
   indicate the failure to deliver an RTP packet with the header
   extension, thus indicating the need for further repetitions.  The
   normal RTCP report blocks can also provide an indicator of successful
   delivery, if no losses are indicated for a reporting interval
   covering the RTP packets with the header extension.  Note that loss
   of an RTCP packet reporting on an interval where RTP header extension
   packets were sent, does not necessarily mean that the RTP header
   extension packets themselves were lost.

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 0 MUST NOT have len 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 len 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
   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
   headers unless it is known that all recipients support mixing, either
   by SDP Offer/Answer [RFC3264] negotiation (see section 6) or by out-
   of-band knowledge.  Each RTP packet with an RTP header extension
   following this specification will indicate if it contains one 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- or two-byte, MUST NOT be used in that RTP
   packet.  Transmitters SHOULD NOT use the two-byte 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 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 two-byte form.



Singer, et al.          Expires February 3, 2018                [Page 6]

Internet-Draft            RTP Header Extensions              August 2017


   A sequence of extension elements, possibly with padding, forms the
   header extension defined in the RTP specification.  There are as many
   extension elements as fit into the length as indicated in 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 at the earlier of
   the end of the entire header extension, or in "one-byte headers only"
   case, on encountering an identifier with the reserved value of 15.

   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 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 1 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,
   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 is 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).









Singer, et al.          Expires February 3, 2018                [Page 7]

Internet-Draft            RTP Header Extensions              August 2017


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

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








Singer, et al.          Expires February 3, 2018                [Page 8]

Internet-Draft            RTP Header Extensions              August 2017


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, and are 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 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
   extension elements, and the value 256 referring to the 4-bit field
   'appbits' (above).  Note that there is one ID space for both one-byte
   and 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 indicates there
   is no data following.










Singer, et al.          Expires February 3, 2018                [Page 9]

Internet-Draft            RTP Header Extensions              August 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       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 (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, and
   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,
   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
   de-referencable, in order to permit confidential or experimental use,
   and 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



Singer, et al.          Expires February 3, 2018               [Page 10]

Internet-Draft            RTP Header Extensions              August 2017


   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
   "urn:ietf:params:rtp-hdrext:" and followed by a registered,
   descriptive name.

   The registration requirements are detailed in the IANA Considerations
   section, below.

   An example (this is only 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 (this is only an example) 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.

   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 <URI> is a URI, as above, <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), 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
   specification.

   Example:

      a=extmap:1 http://example.com/082005/ext.htm#ttime

      a=extmap:2/sendrecv http://example.com/082005/ext.htm#xmeta short



Singer, et al.          Expires February 3, 2018               [Page 11]

Internet-Draft            RTP Header Extensions              August 2017


   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 bytes header
    extensions.

   In order to allow for backward interoperability with systems that do
   not support mixing of one byte and two bytes 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 or media levels.  A
   participant that proposes the use of this mode SHALL itself support
   the reception of mixed one byte and two bytes header extensions.

   If SDP Offer/Answer [RFC3264] is supported and used,the negotiation
   for mixed one byte and two bytes extension MUST be negotiated using
   SDP Offer/Answer [RFC3264].  In the absence of negotiations using 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 and two bytes extensions MUST include the attribute
   "a= extmap-allow-mixed " in the SDP offer.  If "a= extmap-allow-mixed
   " is present in the offer SDP, 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 bytes and two bytes
   extensions in the same RTP stream but MAY use one-byte or two-bytes
   form exclusively (see section 4.1.2).




Singer, et al.          Expires February 3, 2018               [Page 12]

Internet-Draft            RTP Header Extensions              August 2017


   When used in [I-D.ietf-mmusic-sdp-bundle-negotiation] this attribute
   is specified as identical category for the
   [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

   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]

   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.





Singer, et al.          Expires February 3, 2018               [Page 13]

Internet-Draft            RTP Header Extensions              August 2017


   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 may offer
   to receive it in a future offer, 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 support this extension yet has no intention of
   sending it now but may offer 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 under use.  A session update MAY add or
   remove extension(s).  Identifiers 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 re-numbering is not permitted either).

   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 them in an extension header.  If needed,
   the offerer or answerer can update the session to assign a valid
   identifier to that extension URI.



Singer, et al.          Expires February 3, 2018               [Page 14]

Internet-Draft            RTP Header Extensions              August 2017


   Rationale: the range 4096-4351 for these negotiation identifiers is
   deliberately restricted to allow expansion of the range of valid
   identifiers in 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 and 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

   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 [I-D.ietf-mmusic-sdp-bundle-negotiation] to bundle
   multiple m-lines the extmap attribute falls under the special
   category of [I-D.ietf-mmusic-sdp-mux-attributes].  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



Singer, et al.          Expires February 3, 2018               [Page 15]

Internet-Draft            RTP Header Extensions              August 2017


   can include different RTP header extensions allowing for example
   audio and video sources to use different sets of RTP header
   extensions.  It SHALL be assumed that for any RTP header extension,
   difference in configuration using any of the <extensionattributes> is
   important and need to be preserved to any receiver, thus requiring
   assignment of different IDs.  Any RTP header extension that does not
   match this assumption MUST explicitly provide rules for what are
   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 are handled as the non-bundled case.  This allows for
   specifying different directionality for each of the repeated
   extension URI in bundled group.

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>




Singer, et al.          Expires February 3, 2018               [Page 16]

Internet-Draft            RTP Header Extensions              August 2017


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.

   Extensions 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 Secure Real-time Transport Protocol (SRTP) [RFC3711] is
   used to protect RTP sessions, the RTP payload can be 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 like DTLS[RFC6347]
   MAY be used.  RTP header extensions can carry sensitive information
   for which participants in multimedia sessions want confidentiality.
   RFC6904 [RFC6904]  provides a mechanism, extending 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 RFC6904 [RFC6904] the encryption stream
   cipher for the header extension is dependent on the chosen SRTP
   cipher.

   Other security options for securing RTP are discussed in [RFC7201].

10.  IANA Considerations

   This document updates the IANA consideration to reference this
   document and adds a new SDP attribute in section 10.3

   Note to IANA : change RFCxxxx to this RFC number and remove the note.

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

   The IANA will also maintain a server that contains all of the
   registered elements in a publicly accessible space.




Singer, et al.          Expires February 3, 2018               [Page 17]

Internet-Draft            RTP Header Extensions              August 2017


   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

      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 review
      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; and

      7.  that the suggested naming URI form is appropriately chosen and
          unique.



Singer, et al.          Expires February 3, 2018               [Page 18]

Internet-Draft            RTP Header Extensions              August 2017


      8.  That for [I-D.ietf-mmusic-sdp-bundle-negotiation] multiplexed
          m-lines, any RTP header extension with difference in
          configurations of <extensionattributes> that do not require
          assignment of different IDs, MUST explicitly indicate this and
          provide rules for what are 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.

10.2.  Registration of the SDP extmap Attribute

   IANA is requested to update the registration of the extmap SDP
   [RFC4566] attribute.

   o  Contact Name and email address: IETF, contacted via
      mmusic@ietf.org, or a successor address designated by IESG
      Attribute Name: extmap

   o  Attribute Syntax: See section 8 of [RFCXXXX].

   o  Attribute Semantics: The details of appropriate values are given
      in [RFC XXXX].

   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  O/A Procedures: See section 7 of [RFCXXXX].

   o  Mux Category: Special.

   o  Reference: [RFCXXXX]

10.3.  Registration of the SDP extmap-allow-mixed Attribute

   The IANA is requested to register one new SDP attribute:

   o  Contact Name and email address: IETF, contacted via
      mmusic@ietf.org, or a successor address designated by IESG.

   o  Attribute Name: extmap-allow-mixed.



Singer, et al.          Expires February 3, 2018               [Page 19]

Internet-Draft            RTP Header Extensions              August 2017


   o  Attribute Syntax: See section 6 of [RFCXXXX].

   o  Attribute Semantics: See section 6 of [RFCXXXX].

   o  Attribute Value: None.

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

   o  O/A Procedures: See section 6 of [RFCXXXX].

   o  Mux Category: Identical

   o  Reference: [RFCXXXX]

11.  Changes from RFC5285

   The major motivation for updating [RFC5285] was to allow having one
   byte and two bytes 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
   specification [RFC3550] and [RFC5285] that the header extension "is
   designed so that the header extension MAY be ignored".  This is
   described in section 4.1.

   The transmission consideration section (4.1.1) adds more text to
   clarify when and how many times to send the RTP header extension to
   provide higher probability of delivery

   >The security section was expanded

   The rest of the changes are editorial.

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



Singer, et al.          Expires February 3, 2018               [Page 20]

Internet-Draft            RTP Header Extensions              August 2017


   two-byte header form.  Magnus Westerlund and Tom Taylor were
   instrumental in managing the registration text.

13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2508]  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
              Headers for Low-Speed Serial Links", RFC 2508,
              DOI 10.17487/RFC2508, February 1999,
              <http://www.rfc-editor.org/info/rfc2508>.

   [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, <http://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,
              <http://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,
              <http://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,
              <http://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, <http://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,
              <http://www.rfc-editor.org/info/rfc5234>.



Singer, et al.          Expires February 3, 2018               [Page 21]

Internet-Draft            RTP Header Extensions              August 2017


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

13.2.  Informative References

   [I-D.ietf-mmusic-sdp-bundle-negotiation]
              Holmberg, C., Alvestrand, H., and C. Jennings,
              "Negotiating Media Multiplexing Using the Session
              Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
              negotiation-38 (work in progress), April 2017.

   [I-D.ietf-mmusic-sdp-mux-attributes]
              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.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <http://www.rfc-editor.org/info/rfc3550>.

   [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, <http://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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc4585>.

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              DOI 10.17487/RFC4588, July 2006,
              <http://www.rfc-editor.org/info/rfc4588>.

   [RFC5109]  Li, A., Ed., "RTP Payload Format for Generic Forward Error
              Correction", RFC 5109, DOI 10.17487/RFC5109, December
              2007, <http://www.rfc-editor.org/info/rfc5109>.




Singer, et al.          Expires February 3, 2018               [Page 22]

Internet-Draft            RTP Header Extensions              August 2017


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

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://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,
              <http://www.rfc-editor.org/info/rfc7201>.

   [RFC7667]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
              DOI 10.17487/RFC7667, November 2015,
              <http://www.rfc-editor.org/info/rfc7667>.

   [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,
              <http://www.rfc-editor.org/info/rfc8126>.

Authors' Addresses

   David Singer
   Apple, Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   USA

   Phone: +1 408 996 1010
   Email: singer@apple.com
   URI:   http://www.apple.com/quicktime


   Harikishan Desineni
   Qualcomm
   10001 Pacific Heights Blvd
   San Diego, CA  92121
   USA

   Phone: +1 858 845 8996
   Email: hdesinen@quicinc.com









Singer, et al.          Expires February 3, 2018               [Page 23]

Internet-Draft            RTP Header Extensions              August 2017


   Roni Even (editor)
   Huawei Technologies
   Tel Aviv
   Israel

   Email: Roni.even@huawei.com













































Singer, et al.          Expires February 3, 2018               [Page 24]