Internet Engineering Task Force INTERNET-DRAFT D. Singer draft-singer-rtp-hdrext-00.doc Apple Computer May 25 2005 Expires: Nov 25 2005 A general mechanism for RTP Header Extensions IPR Notice 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. Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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 RFC 2119. Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). D. Singer [Page 1]
Internet Draft draft-singer-rtp-hdrext-01.doc May 25 2005 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. 1 Introduction In the RTP specification [1] 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 D. Singer [Page 2]
Internet Draft draft-singer-rtp-hdrext-01.doc May 25 2005 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 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. 2 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. 3 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 signaled out-of-band (see below for a suggested 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 signaling which is the definitive indication that this header extension is present. The 16-bit identifier takes the fixed bit pattern 0xBEDE. 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 are mapped to a larger namespace in the 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... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D. Singer [Page 3]
Internet Draft draft-singer-rtp-hdrext-01.doc May 25 2005 | .... | 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 defined out-of-band (see below) in some kind of signaling. 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). 4 Signalling Design The map of the local identifiers used in the packets to a larger un- allocated namespace is performed in the session signaling. The universe of possible names is identified by reversed domain-names (as used in Java, for example). An example name (this is only an example) might be "org.ietf.avt.rtp.transmittime". 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 <name>:<value> where <name> is a reversed domain name, and value is an integer in the range 1-14 inclusive (0 and 15 are reserved, as noted above). Example: a=EXTMAP org.ietf.avt.rtp.toffset:1 a=EXTMAP org.smpte.12M:2 It is the presence of the EXTMAP attribute(s) which is diagnostic D. Singer [Page 4]
Internet Draft draft-singer-rtp-hdrext-01.doc May 25 2005 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" are reserved to the IETF and MUST be documented in RFCs. 5 Transmission Offset This specification defines only one extension element. The name is "org.ietf.avt.rtp.toffset". 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. 6 Security Considerations This defines only a place to transmit information; the security implications of the extensions must be discussed with those extensions. 6 IANA Considerations Potentially management of the "ietf.org" namespace. 7 RFC Editor Considerations None. 8 Full Copyright Statement Copyright (C) The Internet Society (2005). 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. 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 D. Singer [Page 5]
Internet Draft draft-singer-rtp-hdrext-01.doc May 25 2005 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. 9 Intellectual Property Notice 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. 10 References [RTP] RFC3550, STD0064, RTP: A Transport Protocol for Real-Time Applications, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, July 2003 Acknowledgments Both Brian Link and John Lazzaro provided helpful comments on an initial draft. D. Singer [Page 6]
Internet Draft draft-singer-rtp-hdrext-01.doc May 25 2005 Authors' Contact Information David Singer Apple Computer, Inc. One Infinite Loop, MS:302-3MT Cupertino CA 95014 USA Email: singer@apple.com Tel: +1 408 974 3162 Dates Written: May 25 2005 Expires: Nov 25 2005 D. Singer [Page 7]