<?xml version="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="false" version="3">
  <!-- xml2rfc v2v3 conversion 2.38.1 -->
  <front>
    <title abbrev="CLUE data channel"> Data Channel">Controlling Multiple Streams for
    Telepresence (CLUE) Protocol&nbsp;Data&nbsp;Channel</title>

<!-- [rfced] Please note that the title of this document has been
updated as follows:

Original:
 CLUE Protocol data channel
		</title>

Currently:
 Controlling Multiple Streams for Telepresence (CLUE)
                Protocol Data Channel

Please let us know if any corrections are needed. -->

    <seriesInfo name="RFC" value="8850"/>
    <author initials="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>
    <date year="2019" />
		<area>Transport</area>
		<workgroup>CLUE Working Group</workgroup> month="June" year="2020"/>

    <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 CLUE Controlling Multiple Streams for Telepresence (CLUE) data channel, for transporting CLUE protocol
        messages between two CLUE entities.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default"> toc="default" numbered="true">
      <name>Introduction</name>
      <t>
        This document defines how to use the WebRTC data channel
        mechanism <xref target="I-D.ietf-rtcweb-data-channel"
				pageno="false" format="default" /> target="RFC8831" format="default"/> to realize a
        data channel, referred to as a CLUE Controlling 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>

<!-- [rfced] It is likely that draft-ietf-mmusic-rfc4566bis will move
to AUTH48 state shortly after this document. Do you want to hold this
document to reference 4566bis instead of RFC 4566?
-->
      <t>
				The
        This 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
        <xref target="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 SDP Media
				Description 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" pageno="false" format="default" />
				procedures format="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)
        <xref target="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 this document.
			</t> document.</t></aside>
    </section>
    <section title="Conventions" toc="default">
      		<t>
        		The toc="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 in BCP 14 BCP&nbsp;14 <xref target="RFC2119"></xref> target="RFC2119"/>
    <xref target="RFC8174"></xref> target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
      		</t>
			<t>
				SCTPoDTLS association refers here.</t>

    <dl newline="true" spacing="normal">
    <dt>SCTPoDTLS association</dt>
    <dd>Refers to an SCTP association carried over an a DTLS connection <xref
    target="RFC8261" pageno="false" format="default" />.
			</t>
			<t>
				WebRTC format="default"/>.</dd>
    </dl>
    <dl newline="true" spacing="normal">
    <dt>WebRTC data channel refers channel</dt>
    <dd>Refers to a pair of SCTP streams over a an
SCTPoDTLS association that is used to transport non-media
data between two entities, as defined in <xref target="I-D.ietf-rtcweb-data-channel"
				pageno="false" format="default" />.
			</t>
			<t>
				CLUE
target="RFC8831" format="default"/>.</dd>
    </dl>
    <dl newline="true" spacing="normal">
    <dt>CLUE data channel refers channel</dt>
    <dd>Refers to a WebRTC data channel realization <xref
				target="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 CLUE entities.
			</t>
			<t>
				CLUE entity refers entities.</dd>
    </dl>
    <dl newline="true" spacing="normal">
    <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 CLUE protocol.
			</t>
			<t>
				CLUE session refers protocol.</dd>
    </dl>
    <dl newline="true" spacing="normal">
    <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 SIP UAs.
			</t>
			<t>
				SCTP stream is defined UAs.</dd>
    </dl>
    <dl newline="true" spacing="normal">
    <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 delivery service.
			</t>
			<t>

<!-- [rfced] Section 2:  Does "from one to another associated SCTP identifier
endpoint" mean "from one associated SCTP endpoint to another,"
"from one SCTP endpoint to another associated SCTP endpoint," or
something else?

Original:
 SCTP stream is defined in [RFC4960] 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>
    </dl>
    <dl newline="true" spacing="normal">
    <dt>SCTP stream identifier</dt>
    <dd>Defined in <xref target="RFC4960" pageno="false"
				format="default" /> format="default"/> as an unsigned integer, which identifies
    integer.  Identifies an SCTP stream.
			</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 <xref target="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 entity MUST <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 <xref target="I-D.ietf-rtcweb-data-channel"
						pageno="false" format="default" />, target="RFC8831" format="default"/>, different SCTP options
                (e.g., regarding ordered delivery ), 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>
          <aside><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" /> target="RFC8831" format="default"/>
                mandates that, for a given data channel, the same SCTP options be applied
                to each SCTP message associated with that data channel.

<!-- [rfced] Section 3.2.1:  We could not find this requirement in
[I-D.ietf-rtcweb-data-channel], which is now [RFC8831].
Please verify that the text is correct.

Original:
 NOTE: While SCTP allows SCTP options to be applied per SCTP message,
 [I-D.ietf-rtcweb-data-channel] mandates that, for a given data
 channel, the same SCTP options are applied to each SCTP message
 associated with that data channel.
					</t> -->

          </t></aside>
        </section>
        <section anchor="section.cdc.sctp.ppid" title="SCTP toc="default" numbered="true">
          <name>SCTP Payload Protocol Identifier (PPID)" toc="default"> (PPID)</name>
          <t>
                A CLUE entity MUST <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 <xref target="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 in a UTF-8 format. The PPID
                value 51 does not indicate which application protocol the SCTP message
                is associated with, 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 <xref target="I-D.ietf-clue-protocol" pageno="false" format="default" />
						messages.
					</t> target="RFC8847" format="default"/>.</t>
          <t>
                <xref target="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 entity MUST NOT <bcp14>MUST NOT</bcp14> use
                these extensions, as messages are required to always be sent reliably. A CLUE entity MUST <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 entity MUST <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 entity MUST <bcp14>MUST</bcp14> support the stream reset extension defined in <xref target="RFC6525"
						pageno="false" format="default" />. format="default"/>.
          </t>
          <t>
						As defined in
                Per <xref target="I-D.ietf-rtcweb-data-channel" pageno="false" format="default" />, target="RFC8831" format="default"/>,
                the dynamic address reconfiguration extension parameter ('Supported Extensions Parameter' 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"/>.

<!-- [rfced] Section 3.2.5:  We see that
[I-D.ietf-rtcweb-data-channel] uses "MUST" regarding support for
the stream reset extension.  Should "must" be "MUST" here as well?
If yes, we will request AD approval of the update.

Original:
 As defined in [I-D.ietf-rtcweb-data-channel], the dynamic address
 reconfiguration extension ('Supported Extensions Parameter'
 parameter) defined in [RFC5061] must be used to signal the support of
 the stream reset extension defined in [RFC6525].

From [RFC8831]:
 o  The dynamic address reconfiguration extension defined in [RFC5061]
    MUST be used to signal the support of the stream reset extension
    defined in [RFC6525].

Possibly:
 Per [RFC8831], the dynamic address reconfiguration extension
 parameter ('Supported Extensions Parameter') defined in [RFC5061]
 MUST be used to signal the support of the stream reset extension
 defined in [RFC6525]. -->

 Other features of defined in <xref target="RFC5061" pageno="false" format="default" />
            MUST NOT format="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>
                SCTP multi-homing multihoming is not supported for SCTPoDTLS associations, associations
		and can therefore
						not cannot be used for a CLUE data channel.
          </t>
        </section>
        <section anchor="section.cdcp.proc.close" title="Closing toc="default" numbered="true">
          <name>Closing the CLUE data channel" toc="default"> Data Channel</name>
          <t>
                As described in <xref target="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>
						This toc="default" numbered="true">
          <name>General</name>
          <t>This section defines how to (1) construct the SDP Media Description media description
          ("m=" line) for describing the SCTPoDTLS association used to realize
          a CLUE data channel. The section also defines how to use channel and (2)&nbsp;use the
          SDP-based "SCTP over DTLS" data  channel negotiation mechanism
          <xref target="I-D.ietf-mmusic-data-channel-sdpneg" /> target="RFC8864" format="default"/> for establishing
          a CLUE data channel on the SCTPoDTLS association.
					</t>
					<t> association.</t>
          <aside><t>
                NOTE: Other protocols 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>
          </t></aside>
          <t>
                <xref target="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 the CLUE controlled CLUE-controlled media streams and the CLUE data channel.
          </t>
          <section anchor="section.oa.mediadesc" title="SDP toc="default" numbered="true">
            <name>SDP Media Description Fields" toc="default"> Fields</name>
            <t>
                    <xref target="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
                <xref target="I-D.ietf-mmusic-sctp-sdp" pageno="false" format="default" />, target="RFC8841" format="default"/>, for a
                CLUE data channel the values are set as following: follows:
            </t>
						<texttable
            <table anchor="table_SDP_mediadesc" title='SDP align="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>UDP 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</c>
							<c>"UDP/DTLS/SCTP"</c>
							<c>"webrtc-datachannel"</c>
							<c>"application"</c>
							<c>TCP 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</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 entities SHOULD 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="SDP toc="default" numbered="true">
            <name>SDP sctp-port Attribute" toc="default"> Attribute</name>
            <t>
                As defined in <xref target="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 <xref target="I-D.ietf-mmusic-sctp-sdp"
							pageno="false" target="RFC8841" format="default"/>.
            </t>
          </section>
        </section>
        <section anchor="section.oa.dcmap" title="SDP toc="default" numbered="true">
          <name>SDP dcmap Attribute" toc="default"> Attribute</name>
          <t>
                The values of the SDP dcmap attribute <xref target="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 as following: follows:
          </t>
					<texttable
          <table anchor="table_SDP_dcmap" title='SDP align="center">
            <name>SDP dcmap attribute 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>Value 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</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
                <xref target="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="SDP toc="default" numbered="true">
          <name>SDP dcsa Attribute" toc="default"> Attribute</name>
          <t>
                The SDP dcsa attribute <xref target="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 complete Complete SDP examples can be found
                in <xref target="I-D.ietf-clue-signaling" pageno="false" format="default" />. target="RFC8848" format="default"/>.
          </t>
          <figure anchor="figure_SDP_example" title="SDP anchor="figure_SDP_example">
            <name>SDP Media Description for a CLUE data 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:2 subprotocol="CLUE";ordered=true

                         ]]></artwork> subprotocol="CLUE";ordered=true]]></sourcecode> </figure>
        </section>
      </section>
    </section>

<!-- [rfced] We found the following note in the (now removed)
Change Log:

 o  - NOTE: Comment regarding the Security Considerations is still
      pending.

Was this item addressed? -->

    <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
                <xref target="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 numbered="true" toc="default">
        <name>New WebRTC data channel Data Channel Protocol Value">
				<t>
					[RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.]
				</t> Value</name>
        <t>
        This document adds the 'CLUE' value 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 Common Name:	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>
		<section title="Acknowledgments">
			<t>
				Thanks
  </middle>
  <back>

<!-- [rfced] References:  We see that "sortrefs" in the original
approved document was set to Paul Kyzivat, Christian Groves and Mark Duckworth for comments
				on "no"; however, with the 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 exception of
the draft listings, the references were originally displayed in
alphanumeric order.  Would you like the references 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 sorted 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"?>
this RFC? -->

    <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="I-D.ietf-mmusic-sctp-sdp"> anchor="RFC8841" target="https://www.rfc-editor.org/info/rfc8841">
          <front>
					<title abbrev="The SCTP protocol identifier
            <title>Session Description Protocol (SDP) Offer/Answer Procedures
            for SDP"> Stream Control Transmission Protocol (SCTP)-Based Media (SCTP) over Datagram
            Transport in the Session Description Protocol (SDP)
					</title> Layer Security (DTLS) Transport</title>
             <seriesInfo name="RFC" value="8841"/>
             <seriesInfo name="DOI" value="10.17487/RFC8841"/>
            <author initials="C." initials="C" surname="Holmberg" fullname="Christer Holmberg">
						<organization>Ericsson</organization>
              <organization/>
            </author>
            <author initials="R.S." surname="Shpount" fullname="Roman Shpount">
              <organization/>
            </author>
            <author initials="S." initials="S" surname="Loreto" fullname="Salvatore Loreto">
						<organization>Ericsson</organization>
              <organization/>
            </author>
            <author initials="G." initials="G" surname="Camarillo" fullname="Gonzalo Camarillo">
						<organization>Ericsson</organization>
              <organization/>
            </author>
            <date day="20" month="April" year="2017" /> month="June" year="2020"/>
          </front>
				<seriesInfo name="Internet-Draft" value="draft-ietf-mmusic-sctp-sdp-26.txt" />
        </reference>

<!-- draft-ietf-rtcweb-data-channel (RFC 8831) -->
       <reference anchor="I-D.ietf-rtcweb-data-channel"> anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831">
          <front>
					<title abbrev="WebRTC data channels">
						WebRTC data channels
					</title>
            <title>WebRTC Data Channels</title>
            <seriesInfo name="RFC" value="8831"/>
            <seriesInfo name="DOI" value="10.17487/RFC8831"/>
            <author initials="R" surname="Jesup" fullname="Randell Jesup" initials="R.J" surname="Jesup">
						<organization>WorldGate Communications</organization> Jesup">
              <organization/>
            </author>
            <author initials="S" surname="Loreto" fullname="Salvatore Loreto" initials="S.L" surname="Loreto">
						<organization>Ericsson</organization> Loreto">
              <organization/>
            </author>
            <author initials="M" surname="Tüxen" fullname="Michael Tuexen" initials="M.T" surname="Tuexen">
						<organization>Muenster University of Applied Sciences</organization> Tüxen">
              <organization/>
            </author>
            <date day="4" month="January" year="2015" /> month="June" year="2020"/>
          </front>
				<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-data-channel-13.txt" />
        </reference>

<!-- draft-ietf-mmusic-data-channel-sdpneg (RFC 8864) -->
      <reference anchor="I-D.ietf-mmusic-data-channel-sdpneg"> anchor="RFC8864" target="https://www.rfc-editor.org/info/rfc8864">
        <front>
					<title abbrev="SDP-based 'SCTP over DTLS' data channel negotiation">
						SDP-based "SCTP over DTLS" data channel negotiation
					</title>
          <title>Data Channel Negotiation Based on the Session Description
	  Protocol (SDP)</title>
          <seriesInfo name="RFC" value="8864"/>
          <seriesInfo name="DOI" value="10.17487/RFC8864"/>
          <author fullname="Keith Drage" initials="K.D" initials="K. E." surname="Drage">
						<organization>Alcatel-Lucent</organization>
            <organization>Unaffiliated</organization>
          </author>
          <author fullname="Raju Makaraju" initials="R.M" initials="M. R." surname="Makaraju">
						<organization>Alcatel-Lucent</organization>
					</author>
					<author fullname="Juergen Stoetzer-Bradler" initials="J.S" surname="Stoetzer-Bradler">
						<organization>Alcatel-Lucent</organization>
            <organization>Nokia</organization>
          </author>
          <author fullname="Richard Ejzak" initials="R.E" initials="R.P." surname="Ejzak">
            <organization>Unaffiliated</organization>
          </author>
          <author fullname="Jerome Marcon" initials="J.M" initials="J.M." surname="Marcon">
            <organization>Unaffiliated</organization>
          </author>
          <author fullname="Roni Even" initials="R. E." surname="Even" role="editor">
            <organization>Huawei</organization>
          </author>
          <date day="23" month="April" year="2019" /> month="June" year="2020"/>
        </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"?>
    <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="I-D.ietf-rtcweb-data-protocol"> anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8832">
          <front>
					<title abbrev="WebRTC data channel Establishment Protocol">
						WebRTC data channel
            <title>WebRTC Data Channel Establishment Protocol
					</title> Protocol</title>
            <seriesInfo name="RFC" value="8832"/>
            <seriesInfo name="DOI" value="10.17487/RFC8832"/>
            <author initials="R" surname="Jesup" fullname="Randell Jesup" initials="R.J" surname="Jesup">
						<organization>WorldGate Communications</organization> Jesup">
              <organization/>
            </author>
            <author initials="S" surname="Loreto" fullname="Salvatore Loreto" initials="S.L" surname="Loreto">
						<organization>Ericsson</organization> Loreto">
              <organization/>
            </author>
            <author initials="M" surname="Tüxen" fullname="Michael Tuexen" initials="M.T" surname="Tuexen">
						<organization>Muenster University of Applied Sciences</organization> Tüxen">
              <organization/>
            </author>
            <date day="4" month="January" year="2015" /> month="June" year="2020"/>
          </front>
				<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-data-protocol-09.txt" />
        </reference>

<!-- draft-ietf-clue-protocol (RFC 8847) -->
        <reference anchor="I-D.ietf-clue-protocol"> anchor="RFC8847" target="https://www.rfc-editor.org/info/rfc8847">
          <front>
					<title abbrev="CLUE protocol">
						CLUE protocol
					</title>
            <title>Protocol for Controlling Multiple Streams for Telepresence (CLUE)</title>
            <seriesInfo name="RFC" value="8847"/>
            <seriesInfo name="DOI" value="10.17487/RFC8847"/>
            <author fullname="Roberta Presta" initials="R.P" initials="R." surname="Presta">
              <organization>University of Napoli</organization>
            </author>
            <author fullname="Simon Pietro Romano" initials="S P.R" P." surname="Romano">
              <organization>University of Napoli</organization>
            </author>
            <date day="21" month="September" year="2018" /> month="June" year="2020"/>
          </front>
				<seriesInfo name="Internet-Draft" value="draft-ietf-clue-protocol-17.txt" />
        </reference>

<!-- draft-ietf-clue-signaling (RFC 8848) -->
<!-- Sent email 1/27/2020 re. "Hanton"; s/b Hansen? -->
        <reference anchor="I-D.ietf-clue-signaling"> anchor="RFC8848" target="https://www.rfc-editor.org/info/rfc8848">
          <front>
					<title abbrev="CLUE signaling">
						CLUE
            <title>Session Signaling
					</title> for Controlling Multiple Streams for Telepresence (CLUE)</title>
            <seriesInfo name="RFC" value="8848"/>
            <seriesInfo name="DOI" value="10.17487/RFC8848"/>
            <author fullname="Robert Hanton" initials="R." surname="Hanton">
              <organization>Cisco</organization>
            </author>
            <author fullname="Paul Kyzivat" initials="P.K" initials="P." surname="Kyzivat">
  	    </author>
            <author fullname="Lennard Xiao" initials="L.X" initials="L." surname="Xiao">
              <organization>Huawei</organization>
            </author>
            <author fullname="Christian Groves" initials="C.G" initials="C." 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" /> month="June" year="2020"/>
          </front>
				<seriesInfo name="Internet-Draft" value="draft-ietf-clue-signaling-14.txt" />
        </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>