rfc-8035

Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing

C. Holmberg
date2016-11 streamIETF areawit wgavtcore statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc8035 doi10.17487/RFC8035
This document updates RFC 5761 by clarifying the SDP offer/answer negotiation of RTP and RTP Control Protocol (RTCP) multiplexing. It makes it clear that an answerer can only include an "a=rtcp-mux" attribute in a Session Description Protocol (SDP) answer if the associated SDP offer contained the attribute.

updates

Extracted elements (13)

design-rationale §1

RFC 5761 was ambiguous about whether an answerer could include 'a=rtcp-mux' in an answer even if the offer did not contain the attribute. RFC 8035 clarifies that the answerer may only include 'a=rtcp-mux' if the offer also contained it, preventing one-sided multiplexing configurations.

rtp, realtime, webrtc

design-rationale §3

The document clarifies that negotiation of RTP/RTCP multiplexing applies to both directions, not just the answerer-to-offerer direction, making the bidirectional nature explicit where RFC 5761 left it ambiguous.

rtp, realtime, webrtc

interoperability-note §3.1

When a peer does not understand the 'a=rtcp-mux' attribute, the answer will not contain it, and both sides MUST fall back to using separate ports for RTP and RTCP per the usual port-selection rules, ensuring backward compatibility.

rtp, realtime

normative-requirement §3.1 MUST

If the answer contains an 'a=rtcp-mux' attribute, both the offerer and answerer MUST multiplex RTP and RTCP packets on a single port, applying the negotiation symmetrically to both directions.

rtp, realtime, webrtc

normative-requirement §3.1 MUST NOT

If the answer does not contain an 'a=rtcp-mux' attribute, the offerer and answerer MUST NOT multiplex RTP and RTCP packets on a single port; instead they should use the usual port-selection rules for RTCP.

rtp, realtime, webrtc

normative-requirement §3.1 MUST

If the offer contains the 'a=rtcp-mux' attribute and the answerer wishes to multiplex RTP and RTCP onto a single port, the answerer MUST include a media-level 'a=rtcp-mux' attribute in the answer.

rtp, realtime, webrtc

normative-requirement §3.1 MUST NOT

If the offer does not contain the 'a=rtcp-mux' attribute, the answerer MUST NOT include an 'a=rtcp-mux' attribute in the answer, and MUST NOT multiplex RTP and RTCP packets on a single port. This is the key clarification added by RFC 8035 over RFC 5761.

rtp, realtime, webrtc

normative-requirement §3.1 MUST

If the offerer wishes to multiplex RTP and RTCP onto a single port, the initial SDP offer MUST include the 'a=rtcp-mux' attribute at the media level to request multiplexing.

rtp, realtime, webrtc

normative-requirement §3.1 MUST

The RTP payload types used in the answer MUST conform to the rules in Section 4 of RFC 5761 when 'a=rtcp-mux' multiplexing is negotiated.

rtp, realtime

normative-requirement §3.1 MUST

When SDP is used in a declarative manner, the receiver MUST be prepared to receive RTCP packets on the RTP port when an 'a=rtcp-mux' attribute is present, including accounting for RTCP bandwidth in resource reservations.

rtp, realtime

protocol-element §3.1

The 'a=rtcp-mux' SDP attribute is a media-level attribute indicating desire to multiplex RTP and RTCP onto a single port. Its usage is always negotiated for both directions simultaneously.

rtp, realtime, webrtc

registry §5

IANA updated the att-field (media level only) registration for 'rtcp-mux' in the 'Session Description Protocol (SDP) Parameters' registry to add a reference to RFC 8035.

registry, rtp, realtime

security-consideration §4

The security considerations for RTP and RTCP multiplexing are as described in RFC 5761; RFC 8035 does not introduce new security considerations beyond those already covered.

security, rtp, realtime