rfc8858xml2.original.xml   rfc8858.xml 
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version='1.0' encoding='utf-8'?>
<!-- comment --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
<?rfc compact="yes" ?> category="std" updates="5761" submissionType="IETF" number="8858"
<?rfc sortrefs="no" ?> consensus="true" obsoletes="" xml:lang="en" tocInclude="true"
<rfc ipr="trust200902" category="std" docName="draft-ietf-mmusic-mux-exclusive-1 symRefs="true" sortRefs="true" version="3"
2.txt" updates="5761" submissionType="IETF" xml:lang="en"> docName="draft-ietf-mmusic-mux-exclusive-12">
<front> <front>
<title abbrev="Exclusive RTP/RTCP Mux"> <title abbrev="Exclusive RTP/RTCP Mux">
Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP)
</title> Multiplexing Using the Session Description Protocol (SDP)
<author fullname="Christer Holmberg" initials="C.H." surname="Holmberg"> </title>
<seriesInfo name="RFC" value="8858"/>
<author fullname="Christer Holmberg" initials="C." surname="Holmberg">
<organization abbrev="Ericsson">Ericsson</organization> <organization abbrev="Ericsson">Ericsson</organization>
<address> <address>
<postal> <postal>
<street>Hirsalantie 11</street> <street>Hirsalantie 11</street>
<city>Jorvas</city> <city>Jorvas</city>
<region></region>
<code>02420</code> <code>02420</code>
<country>Finland</country> <country>Finland</country>
</postal> </postal>
<phone></phone> <phone/>
<email>christer.holmberg@ericsson.com</email> <email>christer.holmberg@ericsson.com</email>
</address> </address>
</author> </author>
<date month="January" year="2021"/>
<date year="2017" />
<area>Transport</area> <area>Transport</area>
<keyword>RTP</keyword> <keyword>RTP</keyword>
<keyword>RTCP</keyword> <keyword>RTCP</keyword>
<keyword>SDP</keyword> <keyword>SDP</keyword>
<keyword>OFFER</keyword> <keyword>OFFER</keyword>
<keyword>ANSWER</keyword> <keyword>ANSWER</keyword>
<keyword>MUX</keyword> <keyword>MUX</keyword>
<keyword>MULTIPLEX</keyword> <keyword>MULTIPLEX</keyword>
<keyword>RTCWEB</keyword> <keyword>RTCWEB</keyword>
<keyword>WEBRTC</keyword> <keyword>WebRTC</keyword>
<keyword>JSEP</keyword> <keyword>JSEP</keyword>
<abstract> <abstract>
<t> <t>
This document defines a new SDP media-level attribute, 'rtcp-mux-onl This document defines a new Session Description Protocol (SDP)
y', that can media-level attribute, 'rtcp-mux-only', that can be used
be used by an endpoint to indicate exclusive support of RTP/RTCP mul by an endpoint to indicate exclusive support of RTP
tiplexing. The and RTP Control Protocol (RTCP) multiplexing. The document also upda
document also updates RFC 5761, by clarifying that an offerer can us tes RFC
e a mechanism 5761 by clarifying that an offerer can use a mechanism to indicate
to indicate that it is not able to send and receive RTCP on separate that it is not able to send and receive RTCP on separate ports.
ports. </t>
</t>
</abstract> </abstract>
</front> </front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>
<xref target="RFC5761" 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" format="default"/>
also defines an SDP <xref target="RFC4566" format="default"/>
attribute, 'rtcp-mux', that can be used by entities to indicate
support of RTP/RTCP multiplexing and negotiate usage of it.
</t>
<middle> <t>
<section title="Introduction"> As defined in <xref target="RFC5761" format="default"/>, if
<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 define
s an
Session Description Protocol (SDP) <xref target="RFC4566" pageno="fa
lse"
format="default"/> attribute, 'rtcp-mux' that can be used by entitie
s
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 endpo ints should the peer endpoint does not support RTP/RTCP multiplexing, both endpo ints should
use separate ports for sending and receiving of RTCP (referred to as fallback use separate ports for sending and receiving of RTCP (referred to as fallback
to usage of separate ports for RTP and RTCP). to usage of separate ports for RTP and RTCP).
</t> </t>
<t> <t>
Some newer applications that do not require backward compatibility w Some newer applications that do not require backward compatibility
ith peers with peers that cannot multiplex RTCP might choose not to
that cannot multiplex RTCP might choose to not implement separation implement separation of RTP and RTCP. Examples of such
of applications are W3C WebRTC applications <xref target="WebRTC"
RTP and RTCP. Examples of such applications are W3C WEBRTC format="default"/>, which are not required to interoperate with
<xref target="W3C.WD-webrtc-20120209"/> applications, that are not r non-WebRTC clients. For such applications, this document defines
equired an SDP attribute to signal intent to require multiplexing. The
to interoperate with non-WEBRTC clients. For such applications, this use of this attribute in SDP offers <xref format="default"
document target="RFC3264"/> may harm the interoperability of entities that
defines an SDP attribute to signal intent to require multiplexing. ever need to interoperate with peers that do not support RTC/RTCP
The use of this attribute in SDP offers <xref format="default" pagen multiplexing. Also, while the SDP answerer <xref format="default"
o="false"
target="RFC3264"/> by entities that ever need to interoperate with p
eers
that do not support RTC/RTCP multiplexing may harm interoperability.
Also, while the SDP answerer <xref format="default" pageno="false"
target="RFC3264"/> might support, and prefer usage of, fallback to target="RFC3264"/> might support, and prefer usage of, fallback to
non-multiplex, the attribute indicates that fallback to non-multiple nonmultiplex, the attribute indicates that fallback to
x nonmultiplex cannot be enabled. One example of where nonmultiplex
cannot be enabled. One example of where non-multiplex is preferred is preferred is where an endpoint is connected to a radio
is where an endpoint is connected to a radio interface, and wants to interface and wants to use different bearers (possibly with
use different quality characteristics) for RTP and RTCP. Another
different bearers (possibly with different quality characteristics) example is where one endpoint is acting as a gateway to a network
for where RTP/RTCP multiplexing cannot be used. In such a case, the
RTP and RTCP. Another example is where the one endpoint is acting as endpoint may also prefer nonmultiplexing towards the other
a gateway to a network where RTP/RTCP multiplexing cannot be used. network. Otherwise, the endpoint would have to perform
In such case there endpoint may prefer non-multiplexing also towards demultiplexing of RTP and RTCP.
the </t>
other network. Otherwise the endpoint would have to perform de-multi <t>
plexing This document defines a new SDP media-level attribute,
of RTP and RTCP. 'rtcp-mux-only', that can be used by an endpoint to indicate
</t> exclusive support of RTP/RTCP multiplexing. The document also
<t> updates <xref target="RFC5761" format="default"/> by clarifying
This document defines a new SDP media-level attribute, 'rtcp-mux-onl that an offerer can use a mechanism to indicate that it is not
y', that can
be used by an endpoint to indicate exclusive support of RTP/RTCP mul
tiplexing. The
document also updates <xref target="RFC5761" pageno="false" format="
default"/>,
by clarifying that an offerer can use a mechanism to indicate that i
t is not
able to send and receive RTCP on separate ports. able to send and receive RTCP on separate ports.
</t> </t>
<t> <t>
The document also describes the Interactive Connectivity Establishme This document also describes the Interactive Connectivity Establishm
nt (ICE) ent (ICE)
<xref target="RFC5245"/> considerations when indicating exclusive <xref target="RFC8445" format="default"/> considerations when indica
ting exclusive
support of RTP/RTCP multiplexing. support of RTP/RTCP multiplexing.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<name>Conventions</name>
<section title="Conventions">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "S
HALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTION
AL" in this
document are to be interpreted as described in <xref targ
et="RFC2119"></xref>.
</t>
</section>
<section title="SDP rtcp-mux-only Attribute" anchor="sec-dcon-attr">
<t> <t>
This section defines a new SDP media-level attribute, 'rtcp-mux-only The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
'. "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t> </t>
<figure>
<artwork align="left"><![CDATA[
Name: rtcp-mux-only </section>
<section anchor="sec-dcon-attr" numbered="true" toc="default">
Value: N/A <name>SDP 'rtcp-mux-only' Attribute</name>
<t>This section defines a new SDP media-level attribute, 'rtcp-mux-only'.
Usage Level: media </t>
<ul empty="true">
Charset Dependent: no <li>
<dl>
Syntax: <dt>Name:</dt><dd>rtcp-mux-only</dd>
<dt>Value:</dt><dd>N/A</dd>
rtcp-mux-only <dt>Usage Level:</dt><dd>media</dd>
<dt>Charset Dependent:</dt><dd>no</dd>
Example: <dt>Syntax:</dt>
<dd>rtcp-mux-only</dd>
a=rtcp-mux-only <dt>Example:</dt>
<dd>a=rtcp-mux-only</dd>
]]></artwork> </dl>
</figure> </li>
<t> </ul>
<t>
In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute to In an SDP offer, the offerer uses the SDP 'rtcp-mux-only' attribute to
indicate exclusive support of RTP/RTCP multiplexing for the RTP-base d indicate exclusive support of RTP/RTCP multiplexing for the RTP-base d
media associated with the SDP media description ("m=" line). media associated with the SDP media description ("m=" line).
</t> </t>
<t> <t>
In an SDP answer, the 'rtcp-mux' attribute <xref target="RFC5761" In an SDP answer, the 'rtcp-mux' attribute <xref target="RFC5761" fo
pageno="false" format="default"/> indicates that the answerer rmat="default"/> indicates that the answerer
supports, and accepts usage of, RTP/RTCP multiplexing for the RTP-ba sed media supports, and accepts usage of, RTP/RTCP multiplexing for the RTP-ba sed media
associated with the SDP media description ("m=" line). associated with the SDP media description ("m=" line).
</t> </t>
<t> <t>
The usage of the 'rtcp-mux-only' attribute in an SDP answer is forbi dden. The usage of the 'rtcp-mux-only' attribute in an SDP answer is forbi dden.
</t> </t>
<t> <t>
The usage of the SDP 'rtcp-mux-only' attribute is only defined for R TP-based The usage of the SDP 'rtcp-mux-only' attribute is only defined for R TP-based
media. media.
</t> </t>
<t>
The mux category <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/> <t>
for the 'rtcp-mux-only' attribute is 'IDENTICAL', which means that t The mux category <xref target="RFC8859" format="default"/>
he for the 'rtcp-mux-only' attribute is "IDENTICAL", which means that t
attribute, if used within a BUNDLE group <xref target="I-D.ietf-mmus he
ic-sdp-bundle-negotiation"/>, attribute, if used within a BUNDLE group <xref target="RFC8843" form
at="default"/>,
must be associated with all multiplexed RTP-based media descriptions must be associated with all multiplexed RTP-based media descriptions
within the BUNDLE group. within the BUNDLE group.
</t> </t>
<t> <t>
The 'rtcp-mux-only' attribute applies to the whole associated The 'rtcp-mux-only' attribute applies to the whole associated
media description. The attribute MUST NOT be defined per source (usi media description. The attribute <bcp14>MUST NOT</bcp14> be defined
ng the per source (using the
SDP 'ssrc' attribute <xref format="default" pageno="false" target="R SDP 'ssrc' attribute <xref format="default" target="RFC5576"/>).
FC5576"/>). </t>
</t> <t>
The SDP offer/answer procedures <xref format="default" target="RFC32
64"/> associated with the attribute
are defined in <xref target="sec-oa" format="default"/>.
</t>
</section>
<section anchor="sec-oa" numbered="true" toc="default">
<name>SDP Offer/Answer Procedures</name>
<section numbered="true" toc="default">
<name>General</name>
<t> <t>
The SDP offer/answer <xref format="default" pageno="false" target="R This section defines the SDP offer/answer procedures <xref forma
FC3264"/> t="default" target="RFC3264"/> for
procedures associated with the attribute are defined in <xref target indicating exclusive support of RTP/RTCP multiplexing and
="sec-oa"/> negotiating usage of it.
</t> </t>
</section> <t>
<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 The procedures in this section apply to individual RTP-based
SDP media descriptions ("m=" lines). SDP media descriptions ("m=" lines).
</t> </t>
</section> </section>
<section anchor="sec-of-ini-off" numbered="true" toc="default">
<section title="Generating the Initial SDP Offer" anchor="sec-of-ini-off <name>Generating the Initial SDP Offer</name>
"> <t>
<t> When sending the initial offer, if the offerer wants to indicate
When an offerer sends the initial offer, if the offerer wants to exclusive RTP/RTCP multiplexing for RTP-based media, it <bcp14>M
indicate UST</bcp14> associate
exclusive RTP/RTCP multiplexing for RTP-based media, the offerer
MUST associate
an SDP 'rtcp-mux-only' attribute with the associated SDP media d escription an SDP 'rtcp-mux-only' attribute with the associated SDP media d escription
("m=" line). ("m=" line).
</t> </t>
<t> <t>
In addition, if the offerer associates an SDP 'rtcp-mux-only' at tribute with In addition, if the offerer associates an SDP 'rtcp-mux-only' at tribute with
an SDP media description ("m=" line, the offerer MUST also assoc an SDP media description ("m=" line), the offerer <bcp14>MUST</b
iate an cp14> also associate
SDP 'rtcp-mux' attribute with the same SDP media description ("m an SDP 'rtcp-mux' attribute with the same SDP media
=" line), following description ("m=" line), following
the procedures in <xref target="RFC5761" pageno="false" format=" the procedures in <xref target="RFC5761" format="default"/>.
default"/>. </t>
</t> <t>
<t> If the offerer associates an SDP 'rtcp' attribute <xref target="
If the offerer associates an SDP 'rtcp' attribute <xref target=" RFC3605" format="default"/>
RFC3605" pageno="false" format="default"/>
with an SDP media description ("m=" line), and if the offerer al so associates an with an SDP media description ("m=" line), and if the offerer al so associates an
SDP 'rtcp-mux-only' attribute with the same SDP media descriptio n ("m=" line), the address and port SDP 'rtcp-mux-only' attribute with the same SDP media descriptio n ("m=" line), the address and port
values of the SDP 'rtcp' attribute MUST match the corresponding values of the SDP 'rtcp' attribute <bcp14>MUST</bcp14> match the
values for RTP. corresponding values for RTP.
</t> </t>
<t> <t>
NOTE: This specification does not mandate the usage of the SDP ' rtcp' attribute for RTP/RTCP multiplexing. NOTE: This specification does not mandate the usage of the SDP ' rtcp' attribute for RTP/RTCP multiplexing.
</t> </t>
</section> </section>
<section title="Generating the Answer"> <section numbered="true" toc="default">
<t> <name>Generating the Answer</name>
When an answerer receives an offer that contains an SDP 'rtcp-mu <t>
x-only' attribute, associated with When an answerer receives an offer that contains an SDP
an RTP-based SDP media description ("m=" line), if the answerer 'rtcp-mux-only' attribute associated with
accepts the usage of an RTP-based SDP media description ("m=" line), then if the
RTP/RTCP multiplexing, the answerer MUST associate an SDP 'rtcp- answerer accepts the usage of RTP/RTCP multiplexing, it <bcp14>MUST</bcp14>
mux' attribute with associate an SDP 'rtcp-mux' attribute with
the corresponding SDP media description ("m=") in the associated the corresponding SDP media description ("m=") in the
answer, following the procedures in associated answer, following the procedures in
<xref target="RFC5761" pageno="false" format="default"/>. If the <xref target="RFC5761" format="default"/>. If
answerer does not the answerer does not accept the usage of RTP/RTCP
accept the usage of RTP/RTCP multiplexing, the answerer MUST eit multiplexing, it <bcp14>MUST</bcp14> either reject the SDP media
her reject the SDP media description ("m=") description ("m=")
by setting the port value to zero in the associated answer, or r eject the whole offer, by setting the port value to zero in the associated answer, or r eject the whole offer,
following the procedures in <xref target="RFC3264" pageno="false following the procedures in <xref target="RFC3264" format="defau
" format="default"/>. lt"/>.
</t> </t>
<t> <t>
The answerer MUST NOT associate an SDP 'rtcp-mux-only' attribute The answerer <bcp14>MUST NOT</bcp14> associate an SDP 'rtcp-mux-
with an only' attribute with an
SDP media description ("m=" line) in the answer. SDP media description ("m=" line) in the answer.
</t> </t>
</section> </section>
<section title="Offerer Processing of the SDP Answer" anchor="sec-of-off <section anchor="sec-of-off-ans" numbered="true" toc="default">
-ans"> <name>Offerer Processing of the SDP Answer</name>
<t> <t>
If an offerer associated an SDP 'rtcp-mux-only' attribute with a If an offerer associated an SDP 'rtcp-mux-only' attribute with
n RTP-based an RTP-based SDP media description ("m=" line) in an offer,
SDP media description ("m=" line) in an offer, and if the corres and if the corresponding SDP media description ("m=" line) in
ponding the associated answer contains an SDP 'rtcp-mux' attribute,
SDP media description ("m=" line) in the associated answer conta the offerer <bcp14>MUST</bcp14> apply the RTP/RTCP
ins multiplexing procedures <xref target="RFC5761"
an SDP 'rtcp-mux' attribute, the offerer MUST apply the RTP/RTCP format="default"/> to the associated RTP-based media. If the
multiplexing corresponding SDP media description ("m=" line) in the
procedures <xref target="RFC5761" pageno="false" format="default associated answer does not contain an SDP 'rtcp-mux'
"/> attribute, the offerer <bcp14>MUST</bcp14> either take
to the associated RTP-based media. If the corresponding SDP medi appropriate actions in order to disable the associated
a description RTP-based media -- e.g., send a new offer with a zero port
("m=" line) in the associated answer does not contain an SDP 'rt value associated with the SDP media description ("m=" line) --
cp-mux' attribute, or send a new offer without associating an SDP 'rtcp-mux-only'
the offerer MUST either take appropriate actions in order to dis
able the associated
RTP-based media, e.g., send a new offer with a zero port value a
ssociated with the
SDP media description ("m=" line), or send a new offer without a
ssociating an SDP 'rtcp-mux-only'
attribute with the SDP media description ("m=" line). attribute with the SDP media description ("m=" line).
</t> </t>
<t> <t>
NOTE: This document does not mandate specific actions on how to terminate the RTP media. 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 offerer might, for example, terminate the RTP media by
the SDP sending a new offer in which the port value of the SDP
media description is set to zero in order to terminate the RTP m media description is set to zero.
edia. </t>
</t> </section>
</section> <section numbered="true" toc="default">
<section title="Modifying the Session"> <name>Modifying the Session</name>
<t> <t>
When an offerer sends a subsequent offer, if the offerer and ans When an offerer sends a subsequent offer, if the offerer and
werer have previously answerer have previously negotiated usage of exclusive
negotiated usage of exclusive RTP/RTCP multiplexing for the medi RTP/RTCP multiplexing for the media associated with an
a associated with an RTP-based SDP media description ("m=" line), the offerer
RTP-based SDP media description ("m=" line), the offerer SHOULD <bcp14>SHOULD</bcp14> associate an SDP 'rtcp-mux-only' with
associate an SDP 'rtcp-mux-only' the corresponding SDP media description ("m=" line).
with the corresponding SDP media description ("m=" line). </t>
</t> <t>
<t> In addition, if the offerer associates an SDP 'rtcp-mux-only'
In addition, if the offerer associates an SDP 'rtcp-mux-only' at attribute with an SDP media description ("m=" line), the
tribute with offerer <bcp14>MUST</bcp14> also associate an SDP 'rtcp-mux'
an SDP media description ("m=" line), the offerer MUST also asso attribute with the same SDP media description ("m=" line),
ciate an following the procedures in <xref target="RFC5761"
SDP 'rtcp-mux' attribute with the same SDP media description ("m format="default"/>.
=" line), following </t>
the procedures in <xref target="RFC5761" pageno="false" format=" <t>
default"/>. If the offerer does not associate the attributes with the
</t> corresponding SDP media description ("m=" line), it is an
<t> indication that the offerer no longer wants to use RTP/RTCP
If the offerer does not associate the attributes with the corres multiplexing and instead <bcp14>MUST</bcp14> fall back to usage o
ponding SDP media description ("m=" line) f separate
it is an indication that the offerer no longer wants to use RTP/ ports for RTP and RTCP once the offer has been accepted
RTCP multiplexing, and instead
MUST fallback to usage of separate ports for RTP and RTCP once t
he offer has been accepted
by the answerer. by the answerer.
</t> </t>
<t> <t>
When an offerer sends a subsequent offer, if the offerer and ans When an offerer sends a subsequent offer, if the offerer and
werer have not previously answerer have not previously negotiated usage of RTP/RTCP
negotiated usage of RTP/RTCP multiplexing for the media associat multiplexing for the media associated with an RTP-based SDP
ed with an media description ("m=" line), the offerer <bcp14>MAY</bcp14>
RTP-based SDP media description ("m=" line), the offerer MAY ind indicate exclusive support of RTP/RTCP multiplexing, following
icate exclusive the procedures in <xref target="sec-of-ini-off"
support of RTP/RTCP multiplexing, following the procedures in <x format="default"/>. The offerer <bcp14>MUST</bcp14> process
ref target="sec-of-ini-off"/>. the associated answer following the procedures in <xref
The offerer MUST process the associated answer following the pro target="sec-of-off-ans" format="default"/>.
cedures in </t>
<xref target="sec-of-off-ans"/>. <t>
</t> It is <bcp14>RECOMMENDED</bcp14> to not switch between usage of
<t> RTP/RTCP
It is RECOMMENDED to not switch between usage of RTP/RTCP multip multiplexing and usage of separate ports for RTP and RTCP in a
lexing and usage of subsequent offer, unless there is a use case that mandates it.
separate ports for RTP and RTCP in a subsequent offer, unless th </t>
ere is a use-case that mandates </section>
it. </section>
</t> <section numbered="true" toc="default">
</section> <name>Update to RFC 5761</name>
</section> <section numbered="true" toc="default">
<name>General</name>
<section title="Update to RFC 5761"> <t>
<section title="General"> This section updates Sections <xref target="RFC5761"
<t> section="5.1.1" sectionFormat="bare"/> and <xref target="RFC5761"
This section updates sections 5.1.1 and 5.1.3 of <xref target="R section="5.1.3" sectionFormat="bare"/> of <xref target="RFC5761"
FC5761" pageno="false" format="default"/>, by clarifying format="default"/> by clarifying that an offerer can use a
that an offerer can use a mechanism to indicate that it is not a mechanism to indicate that it is not able to send and receive RTCP
ble to send and receive RTCP on separate ports, and that the offerer shall terminate the
on separate ports, and that the offerer shall terminate the affe affected streams if the answerer does not indicate support of
cted streams if the answerer RTP/RTCP multiplexing. It also clarifies that, when the offerer is
does not indicate support of RTP/RTCP multiplexing. It also clar not able to send and receive RTCP on separate ports, the offerer
ifies that, when the will not provide an SDP 'candidate' attribute for RTCP, nor will
offerer is not able to send and receive RTCP on separate ports, the offerer provide a fallback port for RTCP (using the SDP 'rtcp'
the offerer will not provide attribute).
an SDP 'candidate' attribute for RTCP, nor will the offerer prov </t>
ide a fallback port for RTCP </section>
(using the SDP 'rtcp' attribute). <section numbered="true" toc="default">
</t> <name>Update to 4th Paragraph of Section 5.1.1</name>
</section> <t>
<section title="Update to 4th paragraph of section 5.1.1"> NOTE: <xref target="RFC8035" format="default"/> also updates
<t> <xref target="RFC5761" sectionFormat="of"
NOTE: <xref target="RFC8035" pageno="false" format="default"/> a section="5.1.1"/>. While the paragraph updated in this
lso updates section document is not updated by <xref target="RFC8035"
5.1.1 of <xref target="RFC5761" pageno="false" format="default"/ format="default"/>, the location of the paragraph within
>. While the paragraph Section 5.1.1 is moved.
updated in this document is not updated by <xref target="RFC8035 </t>
" pageno="false" format="default"/>,
the location of the paragraph within section 5.1.1 is moved.
</t>
<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 <t>OLD TEXT:</t>
MUST NOT multiplex RTP and RTCP packets on a single port. Instead, <blockquote>
If the answer does not contain an "a=rtcp-mux" attribute, the offerer
<bcp14>MUST NOT</bcp14> multiplex RTP and RTCP packets on a single port. Ins
tead,
it should send and receive RTCP on a port allocated according to the 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 usual port-selection rules (either the port pair, or a signalled port
if the "a=rtcp:" attribute [10] is also included). This will occur 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" when talking to a peer that does not understand the "a=rtcp-mux"
attribute. attribute.</blockquote>
NEW TEXT:
If the answer does not contain an "a=rtcp-mux" attribute, the offerer <t>NEW TEXT:</t>
MUST NOT multiplex RTP and RTCP packets on a single port. Instead, <blockquote>If the answer does not contain an "a=rtcp-mux" attribute, the off
erer
<bcp14>MUST NOT</bcp14> multiplex RTP and RTCP packets on a single port. Ins
tead,
it should send and receive RTCP on a port allocated according to the 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 usual port-selection rules (either the port pair, or a signaled port
if the "a=rtcp:" attribute [10] is also included). This will occur 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" 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 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 not able to send and receive RTCP on a separate port, the offerer
MUST disable the media streams associated with the attribute. The <bcp14>MUST</bcp14> disable the media streams associated with the attribute. The
mechanism for indicating that the offerer is not able to send and mechanism for indicating that the offerer is not able to send and
receive RTCP on a separate port is outside the scope of this receive RTCP on a separate port is outside the scope of this
specification. specification.</blockquote>
]]></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: </section>
<section numbered="true" toc="default">
<name>Update to 2nd Paragraph of Section 5.1.3</name>
If it is desired to use both ICE and multiplexed RTP and RTCP, the <t>OLD TEXT:</t>
initial offer MUST contain an "a=rtcp-mux" attribute to indicate that <blockquote>If it is desired to use both ICE and multiplexed RTP and RTCP, th
RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" e
initial offer <bcp14>MUST</bcp14> contain an "a=rtcp-mux" attribute to indica
te that
RTP and RTCP multiplexing is desired and <bcp14>MUST</bcp14> contain "a=candi
date:"
lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 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 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. This <bcp14>MUST</bcp14> be done for each media w
RTP and RTCP multiplexing is desired. here
RTP and RTCP multiplexing is desired.</blockquote>
NEW TEXT:
If it is desired to use both ICE and multiplexed RTP and RTCP, the <t>NEW TEXT:</t>
initial offer MUST contain an "a=rtcp-mux" attribute to indicate that <blockquote>If it is desired to use both ICE and multiplexed RTP and RTCP, th
RTP and RTCP multiplexing is desired and MUST contain "a=candidate:" e
initial offer <bcp14>MUST</bcp14> contain an "a=rtcp-mux" attribute to indica
te that
RTP and RTCP multiplexing is desired and <bcp14>MUST</bcp14> contain "a=candi
date:"
lines for both RTP and RTCP along with an "a=rtcp:" line indicating a 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 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. This <bcp14>MUST</bcp14> be done for each media w
RTP and RTCP multiplexing is desired. However, if the offerer here
RTP and RTCP multiplexing is desired. However, if the offerer
indicates in the offer that it is not able to send and receive RTCP 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:" on a separate port, the offerer <bcp14>MUST NOT</bcp14> include "a=candidate:
lines for RTCP, and the offerer MUST NOT provide a fallback port for "
RTCP using the "a=rtcp:" line. lines for RTCP and <bcp14>MUST NOT</bcp14> provide a fallback port for
RTCP using the "a=rtcp:" line.</blockquote>
]]></artwork>
</figure>
</section>
</section>
<section title="ICE Considerations"> </section>
<t> </section>
As defined in <xref target="RFC5245"/>, if an entity is aware that t <section numbered="true" toc="default">
he <name>ICE Considerations</name>
<t>
As defined in <xref target="RFC8445" format="default"/>, if an entit
y is aware that the
remote peer supports, and is willing to use, RTP/RTCP multiplexing, remote peer supports, and is willing to use, RTP/RTCP multiplexing,
the entity will only provide RTP candidates (component ID 1). the entity will only provide RTP candidates (component ID 1).
However, only providing RTP candidates does not as such imply However, only providing RTP candidates does not, as such, imply
exclusive support of RTP/RTCP multiplexing. RTCP candidates exclusive support of RTP/RTCP multiplexing. RTCP candidates also
would not be provided also in cases where RTCP is not supported would not be provided in cases where RTCP is not supported
at all. Therefore, additional information is needed in order at all. Therefore, additional information is needed in order
to indicate support of exclusive RTP/RTCP multiplexing. This to indicate support of exclusive RTP/RTCP multiplexing. This
document defines such mechanism using the SDP 'rtcp-mux-only' document defines such a mechanism using the SDP 'rtcp-mux-only'
attributes. attribute.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
This document does not introduce new security considerations This document does not introduce new security considerations
in additions to those specified in <xref target="RFC3605" beyond those specified in <xref target="RFC3605"
pageno="false" format="default"/> and <xref target="RFC5761" format="default"/> and <xref target="RFC5761" format="default"/>.
pageno="false" format="default"/>. </t>
</t> </section>
</section> <section anchor="section.iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
<section anchor="section.iana" title="IANA Considerations">
<t>
This document updates the "Session Description Protocol Parameters" registry This document updates the "Session Description Protocol Parameters" registry
as specified in Section 8.2.2 of <xref target="RFC4566" pageno="fals e" format="default"/>. as specified in <xref target="RFC4566" sectionFormat="of" section="8 .2.4"/>.
Specifically, it adds the SDP 'rtcp-mux-only' attribute to the table for SDP Specifically, it adds the SDP 'rtcp-mux-only' attribute to the table for SDP
media level attributes. media-level attributes.
</t> </t>
<figure> <ul empty="true">
<artwork align="left"><![CDATA[ <li>
<dl>
Attribute name: rtcp-mux-only <dt>Attribute name:</dt><dd>rtcp-mux-only</dd>
Type of attribute: media-level <dt>Type of attribute:</dt><dd>media-level</dd>
Subject to charset: no <dt>Subject to charset:</dt><dd>no</dd>
Purpose: Indicate exclusive support of RTP/RTCP multiplexing <dt>Purpose:</dt><dd>Indicate exclusive support of RTP/RTCP multiplex
Appropriate Values: N/A ing</dd>
Contact name: Christer Holmberg (christer.holmberg@ericsson.com) <dt>Appropriate Values:</dt><dd>N/A</dd>
Mux Category: IDENTICAL <dt>Contact name:</dt><dd><t><contact fullname="Christer Holmberg"/>
(christer.holmberg@ericsson.com)</t></dd>
]]></artwork> <dt>Mux Category:</dt><dd>IDENTICAL</dd>
</figure> </dl>
</li>
</ul>
</section> </section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3264.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.4566.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8445.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.5761.xml"/>
<xi:include
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
8035.xml"/>
<section title="Acknowledgments"> <!-- draft-ietf-mmusic-sdp-mux-attributes-17 (RFC 8859) -->
<t> <reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8
Thanks to Roman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman, 859">
Tomas Frankkila and Martin Thomson for their comments and input <front>
on the document. Thanks to Francis Dupont for the genart review. <title>A Framework for Session Description Protocol (SDP)
</t> Attributes When Multiplexing</title>
</section> <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar
">
<organization/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8859"/>
<seriesInfo name="DOI" value="10.17487/RFC8859"/>
<section title="Change Log"> </reference>
<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>
<t>
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-11
<list style="symbols">
<t>
Clarification note added to RFF 5761 update section.
</t>
</list>
</t>
<t>
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-10
<list style="symbols">
<t>
Changes based on comments from Ekr:
</t>
<t>
- 'rtcp-mux-only' attribute only defined for SDP offers
</t>
</list>
</t>
<t>
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-09
<list style="symbols">
<t>
Changes based on IESG review comments from Alexey Melnikov
and Mirja Kuhlewind:
</t>
<t>
- References to draft-mux-attributes and draft-sdp-bundle
made normative.
</t>
<t>
- Text added regarding cases where entities might want to
use non-multiplexed RTP and RTCP.
</t>
</list>
</t>
<t>
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-08
<list style="symbols">
<t>
Editorial changes based on genart comments from Francis Dupont.
</t>
</list>
</t>
<t>
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-07
<list style="symbols">
<t>
Comments from Ben Campbell.
</t>
<t>
- Additional text regarding applications for which the mechanism is s
uitable.
</t>
<t>
- Removal of pre-RFC5378 disclaimer.
</t>
<t>
- Editorial fixes.
</t>
</list>
</t>
<t>
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-06
<list style="symbols">
<t>
- Editorial fix.
</t>
<t>
- Addition of pre-RFC5378 disclaimer.
</t>
</list>
</t>
<t>
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-05
<list style="symbols">
<t>
Editorial fix.
</t>
</list>
</t>
<t>
Changes from draft-ietf-mmusic-rtcp-mux-exclusive-04
<list style="symbols">
<t>
Changes based on comments from Flemming Andreasen.
</t>
<t>
- Attribute mux category changed to IDENTICAL.
</t>
<t>
- Reference to draft-5245bis changed to RFC 5245.
</t>
</list>
</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> <!-- draft-ietf-mmusic-sdp-bundle-negotiation (RFC 8843) -->
<reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843"
>
<front>
<title>Negotiating Media Multiplexing Using the Session Description Prot
ocol (SDP)</title>
<author initials="C" surname="Holmberg" fullname="Christer Holmberg">
<organization/>
</author>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
<organization/>
</author>
<author initials="C" surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8843"/>
<seriesInfo name="DOI" value="10.17487/RFC8843"/>
</reference>
<references title="Normative References"> </references>
<?rfc include="reference.RFC.2119"?> <references>
<?rfc include="reference.RFC.3264"?> <name>Informative References</name>
<?rfc include="reference.RFC.4566"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.5245"?> ence.RFC.3605.xml"/>
<?rfc include="reference.RFC.5761"?> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<?rfc include="reference.RFC.8035"?> ence.RFC.5576.xml"/>
<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-mux-attributes-16"?>
<?rfc include="reference.I-D.draft-ietf-mmusic-sdp-bundle-negotiation-36"?>
</references>
<references title="Informative References"> <reference anchor="WebRTC" target="https://www.w3.org/TR/webrtc/">
<?rfc include="reference.RFC.3605"?> <front>
<?rfc include="reference.RFC.5576"?> <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
<?rfc include='reference.W3C.WD-webrtc-20120209'?>
</references>
</back> <author initials="C" surname="Jennings" fullname="Cullen Jennings">
<organization/>
</author>
<author initials="H" surname="Boström" fullname="Henrik Boström">
<organization/>
</author>
<author initials="J-I" surname="Bruaroey" fullname="Jan-Ivar Bruaroe
y">
<organization/>
</author>
</front>
<refcontent>W3C Proposed Recommendation</refcontent>
</reference>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
Thanks to <contact fullname="Roman Shpount"/>, <contact
fullname="Paul Kyzivat"/>, <contact fullname="Ari Keränen"/>,
<contact fullname="Bo Burman"/>, <contact fullname="Tomas Frankkila"
/>, and <contact
fullname="Martin Thomson"/> for their comments and input on the
document. Thanks to <contact fullname="Francis Dupont"/> for the
GENART review.
</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 64 change blocks. 
613 lines changed or deleted 473 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/