A General Mechanism for RTP Header Extensions
obsoleted by
- rfc-8285 — A General Mechanism for RTP Header Extensions
Extracted elements (23)
The existing RFC 3550 header extension mechanism permits only one extension per RTP packet and gives no guidance on allocating 16-bit identifiers to avoid collisions. RFC 5285 removes both drawbacks by defining a backward-compatible multi-element extension format named by URIs, with SDP signaling to map URIs to the compact local identifiers carried in packets.
The one-byte header length field encodes (actual_length − 1), allowing values 1–16 bytes rather than 0–15. This specifically enables carriage of 16-byte payloads (a common length for labels and identifiers) at the cost of losing the ability to represent zero-length values, which would often require padding anyway.
The range 4096–4351 is reserved for negotiation identifiers (mutually exclusive alternatives or overflow offers) and is deliberately restricted in size to allow expansion of the valid identifier range in future specifications.
URIs are used to name extensions to provide a large, unallocated namespace and to give documentation on the extension. URIs are not required to be de-referencable, to permit confidential or experimental use and to handle the case where the defining organization ceases to exist.
Extensions marked with a direction incompatible with the stream direction are an error (e.g., a sendonly extension attribute on a recvonly stream). An answerer that does not understand or does not wish to use an offered extension SHOULD remove it from the SDP answer rather than retaining it.
Use of RTP header extensions reduces header compression efficiency because the extension is sent uncompressed unless the compression module is updated. Intermittent use of extensions (present in some packets but not others) further degrades compression by requiring updates to the fixed header portion.
During offer/answer, if an extension is marked sendonly and the answerer desires to receive it, the extension MUST be marked recvonly in the SDP answer. If marked recvonly and the answerer desires to send it, the extension MUST be marked sendonly in the answer. Identifier values in the valid range MUST NOT be altered (remapped) during a session update.
Each extension is named by a URI that MUST be absolute and precisely identifies the format and meaning of the extension. URIs containing a domain name SHOULD also contain a month-date in the form mmyyyy. The definition and URI assignment MUST have been authorized by the domain name owner on or very close to that date.
Extension definitions MUST be either all session-level or all media-level in SDP; mixing the two styles is not permitted. An extension URI with the same attributes MUST NOT appear more than once applying to the same stream.
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 incompatible with the signaled stream.
In the one-byte header form, the local identifier value 15 is reserved for future extension and MUST NOT be used as an identifier. If ID 15 is encountered, its length field should be ignored and processing of the entire extension should terminate at that point.
In the two-byte header form, if no extension has been specified for local identifier 256, the appbits field SHOULD be set to all 0s by the sender and MUST be ignored by the receiver.
The indication of the presence of this extension and the mapping of local identifiers to a larger namespace MUST be performed out-of-band (e.g., via SDP). A usable mapping MUST use IDs in the valid range, and each ID MUST be used only once per media (or per session for session-level mappings).
The local identifiers present in the stream MUST have been negotiated or defined out-of-band. There are no static allocations 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.
The one-byte header form 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.
Padding bytes have the value 0 and may be placed between extension elements or after the last element to pad to a 32-bit boundary. A padding byte does not supply an element ID or length; when encountered, the parser skips it and continues to the next byte.
The SDP extmap attribute maps a local integer ID to an extension URI with an optional direction qualifier: 'a=extmap:<value>["/"<direction>] <URI> <extensionattributes>'. Direction is one of sendonly, recvonly, sendrecv, or inactive, and inherits from the stream direction when omitted.
IANA manages the 'RTP Compact Header Extensions' registry, which maps extension naming URIs to publicly available specifications. Registration requires Expert Review verifying public availability, RTP compliance, technical consistency, non-duplication, a security analysis, general applicability, and URI uniqueness. Initial assignments: none.
The SDP attribute 'extmap' is registered with IANA per RFC 4566. It is applicable at both session and media level, is not subject to the charset attribute, and defines the mapping from extension numbers used in packet headers to extension names registered in the RTP Compact Header Extensions registry.
Header extensions have the same security coverage as the RTP header itself. When SRTP is used, the RTP payload may be encrypted and integrity protected while the header is at most integrity protected. Therefore, placing sensitive information in header extensions is inappropriate unless the entire RTP packet is protected by a lower-layer protocol providing both confidentiality and integrity.
This specification defines only a mechanism for transmitting information in RTP header extensions; the security implications of any specific extension must be analyzed with that extension's own specification. Extension designers must ensure that even extracted information does not cause security concerns.
The one-byte header form uses the 16-bit profile-defined field value 0xBEDE. Each extension element begins with a 1-byte header: 4-bit ID (range 1–14) and 4-bit length field encoding (actual_data_length − 1), allowing 1–16 bytes of data per element.
The two-byte header form uses the 16-bit profile-defined field value 0x1000 | appbits, where appbits is a 4-bit application-dependent field treated as local identifier 256. Each extension element has an 8-bit ID (range 1–255) and an 8-bit length field encoding the exact data length in bytes (0 means no data).