Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP)
Multiplexing Using the Session Description Protocol (SDP)
Ericsson
Hirsalantie 11
Jorvas
02420
Finland
christer.holmberg@ericsson.com
Transport
RTP
RTCP
SDP
OFFER
ANSWER
MUX
MULTIPLEX
RTCWEB
WebRTC
JSEP
This document defines a new Session Description Protocol (SDP)
media-level attribute, 'rtcp-mux-only', that can be used
by an endpoint to indicate exclusive support of RTP
and RTP Control Protocol (RTCP) multiplexing. The document also updates RFC
5761 by clarifying that an offerer can use a mechanism to indicate
that it is not able to send and receive RTCP on separate ports.
Introduction
defines how to multiplex
RTP and RTCP on a single IP address and port, referred to as
RTP/RTCP multiplexing.
also defines an SDP
attribute, 'rtcp-mux', that can be used by entities to indicate
support of RTP/RTCP multiplexing and negotiate usage of it.
As defined in , if
the peer endpoint does not support RTP/RTCP multiplexing, both endpoints should
use separate ports for sending and receiving of RTCP (referred to as fallback
to usage of separate ports for RTP and RTCP).
Some newer applications that do not require backward compatibility
with peers that cannot multiplex RTCP might choose not to
implement separation of RTP and RTCP. Examples of such
applications are W3C WebRTC applications , which are not required to interoperate with
non-WebRTC clients. For such applications, this document defines
an SDP attribute to signal intent to require multiplexing. The
use of this attribute in SDP offers may harm the interoperability of entities that
ever need to interoperate with peers that do not support RTC/RTCP
multiplexing. Also, while the SDP answerer might support, and prefer usage of, fallback to
nonmultiplex, the attribute indicates that fallback to
nonmultiplex cannot be enabled. One example of where nonmultiplex
is preferred is where an endpoint is connected to a radio
interface and wants to use different bearers (possibly with
different quality characteristics) for RTP and RTCP. Another
example is where one endpoint is acting as a gateway to a network
where RTP/RTCP multiplexing cannot be used. In such a case, the
endpoint may also prefer nonmultiplexing towards the other
network. Otherwise, the endpoint would have to perform
demultiplexing of RTP and RTCP.
This document defines a new SDP media-level attribute,
'rtcp-mux-only', that can be used by an endpoint to indicate
exclusive support of RTP/RTCP multiplexing. The document also
updates by clarifying
that an offerer can use a mechanism to indicate that it is not
able to send and receive RTCP on separate ports.
This document also describes the Interactive Connectivity Establishment (ICE)
considerations when indicating exclusive
support of RTP/RTCP multiplexing.
Conventions
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14 when, and only when, they appear in all capitals, as
shown here.
SDP 'rtcp-mux-only' Attribute
This section defines a new SDP media-level attribute, 'rtcp-mux-only'.
-
- Name:
- rtcp-mux-only
- Value:
- N/A
- Usage Level:
- media
- Charset Dependent:
- no
- Syntax:
- rtcp-mux-only
- Example:
- a=rtcp-mux-only
In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute to
indicate exclusive support of RTP/RTCP multiplexing for the RTP-based
media associated with the SDP media description ("m=" line).
In an SDP answer, the 'rtcp-mux' attribute indicates that the answerer
supports, and accepts usage of, RTP/RTCP multiplexing for the RTP-based media
associated with the SDP media description ("m=" line).
The usage of the 'rtcp-mux-only' attribute in an SDP answer is forbidden.
The usage of the SDP 'rtcp-mux-only' attribute is only defined for RTP-based
media.
The mux category
for the 'rtcp-mux-only' attribute is "IDENTICAL", which means that the
attribute, if used within a BUNDLE group ,
must be associated with all multiplexed RTP-based media descriptions
within the BUNDLE group.
The 'rtcp-mux-only' attribute applies to the whole associated
media description. The attribute MUST NOT be defined per source (using the
SDP 'ssrc' attribute ).
The SDP offer/answer procedures associated with the attribute
are defined in .
SDP Offer/Answer Procedures
General
This section defines the SDP offer/answer procedures for
indicating exclusive support of RTP/RTCP multiplexing and
negotiating usage of it.
The procedures in this section apply to individual RTP-based
SDP media descriptions ("m=" lines).
Generating the Initial SDP Offer
When sending the initial offer, if the offerer wants to indicate
exclusive RTP/RTCP multiplexing for RTP-based media, it MUST associate
an SDP 'rtcp-mux-only' attribute with the associated SDP media description
("m=" line).
In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with
an SDP media description ("m=" line), the offerer MUST also associate
an SDP 'rtcp-mux' attribute with the same SDP media
description ("m=" line), following
the procedures in .
If the offerer associates an SDP 'rtcp' attribute
with an SDP media description ("m=" line), and if the offerer also associates an
SDP 'rtcp-mux-only' attribute with the same SDP media description ("m=" line), the address and port
values of the SDP 'rtcp' attribute MUST match the corresponding values for RTP.
NOTE: This specification does not mandate the usage of the SDP 'rtcp' attribute for RTP/RTCP multiplexing.
Generating the Answer
When an answerer receives an offer that contains an SDP
'rtcp-mux-only' attribute associated with
an RTP-based SDP media description ("m=" line), then if the
answerer accepts the usage of RTP/RTCP multiplexing, it MUST
associate an SDP 'rtcp-mux' attribute with
the corresponding SDP media description ("m=") in the
associated answer, following the procedures in
. If
the answerer does not accept the usage of RTP/RTCP
multiplexing, it MUST either reject the SDP media
description ("m=")
by setting the port value to zero in the associated answer, or reject the whole offer,
following the procedures in .
The answerer MUST NOT associate an SDP 'rtcp-mux-only' attribute with an
SDP media description ("m=" line) in the answer.
Offerer Processing of the SDP Answer
If an offerer associated an SDP 'rtcp-mux-only' attribute with
an RTP-based SDP media description ("m=" line) in an offer,
and if the corresponding SDP media description ("m=" line) in
the associated answer contains an SDP 'rtcp-mux' attribute,
the offerer MUST apply the RTP/RTCP
multiplexing procedures to the associated RTP-based media. If the
corresponding SDP media description ("m=" line) in the
associated answer does not contain an SDP 'rtcp-mux'
attribute, the offerer MUST either take
appropriate actions in order to disable the associated
RTP-based media -- e.g., send a new offer with a zero port
value associated with the SDP media description ("m=" line) --
or send a new offer without associating an SDP 'rtcp-mux-only'
attribute with the SDP media description ("m=" line).
NOTE: This document does not mandate specific actions on how to terminate the RTP media.
The offerer might, for example, terminate the RTP media by
sending a new offer in which the port value of the SDP
media description is set to zero.
Modifying the Session
When an offerer sends a subsequent offer, if the offerer and
answerer have previously negotiated usage of exclusive
RTP/RTCP multiplexing for the media associated with an
RTP-based SDP media description ("m=" line), the offerer
SHOULD associate an SDP 'rtcp-mux-only' with
the corresponding SDP media description ("m=" line).
In addition, if the offerer associates an SDP 'rtcp-mux-only'
attribute with an SDP media description ("m=" line), the
offerer MUST also associate an SDP 'rtcp-mux'
attribute with the same SDP media description ("m=" line),
following the procedures in .
If the offerer does not associate the attributes with the
corresponding SDP media description ("m=" line), it is an
indication that the offerer no longer wants to use RTP/RTCP
multiplexing and instead MUST fall back to usage of separate
ports for RTP and RTCP once the offer has been accepted
by the answerer.
When an offerer sends a subsequent offer, if the offerer and
answerer have not previously negotiated usage of RTP/RTCP
multiplexing for the media associated with an RTP-based SDP
media description ("m=" line), the offerer MAY
indicate exclusive support of RTP/RTCP multiplexing, following
the procedures in . The offerer MUST process
the associated answer following the procedures in .
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.
Update to RFC 5761
General
This section updates Sections and of by clarifying that an offerer can use a
mechanism to indicate that it is not able to send and receive RTCP
on separate ports, and that the offerer shall terminate the
affected streams if the answerer does not indicate support of
RTP/RTCP multiplexing. It also clarifies that, when the offerer is
not able to send and receive RTCP on separate ports, the offerer
will not provide an SDP 'candidate' attribute for RTCP, nor will
the offerer provide a fallback port for RTCP (using the SDP 'rtcp'
attribute).
Update to 4th Paragraph of Section 5.1.1
NOTE: also updates
. While the paragraph updated in this
document is not updated by , the location of the paragraph within
Section 5.1.1 is moved.
OLD TEXT:
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.
NEW TEXT:
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 signaled 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. However, if the offerer indicated in the offer that it is
not able to send and receive RTCP on a separate port, the offerer
MUST disable the media streams associated with the attribute. The
mechanism for indicating that the offerer is not able to send and
receive RTCP on a separate port is outside the scope of this
specification.
Update to 2nd Paragraph of Section 5.1.3
OLD TEXT:
If it is desired to use both ICE and multiplexed RTP and RTCP, the
initial offer MUST contain an "a=rtcp-mux" attribute to indicate that
RTP and RTCP multiplexing is desired and MUST contain "a=candidate:"
lines for both RTP and RTCP along with an "a=rtcp:" line indicating a
fallback port for RTCP in the case that the answerer does not support
RTP and RTCP multiplexing. This MUST be done for each media where
RTP and RTCP multiplexing is desired.
NEW TEXT:
If it is desired to use both ICE and multiplexed RTP and RTCP, the
initial offer MUST contain an "a=rtcp-mux" attribute to indicate that
RTP and RTCP multiplexing is desired and MUST contain "a=candidate:"
lines for both RTP and RTCP along with an "a=rtcp:" line indicating a
fallback port for RTCP in the case that the answerer does not support
RTP and RTCP multiplexing. This MUST be done for each media where
RTP and RTCP multiplexing is desired. However, if the offerer
indicates in the offer that it is not able to send and receive RTCP
on a separate port, the offerer MUST NOT include "a=candidate:"
lines for RTCP and MUST NOT provide a fallback port for
RTCP using the "a=rtcp:" line.
ICE Considerations
As defined in , if an entity is aware that the
remote peer supports, and is willing to use, RTP/RTCP multiplexing,
the entity will only provide RTP candidates (component ID 1).
However, only providing RTP candidates does not, as such, imply
exclusive support of RTP/RTCP multiplexing. RTCP candidates also
would not be provided in cases where RTCP is not supported
at all. Therefore, additional information is needed in order
to indicate support of exclusive RTP/RTCP multiplexing. This
document defines such a mechanism using the SDP 'rtcp-mux-only'
attribute.
Security Considerations
This document does not introduce new security considerations
beyond those specified in and .
IANA Considerations
This document updates the "Session Description Protocol Parameters" registry
as specified in .
Specifically, it adds the SDP 'rtcp-mux-only' attribute to the table for SDP
media-level attributes.
-
- Attribute name:
- rtcp-mux-only
- Type of attribute:
- media-level
- Subject to charset:
- no
- Purpose:
- Indicate exclusive support of RTP/RTCP multiplexing
- Appropriate Values:
- N/A
- Contact name:
- (christer.holmberg@ericsson.com)
- Mux Category:
- IDENTICAL
References
Normative References
A Framework for Session Description Protocol (SDP)
Attributes When Multiplexing
Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
Informative References
WebRTC 1.0: Real-time Communication Between Browsers
W3C Proposed Recommendation
Acknowledgements
Thanks to , , ,
, , and for their comments and input on the
document. Thanks to for the
GENART review.