Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
obsoleted by
- rfc-9143 — Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
updates
Extracted elements (31)
Requiring the DTLS client to include the 'use_srtp' extension in the initial ClientHello (even when DTLS-SRTP is not currently negotiated) avoids the need for a DTLS renegotiation later if DTLS-SRTP encrypted media is added to the BUNDLE group mid-session.
RFC 3264 is updated to allow a zero port value in an offer or answer without necessarily indicating that the media stream is disabled or rejected; an extension mechanism (such as BUNDLE's 'bundle-only' attribute) may assign different semantics to a zero port. This was necessary to permit bundle-only 'm=' sections to coexist with the existing port-zero = rejected convention.
Legacy implementations may not include the MID identification-tag in RTP/RTCP traffic and instead use payload type values to associate RTP streams with 'm=' sections. For this to work reliably, each 'm=' section must use unique payload type values; if they are not unique, stream-to-section association via PT becomes impossible.
The BUNDLE extension is backward compatible. Endpoints that do not support it will generate offers and answers without 'a=group:BUNDLE' and will assign a unique address:port to each 'm=' section per RFC 3264 and RFC 4566.
A given BUNDLE address:port MUST only be associated with a single BUNDLE group. Any bundled 'm=' section MUST NOT be associated with more than one BUNDLE group at any given time.
A given SSRC MUST NOT transmit RTP packets using payload types that originate from different bundled 'm=' sections. Doing so would cause RTP/RTCP failures and timestamp rate-switching issues.
Each 'm=' section within a BUNDLE group MUST use the same transport-layer protocol. If bundled 'm=' sections use different upper-layer protocols, a publicly available specification describing how to associate received data with the correct protocol MUST exist.
For a payload type value to be used in more than one bundled 'm=' section within a BUNDLE group, all codecs associated with that payload type number MUST share an identical codec configuration: same media type, encoding name, clock rate, and any parameter affecting codec configuration and packetization.
In a subsequent offer, or in any answer, IDENTICAL and TRANSPORT multiplexing category SDP attributes (BUNDLE attributes) MUST be included only in the tagged 'm=' section and MUST NOT be included in any other bundled 'm=' section; these attributes then apply to every bundled 'm=' section within the BUNDLE group.
In an initial BUNDLE offer, the offerer MUST assign a unique address:port to each bundled 'm=' section (excluding bundle-only sections), pick a suggested offerer-tagged 'm=' section, include an 'a=group:BUNDLE' attribute, and list the identification-tag of each bundled 'm=' section in that attribute.
Offerers and answerers using the BUNDLE extension MUST support the MID mechanism (Section 15) for inserting the identification-tag into RTP and RTCP packets so that any RTP stream can always be associated with the correct 'm=' section.
The identification-tag MUST NOT contain any user information, and applications SHALL avoid generating the identification-tag using a pattern that enables user or application identification.
The offerer MUST NOT suggest a bundle-only 'm=' section as the offerer-tagged 'm=' section. It is RECOMMENDED that the suggested offerer-tagged 'm=' section be one the offerer believes is unlikely to be rejected or moved out of the BUNDLE group.
The RTP MID header extension (URI: urn:ietf:params:rtp-hdrext:sdes:mid) MUST be enabled by including an SDP 'extmap' attribute in each bundled RTP-based 'm=' section in every offer and answer.
The symmetric RTP mechanism (RFC 4961) MUST be used for all RTP-based bundled media, since a single BUNDLE transport is used for both sending and receiving.
When DTLS is used within a BUNDLE group, there MUST be only one DTLS association for the group, all usages MUST use the same mechanism for determining client/server roles, and if the DTLS client supports DTLS-SRTP it MUST include the 'use_srtp' extension in the ClientHello even if DTLS-SRTP is not currently being negotiated.
When generating an answer that contains a BUNDLE group, the answerer MUST include an 'a=bundle-only' attribute in, and assign a zero port value to, every bundled 'm=' section other than the answerer-tagged 'm=' section.
When RTP header extensions are used within a BUNDLE group, the identifier used for a given extension MUST identify the same extension across all bundled media descriptions.
Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP multiplexing (RFC 5761) for RTP-based bundled media, and MUST support the SDP 'rtcp-mux-only' attribute (RFC 8858). Once negotiated, RTP/RTCP multiplexing within a BUNDLE group cannot be disabled.
The BUNDLE extension defines a new SDP Grouping Framework semantics value 'BUNDLE', enabling negotiation of a single transport (5-tuple) for multiple 'm=' sections. All 'm=' sections sharing that transport form a BUNDLE group, and the shared address:port is the BUNDLE address:port.
The 'bundle-only' SDP media-level property attribute (no value) requests that an answerer accept a bundled 'm=' section only if it is kept within the associated BUNDLE group. It is always paired with a zero port value on the 'm=' line.
Registers extension URI 'urn:ietf:params:rtp-hdrext:sdes:mid' (description: 'Media identification') in the RTP SDES Compact Header Extensions sub-registry.
Registers MID SDES item (value 15, abbreviation 'MID', name 'Media Identification') in the IANA 'RTP SDES Item Types' registry.
Registers new SDP media-level attribute 'bundle-only' (type: media, not subject to charset, mux category: NORMAL) in the SDP attribute registry, and registers group semantics token 'BUNDLE' (mux category: NORMAL) in the 'Semantics for the group SDP Attribute' registry.
Identification-tags MUST be generated in a fashion that does not leak user information (e.g., randomly or using a per-BUNDLE-group counter) and SHOULD be 3 bytes or less. Inconsistent generation methods across implementations could enable fingerprinting. Integrity and source authenticity of the identification-tag are important to prevent denial of service; existing SRTP protection provides this.
This specification updates RFC 7941 by adding an exception: the requirement that an SDES RTP header extension be confidentiality-protected when RTCP is confidentiality-protected MAY be ignored for the MID RTP header extension, as there are no known significant security risks in leaving it unencrypted when other recommendations are followed.
Using BUNDLE causes previously separated RTP streams to share the same security context. If different security policies would have applied to the individual streams, or if different parties would have had access to the security contexts, additional analysis is required before applying BUNDLE.
RTP stream-to-'m='-section association uses four lookup tables: MID→'m=' section, incoming SSRC→'m=' section, outgoing SSRC→'m=' section, and PT→'m=' section (PT entries excluded if ambiguous). On each received RTP packet: check MID first, then SSRC, then PT; discard if no match. Tables MUST be updated as 'm=' sections are added, removed, or reconfigured.
When selecting the offerer-tagged 'm=' section, the answerer iterates the offer's identification-tag list in order. A candidate is accepted only if: (1) the answerer will not move it out of the BUNDLE group, (2) the answerer will not reject it, and (3) it does not carry a zero port. If no candidate qualifies, the answerer MUST NOT create the BUNDLE group.
RTCP MID SDES item (type=15): one-byte type field (value 15), one-byte length field, followed by a UTF-8 encoded identification-tag payload that is not zero-terminated.
RTP SDES header extension for MID (URI: urn:ietf:params:rtp-hdrext:sdes:mid): payload carries a UTF-8 encoded, non-zero-terminated identification-tag using either the 1-byte or 2-byte RFC 7941 header format; the header extension block is padded to a 32-bit boundary with zero bytes.