One document matched: draft-ietf-mmusic-mux-exclusive-04.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- comment -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="trust200902" category="std" docName="draft-ietf-mmusic-mux-exclusive-04" updates="5761" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="Exclusive RTP/RTCP Mux">
Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP
</title>
<author fullname="Christer Holmberg" initials="C.H." surname="Holmberg">
<organization abbrev="Ericsson">Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>Jorvas</city>
<region></region>
<code>02420</code>
<country>Finland</country>
</postal>
<phone></phone>
<email>christer.holmberg@ericsson.com</email>
</address>
</author>
<date year="2016" />
<area>Transport</area>
<keyword>RTP</keyword>
<keyword>RTCP</keyword>
<keyword>SDP</keyword>
<keyword>OFFER</keyword>
<keyword>ANSWER</keyword>
<keyword>MUX</keyword>
<keyword>MULTIPLEX</keyword>
<keyword>RTCWEB</keyword>
<keyword>WEBRTC</keyword>
<keyword>JSEP</keyword>
<abstract>
<t>
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 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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
<xref target="RFC5761" pageno="false" format="default"/> defines how to
multiplex RTP and RTCP on a single IP address and port, referred to as RTP/RTCP multiplexing.
<xref target="RFC5761" pageno="false" format="default"/> also defines an
Session Description Protocol (SDP) <xref target="RFC4566" pageno="false"
format="default"/> attribute, 'rtcp-mux' that can be used by entities
to indicate support, and negotiate usage of, RTP/RTCP multiplexing.
</t>
<t>
As defined in <xref target="RFC5761" pageno="false" format="default"/>, 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).
</t>
<t>
Some newer applications that do not require backward compatibility with peers
that cannot multiplex RTCP might choose to not implement separation of
RTP and RTCP. For those applications, this document defines an SDP attribute
to signal intent to require multiplexing.
</t>
<t>
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 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.
</t>
<t>
The document also describes the Interactive Connectivity Establishment (ICE)
<xref target="I-D.ietf-ice-rfc5245bis"/> considerations when indicating exclusive
support of RTP/RTCP multiplexing.
</t>
</section>
<section title="Conventions">
<t>
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 <xref target="RFC2119"></xref>.
</t>
</section>
<section title="SDP rtcp-mux-only Attribute" anchor="sec-dcon-attr">
<t>
This section defines a new SDP media-level attribute, 'rtcp-mux-only'.
</t>
<figure>
<artwork align="left"><![CDATA[
Name: rtcp-mux-only
Value: N/A
Usage Level: media
Charset Dependent: no
Syntax:
rtcp-mux-only
Example:
a=rtcp-mux-only
]]></artwork>
</figure>
<t>
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).
</t>
<t>
In an SDP answer, the 'rtcp-mux-only' 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).
</t>
<t>
The usage of the SDP 'rtcp-mux-only' attribute is only defined for RTP-based
media.
</t>
<t>
The mux category <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/>
for the 'rtcp-mux-only' attribute is 'NORMAL', which means that the
attribute can be associated with an individual media description, even if the
media description is multiplexed with other media descriptions
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> with which the
attribute is not associated.
</t>
<t>
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 <xref format="default" pageno="false" target="RFC5576"/>).
</t>
<t>
The SDP offer/answer <xref format="default" pageno="false" target="RFC3264"/>
procedures associated with the attribute are defined in <xref target="sec-oa"/>
</t>
</section>
<section title="SDP Offer/Answer Procedures" anchor="sec-oa">
<section title="General">
<t>
This section defines the SDP offer/answer <xref format="default" pageno="false" target="RFC3264"/>
procedures for indicating exclusive support of, and negotiating usage of,
RTP/RTCP multiplexing.
</t>
<t>
The procedures in this section apply to individual RTP-based
SDP media descriptions ("m=" lines).
</t>
</section>
<section title="Generating the Initial SDP Offer" anchor="sec-of-ini-off">
<t>
When an offerer sends the initial offer, if the offerer wants to indicate
exclusive RTP/RTCP multiplexing for RTP-based media, the offerer MUST associate
an SDP 'rtcp-mux-only' attribute with the associated SDP media description
("m=" line).
</t>
<t>
In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with
an SDP media description ("m=" line), the offerer MAY also associate an
SDP 'rtcp-mux' attribute with the same SDP media description ("m=" line), following
the procedures in <xref target="RFC5761" pageno="false" format="default"/>.
</t>
<t>
If the offerer associates an SDP 'rtcp' attribute <xref target="RFC3605" pageno="false" format="default"/>
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.
</t>
<t>
NOTE: This specification does not mandate the usage of the SDP 'rtcp' attribute for RTP/RTCP multiplexing.
</t>
</section>
<section title="Generating the Answer">
<t>
When an answerer receives an offer that contains an SDP 'rtcp-mux-only' attribute, associated with
an RTP-based SDP media description ("m=" line), if the answerer accepts the usage of
RTP/RTCP multiplexing, the answerer MUST associate an SDP 'rtcp-mux-only' attribute with
the corresponding SDP media description ("m=") in the associated answer. If the answerer does not
accept the usage of RTP/RTCP multiplexing, the answerer 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 <xref target="RFC3264" pageno="false" format="default"/>.
</t>
<t>
In addition, if the answerer associates an SDP 'rtcp-mux-only' attribute with
an SDP media description ("m=" line) in the answer, and if the corresponding "m=" line
in the associated offer contained an SDP 'rtcp-mux' attribute, the answerer MUST in addition associate
an SDP 'rtcp-mux' attribute with the same "m=" line, following the procedures in
<xref target="RFC5761" pageno="false" format="default"/>.
</t>
</section>
<section title="Offerer Processing of the SDP Answer" anchor="sec-of-off-ans">
<t>
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-only' attribute, and/or an SDP 'rtcp-mux' attribute, the offerer MUST apply the
RTP/RTCP multiplexing procedures <xref target="RFC5761" pageno="false" format="default"/>
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-only' attribute, nor an SDP 'rtcp-mux' attribute,
the offerer MUST either take appropriate actions in order to disable the associated RTP-based media,
or send a new offer without associating an SDP 'rtcp-mux-only' attribute with the
SDP media description ("m=" line).
</t>
<t>
NOTE: This document does not mandate specific actions on how to terminate the RTP media.
The offerer might e.g. send a new offer, where the port value of the SDP
media description is set to zero, in order to terminate the RTP media.
</t>
</section>
<section title="Modifying the Session">
<t>
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).
</t>
<t>
In addition, if the offerer associates an SDP 'rtcp-mux-only' attribute with
an SDP media description ("m=" line), the offerer MAY also associate an
SDP 'rtcp-mux' attribute with the same SDP media description ("m=" line), following
the procedures in <xref target="RFC5761" pageno="false" format="default"/>.
</t>
<t>
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 fallback to usage of separate ports for RTP and RTCP once the offer has been accepted
by the answerer.
</t>
<t>
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 <xref target="sec-of-ini-off"/>.
The offerer MUST process the associated answer following the procedures in
<xref target="sec-of-off-ans"/>.
</t>
<t>
NOTE: 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.
</t>
</section>
</section>
<section title="Update to RFC 5761">
<section title="General">
<t>
This section updates sections 5.1.1 and 5.1.3 of 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, 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).
</t>
</section>
<section title="Update to 4th paragraph of section 5.1.1">
<figure>
<artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[
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 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. 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.
]]></artwork>
</figure>
</section>
<section title="Update to 2nd paragraph of section 5.1.3">
<figure>
<artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[
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=candidiate:" lines
for RTCP, and the offerer MUST NOT provide a fallback port for RTCP using
the "a=rtcp:" line.
]]></artwork>
</figure>
</section>
</section>
<section title="ICE Considerations">
<t>
As defined in <xref target="I-D.ietf-ice-rfc5245bis"/>, 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
would not be provided also 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 mechanism using the SDP 'rtcp-mux-only'
attributes.
</t>
</section>
<section title="Security Considerations">
<t>
This document does not introduce new security considerations
in additions to those specified in <xref target="RFC3605"
pageno="false" format="default"/> and <xref target="RFC5761"
pageno="false" format="default"/>.
</t>
</section>
<section anchor="section.iana" title="IANA Considerations">
<t>
This document updates the "Session Description Protocol Parameters" registry
as specified in Section 8.2.2 of <xref target="RFC4566" pageno="false" format="default"/>.
Specifically, it adds the SDP 'rtcp-mux-only' attribute to the table for SDP
media level attributes.
</t>
<figure>
<artwork align="left"><![CDATA[
Attribute name: rtcp-mux-only
Type of attribute: media-level
Subject to charset: no
Purpose: Indicate exclusive support of RTP/RTCP multiplexing
Appropriate Values:
Contact name: Christer Holmberg
Category: NORMAL
]]></artwork>
</figure>
</section>
<section title="Acknowledgments">
<t>
Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman,
Tomas Frankkila and Martin Thomson for their comments and input
on the document.
</t>
</section>
<section title="Change Log">
<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>
<t>
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-03
<list style="symbols">
<t>
Editorial changes based on comments from Martin Thomson.
</t>
<t>
Change of attribute name.
</t>
<t>
RFC 5761 updates added.
</t>
</list>
</t>
<t>
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-02
<list style="symbols">
<t>
Minor editorial fix.
</t>
</list>
</t>
<t>
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-01
<list style="symbols">
<t>
Mux category and source-specific applicability added.
</t>
</list>
</t>
<t>
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-00
<list style="symbols">
<t>
Defined new SDP attribute for indicating rtcp-mux-exclusive.
</t>
<t>
Updates to RFC 5761 removed.
</t>
<t>
IANA considerations added.
</t>
</list>
</t>
<t>
Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-03
<list style="symbols">
<t>
Submitted as draft-ietf-mmusic-rtcp-mux-exclusive-00.
</t>
</list>
</t>
<t>
Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-02
<list style="symbols">
<t>
Intended status changed to "Standards track".
</t>
</list>
</t>
<t>
Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-01
<list style="symbols">
<t>
Clarified that the SDP rtcp attribute may contain the
optional IP address part.
</t>
</list>
</t>
<t>
Changes from draft-holmberg-mmusic-rtcp-mux-exclusive-00
<list style="symbols">
<t>
Additional updates to Section 5.1.1 of RFC 5761.
</t>
<t>
ICE considerations added.
</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3264"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.5761"?>
<?rfc include="reference.I-D.draft-ietf-ice-rfc5245bis-00"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3605"?>
<?rfc include="reference.RFC.5576"?>
<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-mux-attributes-12"?>
<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-bundle-negotiation-25"?>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 14:56:22 |