[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 5285

AVT                                                            D. Singer
Internet-Draft                                       Apple Computer Inc.
Expires: February 16, 2007                               August 15, 2006

             A general mechanism for RTP Header Extensions

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on February 16, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   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
   unregistered.  The actual extensions in use in a session are signaled
   in the setup information for that session.

Singer                  Expires February 16, 2007               [Page 1]

Internet-Draft            RTP Header Extensions              August 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Design Goals . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Packet Design  . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  SDP Signalling Design  . . . . . . . . . . . . . . . . . . . .  8
   6.  BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  New spaces for IANA to manage  . . . . . . . . . . . . . . 12
     8.2.  Registration of the SDP extmap attribute . . . . . . . . . 12
   9.  RFC Editor Considerations  . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 14
   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17

Singer                  Expires February 16, 2007               [Page 2]

Internet-Draft            RTP Header Extensions              August 2006

1.  Introduction

   In the RTP specification [RFC3550] there is provision for header
   extensions in section 5.3.1.

   It permits at most one extension in a given packet; the extension has
   a length in 32-bit words, and there is a 16-bit identifier 'defined
   by profile' to identify the extension in use.

   This mechanism has two conspicuous drawbacks: only one extension is
   possible, and there is no documentation of how the 16-bit identifiers
   are allocated.

Singer                  Expires February 16, 2007               [Page 3]

Internet-Draft            RTP Header Extensions              August 2006

2.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Singer                  Expires February 16, 2007               [Page 4]

Internet-Draft            RTP Header Extensions              August 2006

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 is required to
   extract the metadata.  Also, depending on the media format, the
   metadata may need to be added at the time of encoding the media so
   that the bit-rate required for the metadata is taken into account.
   But the metadata may not be known at that time.  Inserting metadata
   at a later time can require a decode and re-encode to meet bit-rate

   In some cases a more appropriate, higher level mechanism may be
   available, and if so, it should 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 meta-data be tied to a specific form
   of media data.

Singer                  Expires February 16, 2007               [Page 5]

Internet-Draft            RTP Header Extensions              August 2006

4.  Packet Design

   The following design is fit into the "header extension" of the RTP
   extension, as described above.  The presence and format of this
   header extension is negotiated or defined out-of-band, such as
   through signaling (see below for SDP signaling), and therefore the
   "identifier" used above is only defined here for diagnostic and
   cross-check purposes (e.g. by network analyzers); it is the
   negotiation/definition which is the definitive indication that this
   header extension is present.  For this specification the 16-bit value
   required by the RTP specification for a header extension, labelled in
   the RTP specification as "defined by profile", takes the fixed bit
   pattern 0xBEDE (the first draft of this specification was written on
   the feast day of the Venerable Bede).

   The RTP specification states that the header extension "is designed
   so that the header extension may be ignored".  This specification
   therefore inherits this requirement.  To be specific, header
   extensions using this specification MUST only be used for data that
   can safely be ignored by the recipient without affecting
   interoperability.  Examples might include meta-data that is
   additional to the usual RTP information.

   The header extension is formed of a set of extension elements.  Each
   extension element has a local identifier and a length.  Since it is
   expected that (a) the number of extensions in any given RTP session
   is small and (b) the extensions themselves are small, only 4 bits are
   allocated to each of these.  The local identifiers may be mapped to a
   larger namespace in the negotation (e.g. session signaling).

   The form of the header extension block is as 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
      |  ID   |  len  |           extension element bytes...          |
      |                             ....                              |

   The 4-bit ID is the local identifier of this element in the range
   1-14 inclusive.  The values present in the stream MUST have been
   negotiated or defined out-of-band.  There are no static allocations
   of identifiers.

   The value 0 is reserved for padding and MUST NOT be used as an
   identifier.  The value 15 is reserved for future extension and MUST
   NOT be used as an identifier.  If the value 15 is encountered,

Singer                  Expires February 16, 2007               [Page 6]

Internet-Draft            RTP Header Extensions              August 2006

   processing of the extension should terminate at that point, and only
   the extension elements present prior to the ID=15 considered.

   The 4-bit length is the length minus one of the data bytes of this
   header extension element (excluding this 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.

   There are as many extension elements as fit into the length as
   indicated in the RTP header-extension length.  Since the RTP header
   extension length is signaled in full 32-bit words, padding bytes are
   placed after the last extension element to pad to a 32-bit boundary.

   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, as needed to pad to full 32-bit words.  Note that
   in this special case the length of the following data is not 1 byte,
   but 0 bytes.

   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 may be present in some packets,
   not that they are in fact present in all (or indeed, any) packets.

Singer                  Expires February 16, 2007               [Page 7]

Internet-Draft            RTP Header Extensions              August 2006

5.  SDP Signalling Design

   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 a SIP offer/answer exchange using SDP.  This section defines such
   signaling in SDP.

   The universe of possible names is identified by reversed domain-names
   (as used in Java, for example), combined with a month-date in the
   form mmyyyy.  That date MUST be near the time of the definition of
   the extension, and it MUST be true that the extension was defined in
   a way authorized by the owner of the domain at that date.  (This
   avoids problems when domain names change ownership).

   An example name (this is only an example) might be


   The mapping may be provided per media-stream (in the media-specific
   section of SDP, i.e. after an "m=" line) or globally for all streams
   (i.e. before the first "m=" line).  The definitions MUST be either
   all global or all local; it is not permitted to mix the two styles.

   Each local identifier potentially used in the stream is mapped to a
   string using an attribute of the form:

   a=extmap:<value> <name>/<month>

   where <name> is a reversed domain name, <value> is the local
   identifier (ID) of this extension, and is an integer in the range
   1-14 inclusive (0 and 15 are reserved, as noted above), and <month>
   takes the form of a 6-digit number mmyyyy.


   a=extmap:1 org.example.avt.rtp.toffset/082005

   a=extmap:2 org.ietf.avt.smpte12M/022006

   When SDP signaling is used for the RTP session, it is the presence of
   the 'extmap' attribute(s) which is diagnostic that this style of
   header extensions is used, not the magic number indicated above.

   Rationale: the use of reversed domain names provides for a large,
   unallocated space, while still giving some clue as to what
   organization or body is responsible for the definition of the

Singer                  Expires February 16, 2007               [Page 8]

Internet-Draft            RTP Header Extensions              August 2006

   Extension names starting with "org.ietf" and "arpa." are reserved to
   the IETF and MUST be documented in RFCs, and registered with IANA.

Singer                  Expires February 16, 2007               [Page 9]

Internet-Draft            RTP Header Extensions              August 2006

6.  BNF Syntax

   The syntax element 'hostname' is as defined in [RFC2396], except that
   (a) numeric hostnames are not permitted and (b) the name is in
   reverse order (e.g. "com.example.multimedia.tag").  The syntax
   element 'extmap' is an attribute as defined in [RFC2327].
   Extensionattributes are not defined here, but by the defined by the
   specification that defines a specific extension name; there may be
   several, separated by spaces.

     digit = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"

     month = "01"|"02"|"03"|"04"|"05|"06"|"07"|"08"|"09"|"10|"11"|"12"

     year = digit digit digit digit

     date = month year

     integer = digit *(digit)

     space = " "

     extensionname = hostname "/" date

     mapentry = "extmap" ":" integer

     mapattrs = (space extensionattributes)

     extmap = mapentry space extensionname mapattrs

Singer                  Expires February 16, 2007              [Page 10]

Internet-Draft            RTP Header Extensions              August 2006

7.  Security Considerations

   This defines only a place to transmit information; the security
   implications of the extensions must be discussed with those

   Care should be taken when defining extensions.  Clearly, they should
   be solely informative, but even when the information is extracted,
   should not cause security concerns.

Singer                  Expires February 16, 2007              [Page 11]

Internet-Draft            RTP Header Extensions              August 2006

8.  IANA Considerations

8.1.  New spaces for IANA to manage

   IANA needs to manage the extension names for this extension that
   start with "org.ietf" or "arpa" ("The IETF Generic RTP header
   extension registry").  Any use of a name with these prefixes MUST be
   documented in a standards-track RFC which defines both the name and
   the format of the data.  IANA manages the registration by documenting
   the association of name to RFC number.

   Names drawn from other spaces are managed outside both the IETF and
   IANA, and the handling of registration and documentation is the
   responsibility of the owner of the internet domain name as of the
   date specified in the registration.

8.2.  Registration of the SDP extmap attribute

   This section contains the information required by [RFC2327] (which is
   identical to that required by draft-ietf-mmusic-sdp-new-26.txt) for
   an SDP attribute.

   o  contact name, email address and telephone number: are as indicated
      for this document

   o  attribute-name (as it will appear in SDP): is 'extmap' (without
      the quotation marks)

   o  long-form attribute name in English: is "generic header extension
      map definition"

   o  type of attribute (session level, media level, or both): both

   o  whether the attribute value is subject to the charset attribute:
      no, it is not

   o  a one paragraph explanation of the purpose of the attribute: This
      attribute defines the mapping from the extension numbers used in
      packet headers into extension names as documented in
      specifications and appropriately registered.

   o  a specification of appropriate attribute values for this
      attribute: is as defined in this document

Singer                  Expires February 16, 2007              [Page 12]

Internet-Draft            RTP Header Extensions              August 2006

9.  RFC Editor Considerations


Singer                  Expires February 16, 2007              [Page 13]

Internet-Draft            RTP Header Extensions              August 2006

Appendix A.  Acknowledgments

   Both Brian Link and John Lazzaro provided helpful comments on an
   initial draft.  Colin Perkins was helpful in reviewing and dealing
   with the details.

Singer                  Expires February 16, 2007              [Page 14]

Internet-Draft            RTP Header Extensions              August 2006

Appendix B.  Change History

   o  August 2005: 00 Draft-avt-rtp-hdrext made from
      draft-singer-rtp-hdrext; added requirement for dates in DNS names

   o  January 2006: 01 Updated to XML2RFC, inserted BNF, other cleanup;
      IANA considerations cleaned

   o  June 2006: 02 Made the signaling optional, and indicate only that
      the presence of the extensions must be negotiated somehow; more

   o  June 2006: 03 Fixed small error in the BNF

   o  August 2006: 04 Transmit offsets to a separate draft; other tidy-
      ups; allow padding between elements

10.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2327]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC2396]  Berners-Lee, MT., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", RFC 3550, STD 0064, July 2003.

Singer                  Expires February 16, 2007              [Page 15]

Internet-Draft            RTP Header Extensions              August 2006

Author's Address

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

   Phone: +1 408 996 1010
   Email: singer@apple.com

Singer                  Expires February 16, 2007              [Page 16]

Internet-Draft            RTP Header Extensions              August 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Singer                  Expires February 16, 2007              [Page 17]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/