<?xmlversion="1.0" encoding="iso-8859-1"?> <!-- comment -->version='1.0' encoding='utf-8'?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd"[]> <?rfc toc="yes" ?> <?rfc compact="yes" ?> <?rfc sortrefs="no" ?>"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="std"docName="draft-ietf-mmusic-mux-exclusive-12.txt"updates="5761" submissionType="IETF"xml:lang="en">number="8858" consensus="true" obsoletes="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3" docName="draft-ietf-mmusic-mux-exclusive-12"> <front> <title abbrev="Exclusive RTP/RTCP Mux"> Indicating Exclusive Support ofRTP/RTCPRTP and RTP Control Protocol (RTCP) Multiplexingusing SDPUsing the Session Description Protocol (SDP) </title> <seriesInfo name="RFC" value="8858"/> <author fullname="Christer Holmberg"initials="C.H."initials="C." 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><phone/> <email>christer.holmberg@ericsson.com</email> </address> </author> <dateyear="2017" />month="January" year="2021"/> <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>WebRTC</keyword> <keyword>JSEP</keyword> <abstract> <t> This document defines a newSDPSession Description Protocol (SDP) media-level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support ofRTP/RTCPRTP and RTP Control Protocol (RTCP) multiplexing. The document also updates RFC5761,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> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <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 anSession Description Protocol (SDP)SDP <xref target="RFC4566"pageno="false"format="default"/> attribute,'rtcp-mux''rtcp-mux', that can be used by entities to indicatesupport,support of RTP/RTCP multiplexing and negotiate usageof, RTP/RTCP multiplexing.of it. </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 choosetonot to implement separation of RTP and RTCP. Examples of such applications are W3CWEBRTCWebRTC applications <xreftarget="W3C.WD-webrtc-20120209"/> applications, thattarget="WebRTC" format="default"/>, which are not required to interoperate withnon-WEBRTCnon-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 <xref format="default"pageno="false"target="RFC3264"/>bymay harm the interoperability of entities that ever need to interoperate with peers that do not support RTC/RTCPmultiplexing may harm interoperability.multiplexing. Also, while the SDP answerer <xref format="default"pageno="false"target="RFC3264"/> might support, and prefer usage of, fallback tonon-multiplex,nonmultiplex, the attribute indicates that fallback tonon-multiplexnonmultiplex cannot be enabled. One example of wherenon-multiplexnonmultiplex is preferred is where an endpoint is connected to a radiointerface,interface and wants to use different bearers (possibly with different quality characteristics) for RTP and RTCP. Another example is wheretheone endpoint is acting as a gateway to a network where RTP/RTCP multiplexing cannot be used. In suchcase therea case, the endpoint mayprefer non-multiplexingalso prefer nonmultiplexing towards the other network.OtherwiseOtherwise, the endpoint would have to performde-multiplexingdemultiplexing of RTP and RTCP. </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 <xref target="RFC5761"pageno="false" format="default"/>,format="default"/> 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>TheThis document also describes the Interactive Connectivity Establishment (ICE) <xreftarget="RFC5245"/>target="RFC8445" format="default"/> considerations when indicating exclusive support of RTP/RTCP multiplexing. </t> </section> <sectiontitle="Conventions">numbered="true" toc="default"> <name>Conventions</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY","<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"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="RFC2119"></xref>.target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> <sectiontitle="SDP rtcp-mux-only Attribute" anchor="sec-dcon-attr"> <t> Thisanchor="sec-dcon-attr" numbered="true" toc="default"> <name>SDP 'rtcp-mux-only' Attribute</name> <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><ul empty="true"> <li> <dl> <dt>Name:</dt><dd>rtcp-mux-only</dd> <dt>Value:</dt><dd>N/A</dd> <dt>Usage Level:</dt><dd>media</dd> <dt>Charset Dependent:</dt><dd>no</dd> <dt>Syntax:</dt> <dd>rtcp-mux-only</dd> <dt>Example:</dt> <dd>a=rtcp-mux-only</dd> </dl> </li> </ul> <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' attribute <xref target="RFC5761"pageno="false"format="default"/> 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 'rtcp-mux-only' attribute in an SDP answer is forbidden. </t> <t> The usage of the SDP 'rtcp-mux-only' attribute is only defined for RTP-based media. </t> <t> The mux category <xreftarget="I-D.ietf-mmusic-sdp-mux-attributes"/>target="RFC8859" format="default"/> for the 'rtcp-mux-only' attribute is'IDENTICAL',"IDENTICAL", which means that the attribute, if used within a BUNDLE group <xreftarget="I-D.ietf-mmusic-sdp-bundle-negotiation"/>,target="RFC8843" format="default"/>, must be associated with all multiplexed RTP-based media descriptions within the BUNDLE group. </t> <t> The 'rtcp-mux-only' attribute applies to the whole associated media description. The attributeMUST NOT<bcp14>MUST NOT</bcp14> be defined per source (using the SDP 'ssrc' attribute <xref format="default"pageno="false"target="RFC5576"/>). </t> <t> The SDP offer/answer procedures <xref format="default"pageno="false"target="RFC3264"/>proceduresassociated with the attribute are defined in <xreftarget="sec-oa"/>target="sec-oa" format="default"/>. </t> </section> <sectiontitle="SDPanchor="sec-oa" numbered="true" toc="default"> <name>SDP Offer/AnswerProcedures" anchor="sec-oa">Procedures</name> <sectiontitle="General">numbered="true" toc="default"> <name>General</name> <t> This section defines the SDP offer/answer procedures <xref format="default"pageno="false"target="RFC3264"/>proceduresfor indicating exclusive supportof,of RTP/RTCP multiplexing and negotiating usageof, RTP/RTCP multiplexing.of it. </t> <t> The procedures in this section apply to individual RTP-based SDP media descriptions ("m=" lines). </t> </section> <sectiontitle="Generatinganchor="sec-of-ini-off" numbered="true" toc="default"> <name>Generating the Initial SDPOffer" anchor="sec-of-ini-off">Offer</name> <t> Whenan offerer sendssending the initial offer, if the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media,the offerer MUSTit <bcp14>MUST</bcp14> 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,line), the offererMUST<bcp14>MUST</bcp14> 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' attributeMUST<bcp14>MUST</bcp14> 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> <sectiontitle="Generatingnumbered="true" toc="default"> <name>Generating theAnswer">Answer</name> <t> When an answerer receives an offer that contains an SDP 'rtcp-mux-only'attribute,attribute associated with an RTP-based SDP media description ("m=" line), then if the answerer accepts the usage of RTP/RTCP multiplexing,the answerer MUSTit <bcp14>MUST</bcp14> associate an SDP 'rtcp-mux' attribute with the corresponding SDP media description ("m=") in the associated answer, following the procedures in <xref target="RFC5761"pageno="false"format="default"/>. If the answerer does not accept the usage of RTP/RTCP multiplexing,the answerer MUSTit <bcp14>MUST</bcp14> 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> The answererMUST NOT<bcp14>MUST NOT</bcp14> associate an SDP 'rtcp-mux-only' attribute with an SDP media description ("m=" line) in the answer. </t> </section> <sectiontitle="Offereranchor="sec-of-off-ans" numbered="true" toc="default"> <name>Offerer Processing of the SDPAnswer" anchor="sec-of-off-ans">Answer</name> <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' attribute, the offererMUST<bcp14>MUST</bcp14> 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' attribute, the offererMUST<bcp14>MUST</bcp14> either take appropriate actions in order to disable the associated RTP-basedmedia,media -- e.g., send a new offer with a zero port value associated with the SDP media description ("m="line),line) -- 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 offerermight e.g. sendmight, for example, terminate the RTP media by sending a new offerwherein which the port value of the SDP media description is set tozero in order to terminate the RTP media.zero. </t> </section> <sectiontitle="Modifyingnumbered="true" toc="default"> <name>Modifying theSession">Session</name> <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 offererSHOULD<bcp14>SHOULD</bcp14> 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 offererMUST<bcp14>MUST</bcp14> 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)line), it is an indication that the offerer no longer wants to use RTP/RTCPmultiplexing,multiplexing and insteadMUST fallback<bcp14>MUST</bcp14> fall back 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 offererMAY<bcp14>MAY</bcp14> indicate exclusive support of RTP/RTCP multiplexing, following the procedures in <xreftarget="sec-of-ini-off"/>.target="sec-of-ini-off" format="default"/>. The offererMUST<bcp14>MUST</bcp14> process the associated answer following the procedures in <xreftarget="sec-of-off-ans"/>.target="sec-of-off-ans" format="default"/>. </t> <t> It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> 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 ause-caseuse case that mandates it. </t> </section> </section> <sectiontitle="Updatenumbered="true" toc="default"> <name>Update to RFC5761">5761</name> <sectiontitle="General">numbered="true" toc="default"> <name>General</name> <t> This section updatessections 5.1.1Sections <xref target="RFC5761" section="5.1.1" sectionFormat="bare"/> and5.1.3<xref target="RFC5761" section="5.1.3" sectionFormat="bare"/> of <xref target="RFC5761"pageno="false" format="default"/>,format="default"/> 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> <sectiontitle="Updatenumbered="true" toc="default"> <name>Update to 4thparagraphParagraph ofsection 5.1.1">Section 5.1.1</name> <t> NOTE: <xref target="RFC8035"pageno="false"format="default"/> also updatessection 5.1.1 of<xref target="RFC5761"pageno="false" format="default"/>.sectionFormat="of" section="5.1.1"/>. While the paragraph updated in this document is not updated by <xref target="RFC8035"pageno="false"format="default"/>, the location of the paragraph withinsectionSection 5.1.1 is moved. </t><figure> <artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[ OLD TEXT:<t>OLD TEXT:</t> <blockquote> If the answer does not contain an "a=rtcp-mux" attribute, the offererMUST NOT<bcp14>MUST NOT</bcp14> 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: Ifattribute.</blockquote> <t>NEW TEXT:</t> <blockquote>If the answer does not contain an "a=rtcp-mux" attribute, the offererMUST NOT<bcp14>MUST NOT</bcp14> 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 offererMUST<bcp14>MUST</bcp14> 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 thisspecification. ]]></artwork> </figure>specification.</blockquote> </section> <sectiontitle="Updatenumbered="true" toc="default"> <name>Update to 2ndparagraphParagraph ofsection 5.1.3"> <figure> <artwork align="left" alt="" height="" name="" type="" width="" xml:space="preserve"><![CDATA[ OLD TEXT: IfSection 5.1.3</name> <t>OLD TEXT:</t> <blockquote>If it is desired to use both ICE and multiplexed RTP and RTCP, the initial offerMUST<bcp14>MUST</bcp14> contain an "a=rtcp-mux" attribute to indicate that RTP and RTCP multiplexing is desired andMUST<bcp14>MUST</bcp14> 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. ThisMUST<bcp14>MUST</bcp14> be done for each media where RTP and RTCP multiplexing isdesired. NEW TEXT: Ifdesired.</blockquote> <t>NEW TEXT:</t> <blockquote>If it is desired to use both ICE and multiplexed RTP and RTCP, the initial offerMUST<bcp14>MUST</bcp14> contain an "a=rtcp-mux" attribute to indicate that RTP and RTCP multiplexing is desired andMUST<bcp14>MUST</bcp14> 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. ThisMUST<bcp14>MUST</bcp14> 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 offererMUST NOT<bcp14>MUST NOT</bcp14> include "a=candidate:" lines forRTCP,RTCP andthe offerer MUST NOT<bcp14>MUST NOT</bcp14> provide a fallback port for RTCP using the "a=rtcp:"line. ]]></artwork> </figure>line.</blockquote> </section> </section> <sectiontitle="ICE Considerations">numbered="true" toc="default"> <name>ICE Considerations</name> <t> As defined in <xreftarget="RFC5245"/>,target="RFC8445" format="default"/>, 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 doesnotnot, assuchsuch, imply exclusive support of RTP/RTCP multiplexing. RTCP candidates also would not be providedalsoin 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'attributes.attribute. </t> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> This document does not introduce new security considerationsin additions tobeyond 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">numbered="true" toc="default"> <name>IANA Considerations</name> <t> This document updates the "Session Description Protocol Parameters" registry as specified inSection 8.2.2 of<xref target="RFC4566"pageno="false" format="default"/>.sectionFormat="of" section="8.2.4"/>. Specifically, it adds the SDP 'rtcp-mux-only' attribute to the table for SDPmedia levelmedia-level attributes. </t><figure> <artwork align="left"><![CDATA[ Attribute name: rtcp-mux-only Type<ul empty="true"> <li> <dl> <dt>Attribute name:</dt><dd>rtcp-mux-only</dd> <dt>Type ofattribute: media-level Subjectattribute:</dt><dd>media-level</dd> <dt>Subject tocharset: no Purpose: Indicatecharset:</dt><dd>no</dd> <dt>Purpose:</dt><dd>Indicate exclusive support of RTP/RTCPmultiplexing Appropriate Values: N/A Contact name: Christer Holmberg (christer.holmberg@ericsson.com) Mux Category: IDENTICAL ]]></artwork> </figure>multiplexing</dd> <dt>Appropriate Values:</dt><dd>N/A</dd> <dt>Contact name:</dt><dd><t><contact fullname="Christer Holmberg"/> (christer.holmberg@ericsson.com)</t></dd> <dt>Mux Category:</dt><dd>IDENTICAL</dd> </dl> </li> </ul> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5761.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8035.xml"/> <!-- draft-ietf-mmusic-sdp-mux-attributes-17 (RFC 8859) --> <reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8859"> <front> <title>A Framework for Session Description Protocol (SDP) Attributes When Multiplexing</title> <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"/> </reference> <!-- 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 Protocol (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> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3605.xml"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5576.xml"/> <reference anchor="WebRTC" target="https://www.w3.org/TR/webrtc/"> <front> <title>WebRTC 1.0: Real-time Communication Between Browsers</title> <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 Bruaroey"> <organization/> </author> </front> <refcontent>W3C Proposed Recommendation</refcontent> </reference> </references> </references> <sectiontitle="Acknowledgments">numbered="false" toc="default"> <name>Acknowledgements</name> <t> Thanks toRoman Shpount, Paul Kyzivat, Ari Keranen, Bo Burman, Tomas Frankkila and Martin Thomson<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 toFrancis Dupont<contact fullname="Francis Dupont"/> for thegenartGENART review. </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-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 suitable. </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> <references title="Normative References"> <?rfc include="reference.RFC.2119"?> <?rfc include="reference.RFC.3264"?> <?rfc include="reference.RFC.4566"?> <?rfc include="reference.RFC.5245"?> <?rfc include="reference.RFC.5761"?> <?rfc include="reference.RFC.8035"?> <?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"> <?rfc include="reference.RFC.3605"?> <?rfc include="reference.RFC.5576"?> <?rfc include='reference.W3C.WD-webrtc-20120209'?> </references></back> </rfc>