[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: December 7, 2006                                   June 5, 2006


             A general mechanism for RTP Header Extensions
                    draft-ietf-avt-rtp-hdrext-02.txt

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

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 7, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document provides a general mechanism to use the header-
   extension feature of RTP (the Real Time 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 December 7, 2006                [Page 1]

Internet-Draft            RTP Header Extensions                June 2006


Table of Contents

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































Singer                  Expires December 7, 2006                [Page 2]

Internet-Draft            RTP Header Extensions                June 2006


1.  Introduction

   In the RTP specification [RFC3550] there is provision for header
   extensions.  The following text is drawn from that specification for
   the convenience of readers.

   * * * * * * * * * * * * * *

   5.3.1 RTP Header Extension

   An extension mechanism is provided to allow individual
   implementations to experiment with new payload-format-independent
   functions that require additional information to be carried in the
   RTP data packet header.  This mechanism is designed so that the
   header extension may be ignored by other interoperating
   implementations that have not been extended.

   Note that this header extension is intended only for limited use.
   Most potential uses of this mechanism would be better done another
   way, using the methods described in the previous section.  For
   example, a profile-specific extension to the fixed header is less
   expensive to process because it is not conditional nor in a variable
   location.  Additional information required for a particular payload
   format SHOULD NOT use this header extension, but SHOULD be carried in
   the payload section of the packet.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      defined by profile       |           length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        header extension                       |
      |                             ....                              |


   If the X bit in the RTP header is one, a variable-length header
   extension MUST be appended to the RTP header, following the CSRC list
   if present.  The header extension contains a 16-bit length field that
   counts the number of 32-bit words in the extension, excluding the
   four-octet extension header (therefore zero is a valid length).  Only
   a single extension can be appended to the RTP data header.  To allow
   multiple interoperating implementations to each experiment
   independently with different header extensions, or to allow a
   particular implementation to experiment with more than one type of
   header extension, the first 16 bits of the header extension are left
   open for distinguishing identifiers or parameters.  The format of
   these 16 bits is to be defined by the profile specification under
   which the implementations are operating.  This RTP specification does



Singer                  Expires December 7, 2006                [Page 3]

Internet-Draft            RTP Header Extensions                June 2006


   not define any header extensions itself.

   * * * * * * * * * * * * * *

   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 December 7, 2006                [Page 4]

Internet-Draft            RTP Header Extensions                June 2006


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














































Singer                  Expires December 7, 2006                [Page 5]

Internet-Draft            RTP Header Extensions                June 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
   requirements.

   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 December 7, 2006                [Page 6]

Internet-Draft            RTP Header Extensions                June 2006


4.  Packet Design

   The following design is fit into the "header extension" of the RTP
   extension, as shown above.  The presence and format of this header
   extension is negotiated 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 which is the definitive
   indication that this header extension is present.  The 16-bit
   identifier takes the fixed bit pattern 0xBEDE (the first draft of
   this specification was written on the feast day of the Venerable
   Bede).

   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; the values 0
   and 15 are reserved and MUST NOT be used.  The remaining values
   present in the stream MUST have been negotiated out-of-band.  There
   are no static allocations of identifiers.

   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 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.  These
   padding bytes MUST have the value zero (0).






Singer                  Expires December 7, 2006                [Page 7]

Internet-Draft            RTP Header Extensions                June 2006


5.  SDP Signalling Design

   The map of the local identifiers used in the packets to a larger un-
   allocated namespace may be performed in the session signaling.  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

   "org.example.avt.rtp.transmittime/082005".

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

   Example:

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

   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 December 7, 2006                [Page 8]

Internet-Draft            RTP Header Extensions                June 2006


6.  Transmission offset

   This specification defines only one extension element.  The name is
   "org.ietf.avt.rtp.toffset/082005".  The value is a fixed 24-bit
   signed integer.  In the case when the sender knows that it is not
   transmitting the RTP packets strictly according to their relative RTP
   timestamps, this extension element may be used to indicate the
   "effective" RTP transmission time of the packet, on the RTP
   timescale.  The value is added to the RTP timestamp of the packet to
   give the RTP time of transmission.

   There are no extension attributes defined for this name.







































Singer                  Expires December 7, 2006                [Page 9]

Internet-Draft            RTP Header Extensions                June 2006


7.  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 defined by the specification that defines a
   specific extension name.

     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























Singer                  Expires December 7, 2006               [Page 10]

Internet-Draft            RTP Header Extensions                June 2006


8.  Security Considerations

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














































Singer                  Expires December 7, 2006               [Page 11]

Internet-Draft            RTP Header Extensions                June 2006


9.  IANA Considerations

9.1.  New spaces for IANA to manage

   IANA needs to manage the extension names that start with "org.ietf"
   or "arpa".  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.

9.2.  Registration of the transmit-time offset

   The first registration within the IETF/IANA space is as documented
   above.  The registered name is "org.ietf.avt.rtp.toffset/082005",
   associated with this specification.

9.3.  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 "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 December 7, 2006               [Page 12]

Internet-Draft            RTP Header Extensions                June 2006


10.  RFC Editor Considerations

   None.
















































Singer                  Expires December 7, 2006               [Page 13]

Internet-Draft            RTP Header Extensions                June 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 December 7, 2006               [Page 14]

Internet-Draft            RTP Header Extensions                June 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
      rationale


11.  References

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

   [RFC2327]  Handley, M. and V. Jacobson, "SDP: Session Description
              Protocol", RFC 2327, April 1998.

   [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 December 7, 2006               [Page 15]

Internet-Draft            RTP Header Extensions                June 2006


Author's Address

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

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









































Singer                  Expires December 7, 2006               [Page 16]

Internet-Draft            RTP Header Extensions                June 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
   http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


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.


Acknowledgment

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




Singer                  Expires December 7, 2006               [Page 17]


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