Session Description Protocol (SDP)
Offer/Answer Clarifications for RTP/&wj;RTCP MultiplexingEricssonHirsalantie 11Jorvas02420Finlandchrister.holmberg@ericsson.com
RAI
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.
RFC 5761
specifies how to multiplex RTP data packets and RTP Control Protocol
(RTCP) packets on a single UDP port, and how to negotiate usage of
such multiplexing using the SDP offer/answer mechanism
with an
"a=rtcp-mux" attribute. However, the text is unclear on whether an
answerer is allowed to include the attribute in an answer
even if the associated offer did not contain an attribute.
This document updates RFC 5761
by clarifying that an answerer can only include an "a=rtcp-mux"
attribute in an answer if the associated offer contained the attribute.
It also clarifies that the negotiation of RTP and RTCP multiplexing is
for usage in both directions.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
This section updates Section 5.1.1 of RFC 5761
by clarifying that an answerer can only include an "a=rtcp-mux"
attribute in an answer if the associated offer contained the attribute,
and by clarifying that the negotiation of RTP and RTCP multiplexing is
for usage in both directions.
In this section, any references to Sections 4 and 8 are to those
sections
in .
OLD TEXT:
When the Session Description Protocol (SDP) [8] is used to negotiate
RTP sessions following the offer/answer model [9], the "a=rtcp-mux"
attribute (see Section 8) indicates the desire to multiplex RTP and
RTCP onto a single port. The initial SDP offer MUST include this
attribute at the media level to request multiplexing of RTP and RTCP
on a single port. For example:
This offer denotes a unicast voice-over-IP session using the RTP/AVP
profile with iLBC coding. The answerer
is requested to send both RTP and RTCP to port 49170 on IPv6 address
2001:DB8::211:24ff:fea3:7a2e.
If the answerer wishes to multiplex RTP and RTCP onto a single port,
it MUST include a media-level "a=rtcp-mux" attribute in the answer.
The RTP payload types used in the answer MUST conform to the rules in
Section 4.
If the answer does not contain an "a=rtcp-mux" attribute, the offerer
MUST NOT multiplex RTP and RTCP packets on a single port. Instead,
it should send and receive RTCP on a port allocated according to the
usual port-selection rules (either the port pair, or a signalled port
if the "a=rtcp:" attribute [10] is also included). This will occur
when talking to a peer that does not understand the "a=rtcp-mux"
attribute.
When SDP is used in a declarative manner, the presence of an "a=rtcp-mux" attribute signals that the sender will multiplex RTP and RTCP on
the same port. The receiver MUST be prepared to receive RTCP packets
on the RTP port, and any resource reservation needs to be made
including the RTCP bandwidth.
NEW TEXT:
When the Session Description Protocol (SDP) [8] is used to negotiate
RTP sessions following the offer/answer model [9], the "a=rtcp-mux"
attribute (see Section 8) indicates the desire to multiplex RTP and
RTCP onto a single port, and the usage is always negotiated for both
directions.
If the offerer wishes to multiplex RTP and RTCP onto a single port,
the initial SDP offer MUST include the attribute at the media level to
request multiplexing of RTP and RTCP on a single port. For example:
This offer denotes a unicast voice-over-IP session using the RTP/AVP
profile with Internet Low Bit Rate Codec (iLBC) coding. The answerer
is requested to send both RTP and RTCP to port 49170 on IPv6 address
2001:DB8::211:24ff:fea3:7a2e.
If the offer contains the "a=rtcp-mux" attribute, and if the answerer
wishes to multiplex RTP and RTCP onto a single port, it MUST include a
media-level "a=rtcp-mux" attribute in the answer. The RTP payload
types used in the answer MUST conform to the rules in Section 4. 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 the
answerer MUST NOT multiplex RTP and RTCP packets on a single port.
If the answer contains an "a=rtcp-mux" attribute, the offerer and
answerer MUST multiplex RTP and RTCP packets on a single port.
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 send and receive RTCP on a port allocated
according to the usual port-selection rules (either the port pair, or
a signalled port if the "a=rtcp:" attribute [10] is also included).
This will occur when talking to a peer that does not understand the
"a=rtcp-mux" attribute.
When SDP is used in a declarative manner, the presence of an "a=rtcp-mux" attribute signals that the sender will multiplex RTP and RTCP on
the same port. The receiver MUST be prepared to receive RTCP packets
on the RTP port, and any resource reservation needs to be made
including the RTCP bandwidth.
The security considerations for RTP and RTCP multiplexing are
described in RFC 5761. This specification does not impact those
security considerations.
IANA has added a reference to this document
for the att&nbhy;field (media level only) registration "rtcp-mux"
in the "Session Description Protocol (SDP) Parameters" registry.
Thanks to Colin Perkins, Magnus Westerlund, Paul Kyzivat, and Roni Even for
providing comments on the document. Thomas Belling provided useful input
in the discussions that took place in 3GPP and resulted in the submission
of the document. Elwyn Davies performed the Gen-ART review. Rick Casarez
performed the Ops-Dir review. Alissa Cooper and Spencer Dawkins provided
IESG review comments.