A General Mechanism for RTP Header Extensions
obsoletes
- rfc-5285 — A General Mechanism for RTP Header Extensions
Extracted elements (26)
The extended range 4096-4351 for negotiation identifiers is deliberately restricted to allow future expansion of the valid identifier range. Multiple extensions with the same identifier in this range may be offered as mutually exclusive alternatives.
The mechanism allows multiple identified extensions in a single RTP packet using URIs as names, removing RFC 3550's limitation of one extension per packet and providing a decentralized registration approach to avoid collisions.
URIs are used to name extensions because they provide a large, unallocated namespace and give documentation on the extension. URIs do not need to be dereferenceable, permitting confidential or experimental use and continued use after an organization ceases to exist.
Use of RTP header extensions reduces the efficiency of RTP header compression (e.g., RFC 2508, RFC 3095) because the header extension is sent uncompressed unless the compression module is updated. Intermittent extension presence can also require updates to the fixed header, further reducing compression efficiency.
A stream MUST contain only one-byte headers or only two-byte headers unless it is known that all recipients support mixing, negotiated via SDP Offer/Answer or out-of-band knowledge.
A usable mapping MUST use IDs in the valid range, and each ID MUST be used only once per media section. An extension URI with the same attributes MUST NOT appear more than once applying to the same stream.
For extensions defined in RFCs, the URI used SHOULD be a URN starting with 'urn:ietf:params:rtp-hdrext:' followed by a registered, descriptive name.
If an extension is marked 'sendonly' and the answerer desires to receive it, the extension MUST be marked 'recvonly' in the SDP answer. An answerer with no desire to receive the extension SHOULD remove it from the answer.
In the one-byte header form, the local identifier value 15 is reserved and MUST NOT be used. If ID 15 is encountered, its length field MUST be ignored, and processing of the entire extension MUST terminate at that point.
Local identifiers MUST be unique in an RTP session, and the same identifier MUST be used for the same offered extension in the answer. Identifier values in the valid range MUST NOT be altered (remapped) during session updates.
Local identifiers present in the stream MUST have been negotiated or defined out of band. Each distinct extension MUST have a unique ID. The ID value 0 is reserved for padding and MUST NOT be used as a local identifier.
RTP header extensions MUST NOT be used to extend RTP itself in a backward-incompatible manner; they MAY carry metadata in addition to normal RTP header information, provided the RTP layer can function if that metadata is missing.
The mapping of local identifiers to extensions MUST be performed out of band (e.g., via SDP). Each extension URI MUST be absolute, and URIs containing a domain name SHOULD also contain a month-date in the form mmyyyy.
The one-byte header form MUST be supported by all receivers. Transmitters SHOULD NOT use the two-byte header form when all extensions are small enough for the one-byte header form.
The RTP header extension SHOULD only be present in a packet if that packet also contains one or more extension elements; an extension element SHOULD only be present when needed.
When SDP Offer/Answer is used, negotiation for mixed one-byte and two-byte extensions MUST use SDP Offer/Answer. Without such negotiation (e.g., declarative SDP), mixed headers MUST NOT occur unless all recipients are known to support this mode.
The 'a=extmap-allow-mixed' SDP attribute (no value) signals that a participant supports receiving mixed one-byte and two-byte header extensions in the same RTP stream. A participant proposing this mode SHALL itself support reception of mixed extensions.
The appbits field in the two-byte header is a 4-bit application-dependent field treated as a special extension assigned to local identifier 256. If no extension is specified for ID 256, the sender SHOULD set appbits to 0 and the receiver MUST ignore it.
The SDP 'extmap' attribute maps local extension IDs to URIs: 'a=extmap:<value>["/<direction>"] <URI> <extensionattributes>'. Direction is one of sendonly, recvonly, sendrecv, or inactive.
IANA manages the 'RTP Compact Header Extensions' registry mapping extension naming URIs to specifications, requiring Expert Review for insertion. The registry includes the extension URI, a formal reference to the specification, a descriptive phrase, and contact information.
IANA registered the new SDP 'extmap-allow-mixed' attribute in the SDP Parameters registry (session and media level, no value, MUX Category IDENTICAL), enabling negotiation of mixed one-byte and two-byte header extensions in the same RTP stream.
IANA registered the SDP 'extmap' attribute in the 'att-field (both session and media level)' subregistry of the SDP Parameters registry, with MUX Category SPECIAL.
Extension usage is negotiated using SDP Offer/Answer, so integrity protection and end-to-end authentication MUST be implemented per RFC 3264 to prevent extension-usage blocking. Integrity protection SHOULD be used to prevent DoS attacks such as modification of header extensions.
RTP header extensions can carry sensitive information for which confidentiality may be required. RFC 6904 provides a mechanism to selectively encrypt RTP header extensions in SRTP; lower-layer security via DTLS MAY also be used.
One-byte header form uses a magic value of 0xBEDE in the RTP 'defined by profile' 16-bit field. Each extension element starts with a 1-byte header containing a 4-bit ID (range 1-14) and a 4-bit length field (value is length-minus-one, so 0 means 1 byte of data, 15 means 16 bytes).
Two-byte header form uses 0x100 (upper 12 bits) in the RTP 'defined by profile' field, with 4 application-dependent bits (appbits). Each extension element has an 8-bit ID (range 1-255) and an 8-bit length field (actual byte count, not minus-one; 0 means no subsequent data).