RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items
updated by
Extracted elements (23)
Including SDES CNAME in an RTP header extension complements RFC 6051 (Rapid Synchronisation of RTP Flows), which carries SR clock information but assumes CNAME binding is already known. Combining both extensions enables rapid synchronization in all cases, including when CNAME is not pre-established via signaling.
Not all SDES items are appropriate for RTP header extension transport. Items like NAME and LOC are privacy-sensitive and have no use case requiring them at the time the first RTP packets arrive, so only items with timeliness requirements (e.g., CNAME) are registered for use with this header extension.
RTP header extensions provide two advantages over non-regular RTCP for SDES delivery: fate sharing (the SDES item arrives if and only if the media data arrives) and deterministic delivery ordering relative to media data. RTCP packets lack sequence numbers and delivery feedback mechanisms, making confirmed delivery difficult.
SDES items are placed in RTP header extensions to speed up delivery when a new SSRC joins a session, enabling receivers to determine synchronization context before the first RTCP interval. This is particularly valuable for CNAME, which is needed to synchronize related RTP streams and cannot wait for the regular RTCP transmission schedule.
The number of header extension repetitions should be tailored to achieve a desired delivery probability given the expected packet loss rate P, using the formula 1-P^N for N repetitions. For point-to-point or small receiver populations, RTCP feedback (XR Loss RLE, NACK) can be used to stop repetitions once delivery is confirmed.
The RFC 5285 header extension specification does not allow mixing one-byte and two-byte headers for the same RTP stream (SSRC). RTP middleboxes must consider all potential header extensions and known SDES item sizes when selecting the header format for outgoing streams.
Update flaps can occur when SDES item values change and arrive via both RTCP and RTP header extensions due to packet reordering or different code paths. Receivers should use the RTP extended sequence number and RTCP SR timestamp to determine which update is more recent before applying a new value.
When ROHC (RFC 5225) header compression is used with RTP, the header extension data itself is not compressed, but the extension indicator (X) bit in the RTP header is compressed and classified as rarely changing. Frequent use of header extensions may degrade header compression efficiency.
Any registration in the RTP SDES Compact Header Extensions sub-registry using a URI starting with 'urn:ietf:params:rtp-hdrext:sdes:' MUST also have a registered Source Description item in the 'RTP SDES item types' registry, and security and privacy considerations MUST be provided.
If any SDES item requires the two-byte header format, then all other header extensions for the same RTP stream (SSRC) MUST also use the two-byte header format, since RFC 5285 does not permit mixing one-byte and two-byte headers for the same SSRC.
In RTP sessions where confidentiality protection is enabled for RTCP, the SDES item header extensions MUST also be protected using encrypted header extensions per RFC 6904 (SRTP encrypted header extensions).
SDES items carried as RTP header extensions MUST use commensurate strength algorithms and SHOULD use the same cryptographic primitives (algorithms, modes) as applied to RTCP packets carrying corresponding SDES items.
The one-byte header SHOULD be used when all non-SDES header extensions support the one-byte format and all SDES item text values are at most 16 bytes.
There SHOULD be strong integrity protection and source authentication of header extensions carrying SDES items, to prevent attackers from modifying SDES item values and creating erroneous relationship bindings.
To handle flaps caused by packet reordering, SDES items received in RTP packets with the same or a lower extended sequence number than the last change MUST NOT be applied; items that can be determined to be older than the current one must be discarded.
SDES items like NAME and LOC are highly sensitive from a privacy perspective and should not be transported over the network without strong security. No use case requires such information at the time of the first RTP packets, so they are excluded from registration for use with this header extension.
CNAME (Canonical End-Point Identifier) is registered as an SDES item for use with the RTP header extension under the URI 'urn:ietf:params:rtp-hdrext:sdes:cname'. It is the primary motivating item due to its role in establishing synchronization context.
The SDES item RTP header extension uses the RFC 5285 general header extension mechanism, where the ID field maps to both the type of header extension and the type of SDES item. The mapping is established in signaling via a URN identifying the header extension and SDES item type.
IANA created the 'RTP SDES Compact Header Extensions' sub-registry under 'RTP Compact Header Extensions', with the base URN 'urn:ietf:params:rtp-hdrext:sdes'. Registration requires Expert Review with additional criteria: a registered SDES item type, security/privacy considerations, and justification for timely delivery.
IANA registered the base URN 'urn:ietf:params:rtp-hdrext:sdes' in the 'RTP Compact Header Extensions' registry as a reserved subspace for RTCP SDES items that are also defined as RTP compact header extensions.
SDES items such as CNAME, NAME, EMAIL, PHONE, LOC, and H323-CADDR may be sensitive from a user privacy perspective. A CNAME of the form user@host has privacy concerns, and one derived from a MAC address has long-term tracking implications. Confidentiality for RTCP must be extended to RTP header extensions carrying these items.
The one-byte format consists of a 4-bit ID field followed by a 4-bit length field (len), where the data payload is len+1 bytes of UTF-8 text encoding the SDES item value. This reuses the RFC 5285 one-byte header format.
The two-byte format consists of an 8-bit ID field followed by an 8-bit length field (len), where the data payload is len bytes of UTF-8 text encoding the SDES item value. This reuses the RFC 5285 two-byte header format and supports SDES items up to 255 bytes.