A General Mechanism for RTP Header Extensions
RFC 5285
Document | Type |
RFC - Proposed Standard
(July 2008; No errata)
Obsoleted by RFC 8285
|
|
---|---|---|---|
Authors | HariKishan Desineni , David Singer | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5285 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Cullen Jennings | ||
Send notices to | mmusic-chairs@ietf.org |
Network Working Group D. Singer Request for Comments: 5285 Apple, Inc. Category: Standards Track H. Desineni Qualcomm July 2008 A General Mechanism for RTP Header Extensions Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Packet Design . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. One-Byte Header . . . . . . . . . . . . . . . . . . . . . 5 4.3. Two-Byte Header . . . . . . . . . . . . . . . . . . . . . 6 5. SDP Signaling Design . . . . . . . . . . . . . . . . . . . . . 7 6. Offer/Answer . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. BNF Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9.1. Identifier Space for IANA to Manage . . . . . . . . . . . 13 9.2. Registration of the SDP extmap Attribute . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Singer & Desineni Standards Track [Page 1] RFC 5285 RTP Header Extensions July 2008 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. 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. 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 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. Singer & Desineni Standards Track [Page 2]Show full document text