Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)
updates
- rfc-5761 — Multiplexing RTP Data and Control Packets on a Single Port
Extracted elements (18)
Providing only RTP ICE candidates (component ID 1) does not by itself imply exclusive RTP/RTCP multiplexing support, as RTCP candidates are also absent when RTCP is not supported at all. The 'rtcp-mux-only' SDP attribute is therefore needed to signal exclusive multiplexing intent unambiguously.
The 'rtcp-mux-only' attribute was created for newer applications (such as WebRTC) that do not require backward compatibility with peers unable to multiplex RTCP, and which choose not to implement separation of RTP and RTCP. Using this attribute in offers may harm interoperability with peers that do not support RTP/RTCP multiplexing.
If an offerer indicated it cannot send/receive RTCP on a separate port (via 'rtcp-mux-only') and the answer does not contain 'rtcp-mux', the offerer MUST disable the associated media streams rather than fall back to separate ports, updating RFC 5761 Section 5.1.1.
When used within a BUNDLE group (RFC 8843), the 'rtcp-mux-only' attribute has mux category 'IDENTICAL', meaning it must be associated with all multiplexed RTP-based media descriptions within the BUNDLE group.
When using ICE with exclusive RTP/RTCP multiplexing, the offerer MUST NOT include 'a=candidate:' lines for RTCP and MUST NOT provide a fallback port for RTCP using the 'a=rtcp:' line. This updates RFC 5761 Section 5.1.3.
If 'rtcp' attribute (RFC 3605) and 'rtcp-mux-only' are both associated with the same SDP media description, the address and port values of the 'rtcp' attribute MUST match the corresponding RTP values.
If the offerer associates 'rtcp-mux-only' with an SDP media description, it MUST also associate 'rtcp-mux' with the same media description, following RFC 5761 procedures.
If the offerer does not associate 'rtcp-mux-only' (or 'rtcp-mux') with the SDP media description in a subsequent offer, the offerer MUST fall back to usage of separate ports for RTP and RTCP once the offer is accepted.
If the offerer sent 'rtcp-mux-only' and the answer contains 'rtcp-mux', the offerer MUST apply RTP/RTCP multiplexing procedures. If the answer does not contain 'rtcp-mux', the offerer MUST either disable the RTP-based media or send a new offer without 'rtcp-mux-only'.
It is RECOMMENDED to not switch between usage of RTP/RTCP multiplexing and usage of separate ports for RTP and RTCP in a subsequent offer, unless there is a use case that mandates it.
The answerer MUST NOT associate an 'rtcp-mux-only' attribute with an SDP media description in the answer; its use in SDP answers is forbidden.
The 'rtcp-mux-only' attribute MUST NOT be defined per source using the SDP 'ssrc' attribute (RFC 5576); it applies to the whole associated media description.
When an answerer accepts RTP/RTCP multiplexing from an offer containing 'rtcp-mux-only', it MUST associate 'rtcp-mux' with the corresponding SDP media description in the answer. If the answerer does not accept multiplexing, it MUST either reject the media description (port set to zero) or reject the whole offer.
When sending a subsequent offer where exclusive RTP/RTCP multiplexing was previously negotiated, the offerer SHOULD associate 'rtcp-mux-only' with the corresponding SDP media description.
When sending the initial offer to indicate exclusive RTP/RTCP multiplexing, the offerer MUST associate an 'rtcp-mux-only' attribute with the SDP media description ('m=' line).
The 'rtcp-mux-only' SDP media-level attribute is defined to indicate exclusive support of RTP/RTCP multiplexing. It has no value (N/A), is not charset dependent, and its syntax is simply 'a=rtcp-mux-only'.
This document registers the 'rtcp-mux-only' SDP media-level attribute in the 'Session Description Protocol Parameters' registry (per RFC 4566 Section 8.2.4), with mux category IDENTICAL and purpose of indicating exclusive support of RTP/RTCP multiplexing.
This document does not introduce new security considerations beyond those specified in RFC 3605 and RFC 5761.