From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5285.txt | 955 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 955 insertions(+) create mode 100644 doc/rfc/rfc5285.txt (limited to 'doc/rfc/rfc5285.txt') 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:["/"] + + + + +Singer & Desineni Standards Track [Page 8] + +RFC 5285 RTP Header Extensions July 2008 + + + where is a URI, as above, 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 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 = + + byte-string = + + SP = + + DIGIT = + +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] + -- cgit v1.2.3