Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
obsoletes
- rfc-8843 — Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
updates
Extracted elements (31)
RFC 3264 and RFC 5888 are updated to allow extensions to assign non-disabling semantics to zero port values in 'm=' sections and to allow 'group' attributes to reference zero-port 'm=' sections. This enables 'bundle-only' to use zero port as a signal for BUNDLE-conditional acceptance rather than stream rejection.
The DTLS client MUST include the 'use_srtp' extension in its ClientHello even when DTLS-SRTP is not currently negotiated. This avoids a DTLS renegotiation should DTLS-SRTP encrypted media be added to the BUNDLE group later during the multimedia session.
The identification-tag is recommended to be kept short; a 1–3 byte tag results in the minimal number of 32-bit words used for the RTP SDES header extension when using the 1-byte header. The exact frequency of MID transmission is intentionally unspecified, as it depends on packet-loss rate, RTCP reporting interval, and acceptable overhead.
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. In this case each 'm=' section must use unique payload type values, and an SSRC mapped to an 'm=' section by payload type will not be remapped simply because the payload type changes.
RFC 8843 assigned the BUNDLE address:port only to the tagged 'm=' section and used 'bundle-only' with zero port for all other bundled sections in subsequent offers/answers. RFC 9143 requires the BUNDLE address:port to be assigned to all bundled 'm=' sections; handling RFC 8843-style signaling is treated as an implementation issue outside the scope of this specification.
The BUNDLE extension is backward compatible. Endpoints that do not support it generate offers and answers without 'group:BUNDLE' and assign a unique address:port to each 'm=' section per RFC 3264. An answerer that does not support BUNDLE will reject bundle-only 'm=' sections (zero port) as per RFC 3264.
A given BUNDLE address:port MUST only be associated with a single BUNDLE group. Any given bundled 'm=' section MUST NOT be associated with more than one BUNDLE group at any given time.
For a given payload type value to be reused across multiple bundled 'm=' sections, all codecs associated with that payload type MUST share an identical codec configuration: same media type, encoding name, clock rate, and any parameter affecting codec configuration or packetization.
In a 3PCC scenario, the 3PCC controller SHOULD rewrite a subsequent BUNDLE offer into a valid initial BUNDLE offer before forwarding it to a UA that is not part of an ongoing SIP session, because initial and subsequent BUNDLE offers are constructed using different rules.
In a subsequent offer or in any answer, the offerer and answerer MUST include IDENTICAL and TRANSPORT multiplexing category SDP attributes (BUNDLE attributes) only in the tagged 'm=' section and MUST NOT include such attributes in any other bundled 'm=' section.
Offerers and answerers using the BUNDLE extension MUST support the MID mechanism (Section 15), inserting the identification-tag associated with an 'm=' section into RTP header extensions and RTCP SDES packets to enable correct association of RTP streams with 'm=' sections.
Since a single BUNDLE transport is used for all bundled media, the symmetric RTP mechanism (RFC 4961) MUST be used for RTP-based bundled media. All RTP-based media within a single BUNDLE group belong to a single RTP session and share a single SSRC numbering space.
The answerer MUST assign the answerer BUNDLE address:port to the answerer-tagged 'm=' section and to every other bundled 'm=' section within the BUNDLE group.
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 MUST be enabled by including an SDP 'extmap' attribute with the URI 'urn:ietf:params:rtp-hdrext:sdes:mid' in each bundled RTP-based 'm=' section in every offer and answer. A given SSRC MUST NOT transmit RTP packets using payload types that originate from different bundled 'm=' sections.
When DTLS is used within a BUNDLE group, there MUST be only one DTLS association. If the DTLS client supports DTLS-SRTP, it MUST include the 'use_srtp' extension in the DTLS ClientHello message, even if DTLS-SRTP is not currently negotiated as part of the multimedia session.
When RTP header extensions (RFC 8285) are used within a BUNDLE group, the identifier used for a given extension MUST identify the same extension across all the bundled media descriptions.
When selecting the offerer-tagged 'm=' section, the answerer MUST verify the section will not be moved out, will not be rejected, and does not contain a zero port value. If no suitable section is found among all identification-tags, the answerer MUST NOT create the BUNDLE group.
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, it is not possible to disable RTP/RTCP multiplexing within a BUNDLE group.
The identification-tag MUST NOT contain any user information, and applications SHALL avoid generating identification-tags using a pattern that enables user or application identification. The MID SDES item is used solely to associate RTP-based media with the correct SDP 'm=' section.
The 'bundle-only' SDP media-level property attribute signals that the associated 'm=' section must be accepted only if kept within the BUNDLE group. It is defined exclusively for bundled 'm=' sections with a zero port value; if received in a non-bundled 'm=' section, it MUST be discarded.
The BUNDLE SDP Grouping Framework extension negotiates a single transport (5-tuple) for sending and receiving media described by multiple 'm=' sections. The address:port combination used by an endpoint for bundled media is the BUNDLE address:port, and a single 'group:BUNDLE' attribute lists the identification-tags of all bundled 'm=' sections.
The tagged 'm=' section (offerer-tagged or answerer-tagged) is the first identification-tag in the 'group:BUNDLE' list and carries the BUNDLE address:port and BUNDLE attributes (IDENTICAL and TRANSPORT multiplexing category) that apply to the entire BUNDLE group.
IANA 'RTP SDES Compact Header Extensions' subregistry updated: Extension URI 'urn:ietf:params:rtp-hdrext:sdes:mid' registered as 'Media identification', referencing RFC 9143.
IANA 'RTP SDES Item Types' registry updated: MID SDES item with value 15, abbreviation MID, name 'Media Identification', referencing RFC 9143.
IANA 'SDP Group Semantics' registry updated: 'BUNDLE' semantics value registered under the SDP Grouping Framework, referencing RFC 9143.
IANA 'Session Description Protocol (SDP) Parameters' registry updated: 'bundle-only' registered as a media-level SDP attribute, not subject to charset, referencing RFC 9143.
The BUNDLE mechanism shares a single transport for multiple media streams; an attacker capable of injecting or intercepting packets on the shared transport can affect all bundled media simultaneously. Security relies on the underlying transport-layer protections (e.g., DTLS-SRTP, ICE) applied to the BUNDLE transport.
BUNDLE group lifecycle: (1) Initial BUNDLE offer — offerer proposes 'group:BUNDLE' with suggested offerer-tagged 'm=' section; (2) Initial BUNDLE answer — answerer selects offerer-tagged and answerer-tagged sections, BUNDLE group is created; (3) Subsequent offer/answer — uses previously negotiated group with mandatory BUNDLE address:port on all bundled sections.
The RTCP MID SDES item has type MID=15, followed by a 1-byte length field, followed by the identification-tag as UTF-8 encoded octets. The identification-tag is not zero-terminated.
The RTP SDES header extension for MID can be encoded with either the 1-byte or 2-byte header format (RFC 7941). The payload is the identification-tag in UTF-8 (not zero-terminated), and the set of header extensions must be padded to the next 32-bit boundary using zero bytes.