summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5285.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5285.txt')
-rw-r--r--doc/rfc/rfc5285.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc5285.txt b/doc/rfc/rfc5285.txt
new file mode 100644
index 0000000..1dad65f
--- /dev/null
+++ b/doc/rfc/rfc5285.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+ 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 metadata be tied to a specific form of
+ media data.
+
+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 value defined for an RTP extension
+ (defined below for the one-byte and two-byte header forms) 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.
+
+ This specification inherits the requirement from the RTP
+ specification that the header extension "is designed so that the
+ header extension may be ignored". 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, and
+ MUST NOT be used when the presence of the extension has changed the
+ form or nature of the rest of the packet in a way that is not
+ compatible with the way the stream is signaled (e.g., as defined by
+ the payload type). Valid examples might include metadata that is
+ additional to the usual RTP information.
+
+ 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).
+
+ 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.
+
+ 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
+
+
+
+Singer & Desineni Standards Track [Page 3]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+ of local identifiers. Each distinct extension MUST have a unique ID.
+ The value 0 is reserved for padding and MUST NOT be used as a local
+ identifier.
+
+ 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 two-byte
+ headers: they MUST NOT be mixed within a stream. Transmitters SHOULD
+ NOT use the two-byte form when all extensions are small enough for
+ the one-byte header form.
+
+ 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 required), and parsing stops at the earlier
+ of the end of the entire header extension, or, in one-byte headers,
+ 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].
+
+
+
+
+
+Singer & Desineni Standards Track [Page 4]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+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", takes the fixed bit pattern
+ 0xBEDE (the first version of this specification was written on the
+ feast day of the Venerable Bede).
+
+ Each extension element starts 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 should be ignored, processing of the
+ entire extension should terminate at that point, and only the
+ extension elements present prior to the element with ID 15
+ 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.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Singer & Desineni Standards Track [Page 5]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+ An example header extension, with three extension elements, some
+ padding, and including the required RTP fields, 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.3. Two-Byte Header
+
+ In the two-byte header form, the 16-bit value required 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+Singer & Desineni Standards Track [Page 6]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+ 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).
+
+ 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.
+
+ An example header extension, with three extension elements, some
+ padding, and including the required RTP fields, 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 a SIP offer/
+ answer exchange using SDP. 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 offer/answer 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
+
+
+
+
+
+
+Singer & Desineni Standards Track [Page 7]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+ 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 are not required
+ 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
+ declarations for a single stream at media level. (The same extension
+ may, of course, be used for several streams, and may appear
+ differently parameterized 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 for each stream type for a given media,
+ or for the session for session-level declarations.
+
+ Each local identifier potentially used in the stream is mapped to a
+ string using an attribute of the form:
+
+ a=extmap:<value>["/"<direction>] <URI> <extensionattributes>
+
+
+
+
+Singer & Desineni Standards Track [Page 8]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+ where <URI> is a URI, as above, <value> is the local identifier (ID)
+ of this extension and is an integer in the valid range inclusive (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).
+
+ 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
+
+ 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 indicated above.
+
+6. Offer/Answer
+
+ The simple signaling described above may be enhanced in an offer/
+ answer 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". A "sendonly" direction
+ indicates an ability to send; a "recvonly" direction indicates a
+ desire to receive; a "sendrecv" direction indicates both. An
+ "inactive" direction indicates neither, but later re-negotiation may
+ make an extension active.
+
+ 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).
+
+
+
+
+
+
+Singer & Desineni Standards Track [Page 9]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+ 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 may be
+ modified to modify or add direction qualifiers for that extension.
+ 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.
+
+ 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.
+
+ 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). 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 (unusable) 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.
+
+
+
+
+
+
+
+
+Singer & Desineni Standards Track [Page 10]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+ It is always allowed to place the offered identifier value "as is" in
+ the SDP answer (for example, due to lack of a free identifier value
+ in the valid range). Extensions with an identifier outside the valid
+ range cannot, of course, be used. If required, the offerer or
+ answerer can update the session to make space for such an extension.
+
+ 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
+
+
+
+
+
+
+Singer & Desineni Standards Track [Page 11]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+7. 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 may be several.
+
+ extmap = mapentry SP extensionname [SP extensionattributes]
+
+ extensionname = URI
+
+ direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"
+
+ mapentry = "extmap:" 1*5DIGIT ["/" direction]
+
+ extensionattributes = byte-string
+
+ URI = <Defined in RFC 3986>
+
+ byte-string = <Defined in RFC 4566>
+
+ SP = <Defined in RFC 5234>
+
+ DIGIT = <Defined in RFC 5234>
+
+8. Security Considerations
+
+ This defines only a place to transmit information; the security
+ implications of the extensions must be discussed with those
+ extensions.
+
+ 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.
+
+ 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 may be both encrypted
+ and integrity protected, while the RTP header is either unprotected
+ or integrity protected. Therefore, it is inappropriate to place
+ information in header extensions that cause security problems if
+ disclosed, unless the entire RTP packet is protected by a lower-layer
+ security protocol providing both confidentiality and integrity
+ capability.
+
+
+
+
+
+Singer & Desineni Standards Track [Page 12]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+9. IANA Considerations
+
+9.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 [RFC5226].
+
+ The IANA will also maintain a server that contains all of the
+ registered elements in a publicly accessible space.
+
+ Here is the formal declaration required by 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 is recommended to 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 extensions (notably, that the stream
+ is still decodable if the extension is ignored or not
+ recognized);
+
+ 3. that the extension specification is technically consistent (in
+ itself and with RTP), complete, and comprehensible;
+
+
+
+
+
+
+Singer & Desineni Standards Track [Page 13]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+ 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.
+
+ 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.
+
+9.2. Registration of the SDP extmap Attribute
+
+ This section contains the information required by [RFC4566] for an
+ SDP attribute.
+
+ o contact name, email address, and telephone number:
+
+ D. Singer
+ singer@apple.com
+ +1 408-974-3162
+
+ o attribute name (as it will appear in SDP): extmap
+
+ o long-form attribute name in English: 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:
+ not subject to the charset attribute
+
+ 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: see RFC 5285.
+
+
+
+Singer & Desineni Standards Track [Page 14]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+10. 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
+ two-byte header form. Magnus Westerlund and Tom Taylor were
+ instrumental in managing the registration text.
+
+11. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
+ Headers for Low-Speed Serial Links", RFC 2508,
+ February 1999.
+
+ [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, July 2001.
+
+ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", STD 64, RFC 3550, July 2003.
+
+ [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
+ IETF URN Sub-namespace for Registered Protocol
+ Parameters", BCP 73, RFC 3553, June 2003.
+
+ [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+ RFC 3711, March 2004.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, January 2005.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+
+
+
+
+
+Singer & Desineni Standards Track [Page 15]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+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
+ 5775 Morehouse Drive
+ San Diego, CA 92126
+ USA
+
+ Phone: +1 858 845 8996
+ EMail: hd@qualcomm.com
+ URI: http://www.qualcomm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Singer & Desineni Standards Track [Page 16]
+
+RFC 5285 RTP Header Extensions July 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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, THE IETF TRUST 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.
+
+Intellectual Property
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Singer & Desineni Standards Track [Page 17]
+