<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "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" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.38.1 -->
  <front>
    <title abbrev="CLUE Data Channel">Controlling Multiple Streams for
    Telepresence (CLUE) Protocol Data&nbsp;Channel</title>

    <seriesInfo name="RFC" value="8850"/>
    <author 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>
    <date 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 a Controlling Multiple Streams for Telepresence (CLUE) data channel, for transporting CLUE protocol
        messages between two CLUE entities.
      </t>
    </abstract>
  </front>
  <middle>
    <section toc="default" numbered="true">
      <name>Introduction</name>
      <t>
        This document defines how to use the WebRTC data channel
        mechanism <xref target="RFC8831" format="default"/> to realize a
        data channel, referred to as a Controlling Multiple Streams for
	Telepresence (CLUE) data channel, for
        transporting CLUE protocol messages <xref target="RFC8847" format="default"/> between two CLUE entities.
      </t>
      <t>
        This document also defines how to describe the SCTPoDTLS association
        <xref target="RFC8261" 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" format="default"/> and defines usage of the
        SDP-based "SCTP over DTLS" data channel negotiation mechanism
        <xref target="RFC8864" format="default"/>. ("SCTP" stands for "Stream
	Control Transmission Protocol".) This includes SCTP
        considerations specific to a CLUE data channel, the SDP media
        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" format="default"/>
        for negotiating usage of a CLUE data channel, are outside
        the scope of this document.
      </t>
      
        <aside><t>NOTE: The usage of the Data Channel Establishment Protocol (DCEP)
        <xref target="RFC8832" format="default"/>
        for establishing a CLUE data channel is outside the scope of this document.</t></aside>
    </section>
    <section toc="default" numbered="true">
      <name>Conventions</name>
    <t>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>

    <dl newline="true" spacing="normal">
    <dt>SCTPoDTLS association</dt>
    <dd>Refers to an SCTP association carried over a DTLS connection <xref
    target="RFC8261" format="default"/>.</dd>

    <dt>WebRTC data channel</dt>
    <dd>Refers to a pair of SCTP streams over an
SCTPoDTLS association that is used to transport non-media
data between two entities, as defined in <xref
target="RFC8831" format="default"/>.</dd>

    <dt>CLUE data channel</dt>
    <dd>Refers to a WebRTC data channel realization <xref target="RFC8831" format="default"/>, with a specific set of
SCTP characteristics, with the purpose of transporting CLUE
protocol messages <xref target="RFC8847" format="default"/> between two CLUE entities.</dd>

    <dt>CLUE entity</dt>
    <dd>Refers to a SIP User Agent (UA) <xref target="RFC3261" format="default"/> that supports the CLUE data channel
and the CLUE protocol.</dd>

    <dt>CLUE session</dt>
    <dd>Refers to a SIP session <xref target="RFC3261" format="default"/> between two SIP UAs, where a
CLUE data channel, associated with the SIP session, has been
established between the SIP UAs.</dd>

    <dt>SCTP stream</dt>
    <dd>Defined in <xref target="RFC4960" 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 delivery service.</dd>

    <dt>SCTP stream identifier</dt>
    <dd>Defined in <xref target="RFC4960" format="default"/> as an unsigned
    integer.  Identifies an SCTP stream.</dd>
    </dl>
    </section>
    <section anchor="section.dtls" toc="default" numbered="true">
      <name>CLUE Data Channel</name>
      <section anchor="section.cdc.gen" 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 <xref 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 entity <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" toc="default" numbered="true">
        <name>SCTP Considerations</name>
        <section anchor="section.cdc.sctp.gen" toc="default" numbered="true">
          <name>General</name>
          <t>
                As described in <xref target="RFC8831" format="default"/>, different SCTP options
                (e.g., regarding ordered delivery) can be used for a
                data channel. This section describes the SCTP options
                used for a CLUE data channel. <xref target="section.oa" format="default"/> describes how SCTP options are signaled using SDP.
          </t>
        </section>
        <section anchor="section.cdc.sctp.ppid" toc="default" numbered="true">
          <name>SCTP Payload Protocol Identifier (PPID)</name>
          <t>
                A CLUE entity <bcp14>MUST</bcp14> use the PPID value 51 when sending a CLUE message
                on a CLUE data channel.
          </t>
          <aside><t>
                   NOTE: As described in <xref target="RFC8831" format="default"/>, the PPID value 51 indicates that
                the SCTP message contains data encoded in UTF-8 format. The PPID
                value 51 does not indicate which application protocol the SCTP message
                is associated with -- only the format in which the data is encoded.
          </t></aside>
        </section>
        <section anchor="section.cdc.sctp.reliability" toc="default" numbered="true">
          <name>Reliability</name>
          <t>
                The usage of SCTP for the CLUE data channel ensures reliable transport of 
                CLUE protocol messages <xref target="RFC8847" format="default"/>.</t>
          <t>
                <xref target="RFC8831" format="default"/>
           	requires the support of the partial reliability extension defined in <xref target="RFC3758" format="default"/> and the limited retransmission policy defined in
           	<xref target="RFC7496" format="default"/>. A CLUE entity <bcp14>MUST NOT</bcp14> use 
                these extensions, as messages are required to always be sent reliably. A CLUE entity <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" toc="default" numbered="true">
          <name>Order</name>
          <t>
                A CLUE entity <bcp14>MUST</bcp14> use the ordered delivery SCTP service, as
                described in <xref target="RFC4960" format="default"/>,
                for the CLUE data channel.
          </t>
        </section>
        <section anchor="section.cdc.sctp.streamreset" toc="default" numbered="true">
          <name>Stream Reset</name>
          <t>
                A CLUE entity <bcp14>MUST</bcp14> support the stream reset extension defined in <xref target="RFC6525" format="default"/>.
          </t>
          <t>
                Per <xref target="RFC8831" format="default"/>,
                the dynamic address reconfiguration extension parameter ('Supported Extensions Parameter')
                defined in <xref target="RFC5061" format="default"/> must be used to signal the
            support of the stream reset extension defined in <xref
	    target="RFC6525" format="default"/>.
 Other features defined in <xref target="RFC5061" format="default"/>
            <bcp14>MUST NOT</bcp14> be used for CLUE data channels.
          </t>
        </section>
        <section anchor="section.cdc.sctp.multihome" toc="default" numbered="true">
          <name>SCTP Multihoming</name>
          <t>
                SCTP multihoming is not supported for SCTPoDTLS associations
		and therefore cannot be used for a CLUE data channel.
          </t>
        </section>
        <section anchor="section.cdcp.proc.close" toc="default" numbered="true">
          <name>Closing the CLUE Data Channel</name>
          <t>
                As described in <xref target="RFC8831" format="default"/>, to close a data channel, an entity sends an SCTP reset
                message <xref target="RFC6525" 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" toc="default" numbered="true">
        <name>SDP Considerations</name>
        <section anchor="section.oa.gen" toc="default" numbered="true">
          <name>General</name>
          <t>This section defines how to (1) construct the SDP media description
          ("m=" line) for describing the SCTPoDTLS association used to realize
          a CLUE data channel and (2)&nbsp;use the
          SDP-based "SCTP over DTLS" data  channel negotiation mechanism
          <xref target="RFC8864" format="default"/> for establishing
          a CLUE data channel on the SCTPoDTLS association.</t>
          <aside><t>
                NOTE: Protocols other than SDP for negotiating usage of an SCTPoDTLS
                association for realizing a CLUE data channel are outside the scope
                of this specification.
          </t></aside>
          <t>
                <xref target="RFC8848" format="default"/>
                describes the SDP Offer/Answer procedures for negotiating a CLUE session,
                including the CLUE-controlled media streams and the CLUE data channel.
          </t>
          <section anchor="section.oa.mediadesc" toc="default" numbered="true">
            <name>SDP Media Description Fields</name>
            <t>
                    <xref target="RFC8841" format="default"/> defines how
                to set the values of an "m=" line describing an SCTPoDTLS association. As defined in
                <xref target="RFC8841" format="default"/>, for a 
                CLUE data channel the values are set as follows:
            </t>
            <table anchor="table_SDP_mediadesc" align="center">
              <name>SDP "proto" Field 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 port value</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 port value</td>
                  <td align="center">"TCP/DTLS/SCTP"</td>
                  <td align="center">"webrtc-datachannel"</td>
                </tr>
              </tbody>
            </table>
            <t>
                CLUE entities <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" target="RFC8445"/>
                is used and the ICE procedures determine that TCP transport is required).
            </t>
          </section>
          <section anchor="section.oa.sctpport" toc="default" numbered="true">
            <name>SDP sctp-port Attribute</name>
            <t>
                As defined in <xref 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 <xref target="RFC8841" format="default"/>.
            </t>
          </section>
        </section>
        <section anchor="section.oa.dcmap" toc="default" numbered="true">
          <name>SDP dcmap Attribute</name>
          <t>
                The values of the SDP dcmap attribute <xref target="RFC8864" format="default"/>, associated with the "m=" line describing the SCTPoDTLS
                association used to realize the WebRTC data channel, are set as follows:
          </t>
          <table anchor="table_SDP_dcmap" align="center">
            <name>SDP dcmap Attribute 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 data 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
                <xref target="RFC8864" format="default"/> the max-retr and max-time attribute parameters
                are not used when negotiating CLUE data channels.
          </t></aside>
        </section>
        <section anchor="section.oa.dcsa" toc="default" numbered="true">
          <name>SDP dcsa Attribute</name>
          <t>
                The SDP dcsa attribute <xref target="RFC8864" format="default"/> is not used when establishing a CLUE data channel.
          </t>
        </section>
        <section anchor="section.oa.example" toc="default" numbered="true">
          <name>Example</name>
          <t>
                The example in <xref target="figure_SDP_example" format="default"/> shows 
                an SDP media description for a CLUE data channel. Complete SDP examples can be found 
                in <xref target="RFC8848" format="default"/>.
          </t>
          <figure anchor="figure_SDP_example">
            <name>SDP Media Description for a CLUE Data Channel</name>
        <sourcecode name="sdp-1" type="sdp"><![CDATA[
         m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
         a=sctp-port: 5000
         a=dcmap:2 subprotocol="CLUE";ordered=true]]></sourcecode> </figure>
        </section>
      </section>
    </section>
    <section anchor="section.sec" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
                This specification relies on the security properties of the WebRTC data channel described in
                <xref 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" format="default"/>
                for session establishment prior to establishing the data channel.
      </t>
    </section>
    <section anchor="section.iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="section.iana.dc" numbered="true" toc="default">
        <name>Subprotocol Identifier &quot;clue&quot;</name>
        <t>
        This document adds the subprotocol identifier "clue" to the "WebSocket Subprotocol Name Registry"
        as follows:
        </t>

<table anchor="clue-reg">
  <name>Registration of 'clue' Value</name>
  <tbody>
    <tr>
      <td>Subprotocol Identifier</td>
      <td>clue</td>
    </tr>
    <tr>
      <td>Subprotocol Common 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>
    <section numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
        Thanks to <contact fullname="Paul Kyzivat"/>,
        <contact fullname="Christian Groves"/>, and
        <contact fullname="Mark Duckworth"/> for comments
        on this document.
      </t>
    </section>
  </back>
</rfc>
