<?xmlversion="1.0" encoding="iso-8859-1"?>version='1.0' encoding='utf-8'?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml"> <!ENTITY RFC3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml"> ]> <?rfc toc="yes" ?> <?rfc compact="yes" ?> <?rfc subcompact="yes" ?> <?rfc sortrefs="no" ?> <?rfc strict="yes" ?>"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="exp" docName="draft-ietf-clue-datachannel-18" number="8850" obsoletes="" updates="" submissionType="IETF"xml:lang="en">consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 2.38.1 --> <front> <title abbrev="CLUEdata channel"> CLUEData Channel">Controlling Multiple Streams for Telepresence (CLUE) Protocoldata channel </title>Data Channel</title> <seriesInfo name="RFC" value="8850"/> <authorinitials="C.H."initials="C." surname="Holmberg" fullname="Christer Holmberg"> <organization>Ericsson</organization> <address> <postal> <street>Hirsalantie 11</street> <code>02420</code> <city>Jorvas</city> <country>Finland</country> </postal> <email>christer.holmberg@ericsson.com</email> </address> </author> <dateyear="2019" /> <area>Transport</area> <workgroup>CLUE Working Group</workgroup>month="January" year="2021"/> <keyword>SIP</keyword> <keyword>SDP</keyword> <keyword>DTLS</keyword> <keyword>SCTP</keyword> <keyword>DATA</keyword> <keyword>CHANNEL</keyword> <keyword>DCEP</keyword> <keyword>DATA_CHANNEL_OPEN</keyword> <keyword>DATA_CHANNEL_ACK</keyword> <keyword>PPID</keyword> <keyword>TELEPRESENCE</keyword> <keyword>RTCWEB</keyword> <keyword>WEBRTC</keyword> <abstract> <t> This document defines how to use the WebRTC data channel mechanism to realize a data channel, referred to as aCLUEControlling Multiple Streams for Telepresence (CLUE) data channel, for transporting CLUE protocol messages between two CLUE entities. </t> </abstract> </front> <middle> <sectiontitle="Introduction" toc="default">toc="default" numbered="true"> <name>Introduction</name> <t> This document defines how to use the WebRTC data channel mechanism <xreftarget="I-D.ietf-rtcweb-data-channel" pageno="false" format="default" />target="RFC8831" format="default"/> to realize a data channel, referred to as aCLUEControlling Multiple Streams for Telepresence (CLUE) data channel, for transporting CLUE protocol<xref target="I-D.ietf-clue-protocol" pageno="false" format="default" />messages <xref target="RFC8847" format="default"/> between two CLUE entities. </t> <t>TheThis document also defines how to describe the SCTPoDTLS association <xref target="RFC8261"pageno="false" format="default" />format="default"/> (also referred to as "SCTP over DTLS" in this document) used to realize the CLUE data channel using the Session Description Protocol (SDP) <xref target="RFC4566"pageno="false" format="default" />,format="default"/> and defines usage of the SDP-based "SCTP over DTLS" data channel negotiation mechanism <xreftarget="I-D.ietf-mmusic-data-channel-sdpneg" pageno="false" format="default" />.target="RFC8864" format="default"/>. ("SCTP" stands for "Stream Control Transmission Protocol".) This includes SCTP considerations specific to a CLUE data channel, the SDPMedia Descriptionmedia description ("m=" line) values, and usage of SDP attributes specific to a CLUE data channel. </t> <t> Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures <xref target="RFC3264"pageno="false" format="default" /> proceduresformat="default"/> for negotiating usage of a CLUE data channel, are outside the scope of this document. </t><t> NOTE:<aside><t>NOTE: The usage of the Data Channel Establishment Protocol (DCEP) <xreftarget="I-D.ietf-rtcweb-data-protocol" pageno="false" format="default" />target="RFC8832" format="default"/> for establishing a CLUE data channel is outside the scope of thisdocument. </t>document.</t></aside> </section> <sectiontitle="Conventions" toc="default"> <t> Thetoc="default" numbered="true"> <name>Conventions</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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 inBCP 14BCP 14 <xreftarget="RFC2119"></xref>target="RFC2119"/> <xreftarget="RFC8174"></xref>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere. </t> <t> SCTPoDTLS association refershere.</t> <dl newline="true" spacing="normal"> <dt>SCTPoDTLS association</dt> <dd>Refers to an SCTP association carried overana DTLS connection <xref target="RFC8261"pageno="false" format="default" />. </t> <t> WebRTCformat="default"/>.</dd> <dt>WebRTC datachannel referschannel</dt> <dd>Refers to a pair of SCTP streams overaan SCTPoDTLS association that is used to transport non-media data between two entities, as defined in <xreftarget="I-D.ietf-rtcweb-data-channel" pageno="false" format="default" />. </t> <t> CLUEtarget="RFC8831" format="default"/>.</dd> <dt>CLUE datachannel referschannel</dt> <dd>Refers to a WebRTC data channel realization <xreftarget="I-D.ietf-rtcweb-data-channel" pageno="false" format="default" /> realization,target="RFC8831" format="default"/>, with a specific set of SCTP characteristics, with the purpose of transporting CLUE protocol<xref target="I-D.ietf-clue-protocol" pageno="false" format="default" />messages <xref target="RFC8847" format="default"/> between two CLUEentities. </t> <t> CLUE entity refersentities.</dd> <dt>CLUE entity</dt> <dd>Refers to a SIP User Agent (UA) <xref target="RFC3261"pageno="false" format="default" />format="default"/> that supports the CLUE data channel and the CLUEprotocol. </t> <t> CLUE session refersprotocol.</dd> <dt>CLUE session</dt> <dd>Refers to a SIP session <xref target="RFC3261"pageno="false" format="default" />format="default"/> between two SIP UAs, where a CLUE data channel, associated with the SIP session, has been established between the SIPUAs. </t> <t> SCTP stream is definedUAs.</dd> <dt>SCTP stream</dt> <dd>Defined in <xref target="RFC4960"pageno="false" format="default" />format="default"/> as a unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered deliveryservice. </t> <t> SCTP identifier is definedservice.</dd> <dt>SCTP stream identifier</dt> <dd>Defined in <xref target="RFC4960"pageno="false" format="default" />format="default"/> as an unsignedinteger, which identifiesinteger. Identifies an SCTPstream. </t>stream.</dd> </dl> </section> <section anchor="section.dtls"title="CLUE data channel" toc="default">toc="default" numbered="true"> <name>CLUE Data Channel</name> <section anchor="section.cdc.gen"title="General" toc="default">toc="default" numbered="true"> <name>General</name> <t> This section describes the realization of a CLUE data channel, using the WebRTC data channel mechanism. This includes a set of SCTP characteristics specific to a CLUE data channel, the values of the "m=" line describing the SCTPoDTLS association associated with the WebRTC data channel, and the usage of the SDP-based "SCTP over DTLS" data channel negotiation mechanism for creating the CLUE data channel. </t> <t> As described in <xreftarget="I-D.ietf-rtcweb-data-channel" pageno="false" format="default" />,target="RFC8831" format="default"/>, the SCTP streams realizing a WebRTC data channel must be associated with the same SCTP association. In addition, both SCTP streams realizing the WebRTC data channel must use the same SCTP stream identifier value. These rules also apply to a CLUE data channel. </t> <t> Within a given CLUE session, a CLUE entityMUST<bcp14>MUST</bcp14> use a single CLUE data channel for transport of all CLUE messages towards its peer. </t> </section> <section anchor="section.cdc.sctp"title="SCTP Considerations" toc="default">toc="default" numbered="true"> <name>SCTP Considerations</name> <section anchor="section.cdc.sctp.gen"title="General" toc="default">toc="default" numbered="true"> <name>General</name> <t> As described in <xreftarget="I-D.ietf-rtcweb-data-channel" pageno="false" format="default" />,target="RFC8831" format="default"/>, different SCTP options (e.g., regarding ordereddelivery ),delivery) can be used for a data channel. This section describes the SCTP options used for a CLUE data channel. <xref target="section.oa"pageno="false" format="default" />format="default"/> describes how SCTP options are signaled using SDP. </t><t> NOTE: While SCTP allows SCTP options to be applied per SCTP message, <xref target="I-D.ietf-rtcweb-data-channel" pageno="false" format="default" /> mandates that, for a given data channel, the same SCTP options are applied to each SCTP message associated with that data channel. </t></section> <section anchor="section.cdc.sctp.ppid"title="SCTPtoc="default" numbered="true"> <name>SCTP Payload Protocol Identifier(PPID)" toc="default">(PPID)</name> <t> A CLUE entityMUST<bcp14>MUST</bcp14> use the PPID value 51 when sending a CLUE message on a CLUE data channel. </t><t><aside><t> NOTE: As described in <xreftarget="I-D.ietf-rtcweb-data-channel" pageno="false" format="default" />,target="RFC8831" format="default"/>, the PPID value 51 indicates that the SCTP message contains data encoded inaUTF-8 format. The PPID value 51 does not indicate which application protocol the SCTP message is associatedwith,with -- only the format in which the data is encoded.</t></t></aside> </section> <section anchor="section.cdc.sctp.reliability"title="Reliability" toc="default">toc="default" numbered="true"> <name>Reliability</name> <t> The usage of SCTP for the CLUE data channel ensures reliable transport of CLUE protocol messages <xreftarget="I-D.ietf-clue-protocol" pageno="false" format="default" /> messages. </t>target="RFC8847" format="default"/>.</t> <t> <xreftarget="I-D.ietf-rtcweb-data-channel" pageno="false" format="default" />target="RFC8831" format="default"/> requires the support of the partial reliability extension defined in <xref target="RFC3758"pageno="false" format="default" />format="default"/> and the limited retransmission policy defined in <xref target="RFC7496"pageno="false" format="default" />.format="default"/>. A CLUE entityMUST NOT<bcp14>MUST NOT</bcp14> use these extensions, as messages are required to always be sent reliably. A CLUE entityMUST<bcp14>MUST</bcp14> terminate the session if it detects that the peer entity uses any of the extensions. </t> </section> <section anchor="section.cdc.sctp.order"title="Order" toc="default">toc="default" numbered="true"> <name>Order</name> <t> A CLUE entityMUST<bcp14>MUST</bcp14> use the ordered delivery SCTP service, as described in <xref target="RFC4960"pageno="false" format="default" />,format="default"/>, for the CLUE data channel. </t> </section> <section anchor="section.cdc.sctp.streamreset"title="Stream Reset" toc="default">toc="default" numbered="true"> <name>Stream Reset</name> <t> A CLUE entityMUST<bcp14>MUST</bcp14> support the stream reset extension defined in <xref target="RFC6525"pageno="false" format="default" />.format="default"/>. </t> <t>As defined inPer <xreftarget="I-D.ietf-rtcweb-data-channel" pageno="false" format="default" />,target="RFC8831" format="default"/>, the dynamic address reconfiguration extension parameter ('Supported ExtensionsParameter' parameter)Parameter') defined in <xref target="RFC5061"pageno="false" format="default" />format="default"/> must be used to signal the support of the stream reset extension defined in <xref target="RFC6525"pageno="false" format="default" />.format="default"/>. Other featuresofdefined in <xref target="RFC5061"pageno="false" format="default" /> MUST NOTformat="default"/> <bcp14>MUST NOT</bcp14> be used for CLUE data channels. </t> </section> <section anchor="section.cdc.sctp.multihome"title="SCTP Multihoming" toc="default">toc="default" numbered="true"> <name>SCTP Multihoming</name> <t> SCTPmulti-homingmultihoming is not supported for SCTPoDTLSassociations,associations andcanthereforenotcannot be used for a CLUE data channel. </t> </section> <section anchor="section.cdcp.proc.close"title="Closingtoc="default" numbered="true"> <name>Closing the CLUEdata channel" toc="default">Data Channel</name> <t> As described in <xreftarget="I-D.ietf-rtcweb-data-channel" pageno="false" format="default" />,target="RFC8831" format="default"/>, to close a data channel, an entity sends an SCTP reset message <xref target="RFC6525"pageno="false" format="default" />format="default"/> on its outgoing SCTP stream associated with the data channel. When the remote peer receives the reset message, it also sends (unless already sent) a reset message on its outgoing SCTP stream associated with the data channel. The SCTPoDTLS association, and other data channels established on the same association, are not affected by the SCTP reset messages. </t> </section> </section> <section anchor="section.oa"title="SDP Considerations" toc="default">toc="default" numbered="true"> <name>SDP Considerations</name> <section anchor="section.oa.gen"title="General" toc="default"> <t> Thistoc="default" numbered="true"> <name>General</name> <t>This section defines how to (1) construct the SDPMedia Descriptionmedia description ("m=" line) for describing the SCTPoDTLS association used to realize a CLUE datachannel. The section also defines how to usechannel and (2) use the SDP-based "SCTP over DTLS" data channel negotiation mechanism <xreftarget="I-D.ietf-mmusic-data-channel-sdpneg" />target="RFC8864" format="default"/> for establishing a CLUE data channel on the SCTPoDTLSassociation. </t> <t>association.</t> <aside><t> NOTE:Other protocolsProtocols other than SDP for negotiating usage of an SCTPoDTLS association for realizing a CLUE data channel are outside the scope of this specification.</t></t></aside> <t> <xreftarget="I-D.ietf-clue-signaling" pageno="false" format="default" />target="RFC8848" format="default"/> describes the SDP Offer/Answer procedures for negotiating a CLUE session, including theCLUE controlledCLUE-controlled media streams and the CLUE data channel. </t> <section anchor="section.oa.mediadesc"title="SDPtoc="default" numbered="true"> <name>SDP Media DescriptionFields" toc="default">Fields</name> <t> <xreftarget="I-D.ietf-mmusic-sctp-sdp" pageno="false" format="default" />target="RFC8841" format="default"/> defines how to set the values of an "m=" line describing an SCTPoDTLS association. As defined in <xreftarget="I-D.ietf-mmusic-sctp-sdp" pageno="false" format="default" />,target="RFC8841" format="default"/>, for a CLUE data channel the values are set asfollowing:follows: </t><texttable<table anchor="table_SDP_mediadesc"title='SDPalign="center"> <name>SDP "proto"field values'> <ttcol align='center'>media</ttcol> <ttcol align='center'>port</ttcol> <ttcol align='center'>proto</ttcol> <ttcol align='center'>fmt</ttcol> <c>"application"</c> <c>UDPField Values</name> <thead> <tr> <th align="center">media</th> <th align="center">port</th> <th align="center">proto</th> <th align="center">fmt</th> </tr> </thead> <tbody> <tr> <td align="center">"application"</td> <td align="center">UDP portvalue</c> <c>"UDP/DTLS/SCTP"</c> <c>"webrtc-datachannel"</c> <c>"application"</c> <c>TCPvalue</td> <td align="center">"UDP/DTLS/SCTP"</td> <td align="center">"webrtc-datachannel"</td> </tr> <tr> <td align="center">"application"</td> <td align="center">TCP portvalue</c> <c>"TCP/DTLS/SCTP"</c> <c>"webrtc-datachannel"</c> </texttable>value</td> <td align="center">"TCP/DTLS/SCTP"</td> <td align="center">"webrtc-datachannel"</td> </tr> </tbody> </table> <t> CLUE entitiesSHOULD NOT<bcp14>SHOULD NOT</bcp14> transport the SCTPoDTLS association used to realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP" proto value), unless it is known that UDP/DTLS/SCTP will not work (for instance, when the Interactive Connectivity Establishment (ICE) mechanism <xref format="default"pageno="false"target="RFC8445"/> is used and the ICE procedures determine that TCP transport is required). </t> </section> <section anchor="section.oa.sctpport"title="SDPtoc="default" numbered="true"> <name>SDP sctp-portAttribute" toc="default">Attribute</name> <t> As defined in <xreftarget="I-D.ietf-mmusic-sctp-sdp" pageno="false"target="RFC8841" format="default"/>, the SDP sctp-port attribute value is set to the SCTP port of the SCTPoDTLS association. A CLUE entity can choose any valid SCTP port value <xreftarget="I-D.ietf-mmusic-sctp-sdp" pageno="false"target="RFC8841" format="default"/>. </t> </section> </section> <section anchor="section.oa.dcmap"title="SDPtoc="default" numbered="true"> <name>SDP dcmapAttribute" toc="default">Attribute</name> <t> The values of the SDP dcmap attribute <xreftarget="I-D.ietf-mmusic-data-channel-sdpneg" pageno="false" format="default" />,target="RFC8864" format="default"/>, associated with the "m=" line describing the SCTPoDTLS association used to realize the WebRTC data channel, are set asfollowing:follows: </t><texttable<table anchor="table_SDP_dcmap"title='SDPalign="center"> <name>SDP dcmapattribute values'> <ttcol align='center'>stream-id</ttcol> <ttcol align='center'>sub-protocol</ttcol> <ttcol align='center'>label</ttcol> <ttcol align='center'>ordered</ttcol> <ttcol align='center'>max-retr</ttcol> <ttcol align='center'>max-time</ttcol> <c>ValueAttribute Values</name> <thead> <tr> <th align="center">stream-id</th> <th align="center">subprotocol</th> <th align="center">label</th> <th align="center">ordered</th> <th align="center">max-retr</th> <th align="center">max-time</th> </tr> </thead> <tbody> <tr> <td align="center">Value of the SCTP stream used to realize the CLUE datachannel</c> <c>"CLUE"</c> <c>Appli-cation specific</c> <c>"true"</c> <c>N/A</c> <c>N/A</c> </texttable> <t>channel</td> <td align="center">"CLUE"</td> <td align="center">Application specific</td> <td align="center">"true"</td> <td align="center">N/A</td> <td align="center">N/A</td> </tr> </tbody> </table> <aside><t> NOTE: As CLUE entities are required to use ordered SCTP message delivery, with full reliability, according to the procedures in <xreftarget="I-D.ietf-mmusic-data-channel-sdpneg" pageno="false" format="default" />target="RFC8864" format="default"/> the max-retr and max-time attribute parameters are not used when negotiating CLUE data channels.</t></t></aside> </section> <section anchor="section.oa.dcsa"title="SDPtoc="default" numbered="true"> <name>SDP dcsaAttribute" toc="default">Attribute</name> <t> The SDP dcsa attribute <xreftarget="I-D.ietf-mmusic-data-channel-sdpneg" pageno="false" format="default" />target="RFC8864" format="default"/> is not used when establishing a CLUE data channel. </t> </section> <section anchor="section.oa.example"title="Example" toc="default">toc="default" numbered="true"> <name>Example</name> <t> The example in <xref target="figure_SDP_example"pageno="false" format="default" />format="default"/> shows an SDP media description for a CLUE data channel.Examples of completeComplete SDP examples can be found in <xreftarget="I-D.ietf-clue-signaling" pageno="false" format="default" />.target="RFC8848" format="default"/>. </t> <figureanchor="figure_SDP_example" title="SDPanchor="figure_SDP_example"> <name>SDP Media Description for a CLUEdata channel"> <artwork><![CDATA[Data Channel</name> <sourcecode name="sdp-1" type="sdp"><![CDATA[ m=application 54111 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2subprotocol="CLUE";ordered=true ]]></artwork>subprotocol="CLUE";ordered=true]]></sourcecode> </figure> </section> </section> </section> <section anchor="section.sec"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> This specification relies on the security properties of the WebRTC data channel described in <xreftarget="I-D.ietf-rtcweb-data-channel" pageno="false" format="default" />,target="RFC8831" format="default"/>, including reliance on DTLS. Since CLUE sessions are established using SIP/SDP, protecting the data channel against message modification and recovery requires the use of SIP authentication and authorization mechanisms described in <xref target="RFC3261"pageno="false" format="default" />format="default"/> for session establishment prior to establishing the data channel. </t> </section> <section anchor="section.iana"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <section anchor="section.iana.dc"title="New WebRTC data channel Protocol Value"> <t> [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.] </t>numbered="true" toc="default"> <name>Subprotocol Identifier "clue"</name> <t> This document adds the'CLUE' valuesubprotocol identifier "clue" to the "WebSocket Subprotocol Name Registry" as follows: </t><figure> <artwork align="left"><![CDATA[ Subprotocl Identifier: CLUE Subprotocol<table anchor="clue-reg"> <name>Registration of 'clue' Value</name> <tbody> <tr> <td>Subprotocol Identifier</td> <td>clue</td> </tr> <tr> <td>Subprotocol CommonName: CLUE Subprotocol Definition: RFC-XXXX Reference: RFC-XXXX ]]></artwork> </figure>Name</td> <td>CLUE</td> </tr> <tr> <td>Subprotocol Definition</td> <td>RFC 8850</td> </tr> <tr> <td>Reference</td> <td>RFC 8850</td> </tr> </tbody> </table> </section> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5061.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6525.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7496.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8261.xml"/> <!-- draft-ietf-mmusic-sctp-sdp (RFC 8841) --> <reference anchor="RFC8841" target="https://www.rfc-editor.org/info/rfc8841"> <front> <title>Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport</title> <author initials="C" surname="Holmberg" fullname="Christer Holmberg"> <organization/> </author> <author initials="R." surname="Shpount" fullname="Roman Shpount"> <organization/> </author> <author initials="S" surname="Loreto" fullname="Salvatore Loreto"> <organization/> </author> <author initials="G" surname="Camarillo" fullname="Gonzalo Camarillo"> <organization/> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8841"/> <seriesInfo name="DOI" value="10.17487/RFC8841"/> </reference> <!-- draft-ietf-rtcweb-data-channel (RFC 8831) --> <reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831"> <front> <title>WebRTC Data Channels</title> <author initials="R" surname="Jesup" fullname="Randell Jesup"> <organization/> </author> <author initials="S" surname="Loreto" fullname="Salvatore Loreto"> <organization/> </author> <author initials="M" surname="Tüxen" fullname="Michael Tüxen"> <organization/> </author> <date month='January' year='2021'/> </front> <seriesInfo name="RFC" value="8831"/> <seriesInfo name="DOI" value="10.17487/RFC8831"/> </reference> <!-- draft-ietf-mmusic-data-channel-sdpneg (RFC 8864) --> <reference anchor="RFC8864" target="https://www.rfc-editor.org/info/rfc8864"> <front> <title>Negotiation Data Channels Using the Session Description Protocol (SDP)</title> <author fullname="Keith Drage" initials="K." surname="Drage"> <organization>Unaffiliated</organization> </author> <author fullname="Raju Makaraju" initials="M." surname="Makaraju"> <organization>Nokia</organization> </author> <author fullname="Richard Ejzak" initials="R." surname="Ejzak"> <organization>Unaffiliated</organization> </author> <author fullname="Jerome Marcon" initials="J." surname="Marcon"> <organization>Unaffiliated</organization> </author> <author fullname="Roni Even" initials="R." surname="Even" role="editor"> <organization>Huawei</organization> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8864"/> <seriesInfo name="DOI" value="10.17487/RFC8864"/> </reference> </references> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3758.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/> <!-- draft-ietf-rtcweb-data-protocol (RFC 8832) --> <reference anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8832"> <front> <title>WebRTC Data Channel Establishment Protocol</title> <author initials='R.' surname='Jesup' fullname='Randell Jesup'> <organization/> </author> <author initials='S.' surname='Loreto' fullname='Salvatore Loreto'> <organization/> </author> <author initials='M' surname='Tüxen' fullname='Michael Tüxen'> <organization/> </author> <date month='January' year='2021'/> </front> <seriesInfo name="RFC" value="8832"/> <seriesInfo name="DOI" value="10.17487/RFC8832"/> </reference> <!-- draft-ietf-clue-protocol (RFC 8847) --> <reference anchor='RFC8847' target='https://www.rfc-editor.org/info/rfc8847'> <front> <title>Protocol for Controlling Multiple Streams for Telepresence (CLUE)</title> <author initials='R' surname='Presta' fullname='Roberta Presta'> <organization /> </author> <author initials='S P.' surname='Romano' fullname='Simon Pietro Romano'> <organization /> </author> <date month='January' year='2021' /> </front> <seriesInfo name="RFC" value="8847" /> <seriesInfo name='DOI' value='10.17487/RFC8847' /> </reference> <!-- draft-ietf-clue-signaling (RFC 8848) --> <reference anchor="RFC8848" target="https://www.rfc-editor.org/info/rfc8848"> <front> <title>Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)</title> <author fullname="Robert Hanton" initials="R." surname="Hanton"> <organization>Cisco</organization> </author> <author fullname="Paul Kyzivat" initials="P." surname="Kyzivat"> </author> <author fullname="Lennard Xiao" initials="L." surname="Xiao"> <organization>Huawei</organization> </author> <author fullname="Christian Groves" initials="C." surname="Groves"> <organization>Huawei</organization> </author> <date month="January" year="2021"/> </front> <seriesInfo name="RFC" value="8848"/> <seriesInfo name="DOI" value="10.17487/RFC8848"/> </reference> </references> </references> <sectiontitle="Acknowledgments">numbered="false" toc="default"> <name>Acknowledgements</name> <t> Thanks toPaul Kyzivat, Christian Groves<contact fullname="Paul Kyzivat"/>, <contact fullname="Christian Groves"/>, andMark Duckworth<contact fullname="Mark Duckworth"/> for comments onthethis document. </t> </section><section title="Change Log"> <t> [RFC EDITOR NOTE: Please remove this section when publishing] </t> <t> Changes from draft-ietf-clue-datachannel-17 <list style="symbols"> <t> Editorial changes to Tables based on TSV-ART review. </t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-16 <list style="symbols"> <t> Category changed to Experimental. </t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-15 <list style="symbols"> <t> Updates based on IESG review by Roman Danyliw. </t> <t> Make CLUE references Informative, as they are going to be published as Experimental RFCs. </t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-14 <list style="symbols"> <t> ICE reference update. </t> <t> Reference draft versions updates. </t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-13 <list style="symbols"> <t> Editorial changes based on Gen-ART review from Brian Carpenter. </t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-12 <list style="symbols"> <t> Changes based on AD comments from Alissa Cooper (https://www.ietf.org/mail-archive/web/clue/current/msg04911.html): </t> <t> - DCEP reference removed from security considerations. </t> <t> - Editorial fixes. </t> <t> - NOTE: Comment regarding the Security Considerations is still pending. </t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-11 <list style="symbols"> <t> Changes based on WGLC comments from Juergen Stoetzer-Bradler and Christian groves: </t> <t> - Reference updates. </t> <t> - 'Reference' added to IANA registration data. </t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-10 <list style="symbols"> <t> Security Considerations modified and enhanced, based on comments provided by Alissa Cooper. </t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-09 <list style="symbols"> <t>Reference updates:</t> <t> - draft-ietf-tsvwg-sctp-prpolicies published as RFC 7496</t> <t> - Reference update of draft versions</t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-08 <list style="symbols"> <t>Changes based on WGLC comments from Daniel Burnett:</t> <t>- Editorial corrections.</t> <t>Changes based on WGLC comments from Paul Kyzivat:</t> <t>- Editorial corrections.</t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-07 <list style="symbols"> <t>Changes based on WGLC comments from Christian Groves:</t> <t>- IANA considerations for dcmap attribute removed.</t> <t>- Explicit clarification that the dcmap attribute max-time and max-retr parameters are not used with ordered/reliable transmission of SCTP messages.</t> <t>- Indication that TCP transport should only be used if ICE is used, and if usage of TCP is required by ICE.</t> <t>- Informative reference to ICE added.</t> <t>- Editorial corrections.</t> <t>Changes based on WGLC comments from Mark Duckworth:</t> <t>- Make it more clear that the rules regarding usage of partial reliability and ordered reliability apply to CLUE data channels.</t> <t>Changes based on WGLC comments from Paul Kyzivat:</t> <t>- Clarify that same SCTP options are applied to each SCTP message associated with a given data channel.</t> <t>- Switched location of sections 3.2 and 3.3.</t> <t>- PPID table removed. Not needed, since only one value is used.</t> <t>- Editorial corrections.</t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-06 <list style="symbols"> <t>Usage of DCEP removed.</t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-05 <list style="symbols"> <t>"DTLS/SCTP" split into "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP".</t> <t>Removed note regarding optionality of including the SDP sctp-port attribute.</t> <t>Added defintion of 'SCTPoDTLS association' to the Conventions.</t> <t>Reference to RFC 4566 (SDP) added.</t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-04 <list style="symbols"> <t>Defines DCEP and external SDP negotiation as two separate mechanisms for negotiating a CLUE data channel.</t> <t>Updates based on technical changes in referenced specifications.</t> <t>Reference to draft-ietf-mmusic-sctp-sdp added.</t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-03 <list style="symbols"> <t>IANA considerations added.</t> <t>Editorial changes based on comments from Christian Groves.</t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-02 <list style="symbols"> <t>SDP "m=" line example fixed.</t> <t>OPEN ISSUE #1 closed.</t> <t>- It was agreed (IETF#91) to use draft-ejzak-mmusic-data-channel-sdpneg, as it was adopted as a WG item in MMUSIC. </t> <t>- Details for draft-ejzak-mmusic-data-channel-sdpneg usage added.</t> <t>SDP Offer/Answer procedures removed, as they will be defined in the CLUE protocol draft.</t> <t>References updated.</t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-01 <list style="symbols"> <t>Support of interleaving "MUST"->"SHOULD".</t> <t>Example updated.</t> <t>Reference update.</t> </list> </t> <t> Changes from draft-ietf-clue-datachannel-00 <list style="symbols"> <t>SDP Offer/Answer procedures structures according to RFC 3264.</t> <t>Reference update.</t> </list> </t> <t> Changes from draft-holmberg-clue-datachannel-04 <list style="symbols"> <t>Draft submitted as draft-ietf-clue-data-channel-00.</t> <t>Editorial nits fixed.</t> <t>Changes based on comments from Paul Kyzivat (http://www.ietf.org/mail-archive/web/clue/current/msg03559.html).</t> <t>- Proto value fixed.</t> <t>- Explicit text that the partial reliability and limited retransmission policies MUST NOT be used.</t> <t>- Added open issue on whether the DCEP 'protocol' field value for CLUE should contain a version number.</t> <t>- Removed paragraph saying that an offerer must not insert more than one "m=" line describing an SCTPoDTLS association to be used to realize a CLUE data channel, as the draft already states that only one CLUE data channel per CLUE session shall be opened.</t> <t>- Added reference to draft-ietf-rtcweb-data-protocol regarding details on reseting SCTP streams.</t> <t>- Added text saying that the value of the DCEP 'channel type' MUST be DATA_CHANNEL_RELIABLE.</t> <t>- Clarified that DCEP must be supported, and used in the absence of another mechanism for opening a CLUE data channel.</t> </list> </t> <t> Changes from draft-holmberg-clue-datachannel-03 <list style="symbols"> <t>Procedures updated, based on WG agreement (IETF#89) to use DCEP for the CLUE data channel.</t> <t>Procedures updated, based on WG agreement (IETF#89) that offerer is responsible for sending DCEP DATA_CHANNEL_OPEN.</t> <t>Editorial changes, and alignments caused by changes in referenced specifications.</t> </list> </t> <t> Changes from draft-holmberg-clue-datachannel-02 <list style="symbols"> <t>PPID value for CLUE messages added</t> <t>References updated</t> </list> </t> <t> Changes from draft-holmberg-clue-datachannel-01 <list style="symbols"> <t>More text added</t> </list> </t> <t> Changes from draft-holmberg-clue-datachannel-00 <list style="symbols"> <t>Editorial corrections based on comments from Paul K</t> </list> </t> </section> </middle> <back> <references title="Normative References"> <?rfc include="reference.RFC.2119"?> <?rfc include="reference.RFC.3261"?> <?rfc include="reference.RFC.3264"?> <?rfc include="reference.RFC.4566"?> <?rfc include="reference.RFC.4960"?> <?rfc include="reference.RFC.5061"?> <?rfc include="reference.RFC.6525"?> <?rfc include="reference.RFC.7496"?> <?rfc include="reference.RFC.8174"?> <?rfc include="reference.RFC.8261"?> <reference anchor="I-D.ietf-mmusic-sctp-sdp"> <front> <title abbrev="The SCTP protocol identifier for SDP"> Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP) </title> <author initials="C." surname="Holmberg" fullname="Christer Holmberg"> <organization>Ericsson</organization> </author> <author initials="S." surname="Loreto" fullname="Salvatore Loreto"> <organization>Ericsson</organization> </author> <author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo"> <organization>Ericsson</organization> </author> <date day="20" month="April" year="2017" /> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-sctp-sdp-26.txt" /> </reference> <reference anchor="I-D.ietf-rtcweb-data-channel"> <front> <title abbrev="WebRTC data channels"> WebRTC data channels </title> <author fullname="Randell Jesup" initials="R.J" surname="Jesup"> <organization>WorldGate Communications</organization> </author> <author fullname="Salvatore Loreto" initials="S.L" surname="Loreto"> <organization>Ericsson</organization> </author> <author fullname="Michael Tuexen" initials="M.T" surname="Tuexen"> <organization>Muenster University of Applied Sciences</organization> </author> <date day="4" month="January" year="2015" /> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-data-channel-13.txt" /> </reference> <reference anchor="I-D.ietf-mmusic-data-channel-sdpneg"> <front> <title abbrev="SDP-based 'SCTP over DTLS' data channel negotiation"> SDP-based "SCTP over DTLS" data channel negotiation </title> <author fullname="Keith Drage" initials="K.D" surname="Drage"> <organization>Alcatel-Lucent</organization> </author> <author fullname="Raju Makaraju" initials="R.M" surname="Makaraju"> <organization>Alcatel-Lucent</organization> </author> <author fullname="Juergen Stoetzer-Bradler" initials="J.S" surname="Stoetzer-Bradler"> <organization>Alcatel-Lucent</organization> </author> <author fullname="Richard Ejzak" initials="R.E" surname="Ejzak"> <organization>Unaffiliated</organization> </author> <author fullname="Jerome Marcon" initials="J.M" surname="Marcon"> <organization>Unaffiliated</organization> </author> <date day="23" month="April" year="2019" /> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-data-channel-sdpneg-26.txt" /> </reference> </references> <references title="Informative References"> <?rfc include="reference.RFC.3758"?> <?rfc include="reference.RFC.8445"?> <reference anchor="I-D.ietf-rtcweb-data-protocol"> <front> <title abbrev="WebRTC data channel Establishment Protocol"> WebRTC data channel Establishment Protocol </title> <author fullname="Randell Jesup" initials="R.J" surname="Jesup"> <organization>WorldGate Communications</organization> </author> <author fullname="Salvatore Loreto" initials="S.L" surname="Loreto"> <organization>Ericsson</organization> </author> <author fullname="Michael Tuexen" initials="M.T" surname="Tuexen"> <organization>Muenster University of Applied Sciences</organization> </author> <date day="4" month="January" year="2015" /> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-data-protocol-09.txt" /> </reference> <reference anchor="I-D.ietf-clue-protocol"> <front> <title abbrev="CLUE protocol"> CLUE protocol </title> <author fullname="Roberta Presta" initials="R.P" surname="Presta"> <organization>University of Napoli</organization> </author> <author fullname="Simon Pietro Romano" initials="S P.R" surname="Romano"> <organization>University of Napoli</organization> </author> <date day="21" month="September" year="2018" /> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-clue-protocol-17.txt" /> </reference> <reference anchor="I-D.ietf-clue-signaling"> <front> <title abbrev="CLUE signaling"> CLUE Signaling </title> <author fullname="Paul Kyzivat" initials="P.K" surname="Kyzivat"> </author> <author fullname="Lennard Xiao" initials="L.X" surname="Xiao"> <organization>Huawei</organization> </author> <author fullname="Christian Groves" initials="C.G" surname="Groves"> <organization>Huawei</organization> </author> <author fullname="Robert Hansen" initials="S P.R" surname="Romano"> <organization>Cisco</organization> </author> <date day="22" month="October" year="2018" /> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-clue-signaling-14.txt" /> </reference> </references></back> </rfc>