rfc8850xml2.original.xml   rfc8850.xml 
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC category="exp" docName="draft-ietf-clue-datachannel-18" number="8850"
.2119.xml"> obsoletes="" updates="" submissionType="IETF" consensus="true" xml:lang="en
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC " tocInclude="true" sortRefs="true" version="3">
.3261.xml"> <!-- xml2rfc v2v3 conversion 2.38.1 -->
<!ENTITY RFC3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <front>
.3264.xml"> <title abbrev="CLUE Data Channel">Controlling Multiple Streams for
Telepresence (CLUE) Protocol Data&nbsp;Channel</title>
]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc strict="yes" ?>
<rfc ipr="trust200902" category="exp" docName="draft-ietf-clue-datachannel-18" o
bsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="CLUE data channel">
CLUE Protocol data channel
</title>
<author initials="C.H." surname="Holmberg" fullname="Christer Hol
mberg">
<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" /> <seriesInfo name="RFC" value="8850"/>
<area>Transport</area> <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
<workgroup>CLUE Working Group</workgroup> <organization>Ericsson</organization>
<keyword>SIP</keyword> <address>
<keyword>SDP</keyword> <postal>
<keyword>DTLS</keyword> <street>Hirsalantie 11</street>
<keyword>SCTP</keyword> <code>02420</code>
<keyword>DATA</keyword> <city>Jorvas</city>
<keyword>CHANNEL</keyword> <country>Finland</country>
<keyword>DCEP</keyword> </postal>
<keyword>DATA_CHANNEL_OPEN</keyword> <email>christer.holmberg@ericsson.com</email>
<keyword>DATA_CHANNEL_ACK</keyword> </address>
<keyword>PPID</keyword> </author>
<keyword>TELEPRESENCE</keyword> <date month="January" year="2021"/>
<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 data channel, for transporting CLUE pro
tocol
messages between two CLUE entities.
</t>
</abstract>
</front>
<middle> <keyword>SIP</keyword>
<section title="Introduction" toc="default"> <keyword>SDP</keyword>
<t> <keyword>DTLS</keyword>
This document defines how to use the WebRTC data <keyword>SCTP</keyword>
channel <keyword>DATA</keyword>
mechanism <xref target="I-D.ietf-rtcweb-data-chan <keyword>CHANNEL</keyword>
nel" <keyword>DCEP</keyword>
pageno="false" format="default" /> to realize a <keyword>DATA_CHANNEL_OPEN</keyword>
data channel, referred to as a CLUE data channel, <keyword>DATA_CHANNEL_ACK</keyword>
for <keyword>PPID</keyword>
transporting CLUE protocol <xref target="I-D.ietf <keyword>TELEPRESENCE</keyword>
-clue-protocol" <keyword>RTCWEB</keyword>
pageno="false" format="default" /> messages betwe <keyword>WEBRTC</keyword>
en two CLUE entities. <abstract>
</t> <t>
<t> This document defines how to use the WebRTC data channel
The document defines how to describe the SCTPoDTL mechanism to realize a data channel, referred to
S association as a Controlling Multiple Streams for Telepresence (CLUE) data channel,
<xref target="RFC8261" pageno="false" format="def for transporting CLUE protocol
ault" /> used to 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="defau
lt"/> 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 Prot ocol (SDP) realize the CLUE data channel using the Session Description Prot ocol (SDP)
<xref target="RFC4566" pageno="false" format="default" />, and d <xref target="RFC4566" format="default"/> and defines usage of t
efines usage of the he
SDP-based "SCTP over DTLS" data channel negotiati SDP-based "SCTP over DTLS" data channel negotiation mechanism
on mechanism <xref target="RFC8864" format="default"/>. ("SCTP" stands for "Stream
<xref target="I-D.ietf-mmusic-data-channel-sdpneg Control Transmission Protocol".) This includes SCTP
" considerations specific to a CLUE data channel, the SDP media
pageno="false" format="default" />. This includes description ("m=" line) values, and usage of SDP attributes specific
SCTP to a CLUE data channel.
considerations specific to a CLUE data channel, t </t>
he SDP Media <t>
Description ("m=" line) values, and usage of SDP Details and procedures associated with the CLUE protocol, and the
attributes specific SDP Offer/Answer procedures <xref target="RFC3264" format="default"/>
to a CLUE data channel. for negotiating usage of a CLUE data channel, are outside
</t> the scope of this document.
<t> </t>
Details and procedures associated with the CLUE p
rotocol, and the
SDP Offer/Answer <xref target="RFC3264" pageno="f
alse" format="default" />
procedures for negotiating usage of a CLUE data c
hannel, are outside
the scope of this document.
</t>
<t>
NOTE: The usage of the Data Channel Establishment
Protocol (DCEP)
<xref target="I-D.ietf-rtcweb-data-protocol" page
no="false" format="default" />
for establishing a CLUE data channel is outside t
he scope of this document.
</t>
</section>
<section title="Conventions" toc="default">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "S
HALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMME
NDED",
"MAY", and "OPTIONAL" in this document are to be interpre
ted as
described in BCP 14 <xref target="RFC2119"></xref> <xref
target="RFC8174"></xref>
when, and only when, they appear in all capitals, as show
n here.
</t>
<t>
SCTPoDTLS association refers to an SCTP associati
on carried
over an DTLS connection <xref target="RFC8261" pa
geno="false" format="default" />.
</t>
<t>
WebRTC data channel refers to a pair of SCTP stre
ams over a
SCTPoDTLS association that is used to transport n
on-media
data between two entities, as defined in <xref ta
rget="I-D.ietf-rtcweb-data-channel"
pageno="false" format="default" />.
</t>
<t>
CLUE data channel refers to a WebRTC data channel
<xref
target="I-D.ietf-rtcweb-data-channel" pageno="fal
se"
format="default" /> realization, with a specific
set of
SCTP characteristics, with the purpose of transpo
rting CLUE
protocol <xref target="I-D.ietf-clue-protocol" pa
geno="false"
format="default" /> messages between two CLUE ent
ities.
</t>
<t>
CLUE entity refers to a SIP User Agent (UA) <xref
target="RFC3261"
pageno="false" format="default" /> that supports
the CLUE data channel
and the CLUE protocol.
</t>
<t>
CLUE session refers to a SIP session <xref target
="RFC3261"
pageno="false" format="default" /> between two SI
P UAs, where a
CLUE data channel, associated with the SIP sessio
n, has been
established between the SIP UAs.
</t>
<t>
SCTP stream is defined in <xref target="RFC4960"
pageno="false"
format="default" /> as a unidirectional logical c
hannel
established from one to another associated SCTP e
ndpoint,
within which all user messages are delivered in s
equence except
for those submitted to the unordered delivery ser
vice.
</t>
<t>
SCTP identifier is defined in <xref target="RFC49
60" pageno="false"
format="default" /> as an unsigned integer, which
identifies an SCTP stream.
</t>
</section>
<section anchor="section.dtls" title="CLUE data channel" toc="def <aside><t>NOTE: The usage of the Data Channel Establishment Protocol (DC
ault"> EP)
<section anchor="section.cdc.gen" title="General" toc="de <xref target="RFC8832" format="default"/>
fault"> for establishing a CLUE data channel is outside the scope of this docume
<t> nt.</t></aside>
This section describes the realization of </section>
a CLUE data channel, <section toc="default" numbered="true">
using the WebRTC data channel mechanism. <name>Conventions</name>
This includes a set of SCTP characteristi <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
cs specific to a "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
CLUE data channel, the values of the "m=" "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
line describing "<bcp14>SHOULD NOT</bcp14>",
the SCTPoDTLS association associated with "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
the WebRTC "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
data channel, and the usage of the SDP-ba to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
sed "SCTP <xref target="RFC8174"/> when, and only when, they appear in all capitals,
over DTLS" data channel negotiation mecha as shown here.</t>
nism for creating the
CLUE data channel.
</t>
<t>
As described in <xref target="I-D.ietf-rt
cweb-data-channel"
pageno="false" format="default" />, the S
CTP 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 entit
y MUST use a single CLUE
data channel for transport of all CLUE me
ssages towards its peer.
</t>
</section>
<section anchor="section.cdc.sctp" title="SCTP Considerat <dl newline="true" spacing="normal">
ions" toc="default"> <dt>SCTPoDTLS association</dt>
<section anchor="section.cdc.sctp.gen" title="Gen <dd>Refers to an SCTP association carried over a DTLS connection <xref
eral" toc="default"> target="RFC8261" format="default"/>.</dd>
<t>
As described in <xref target="I-D
.ietf-rtcweb-data-channel"
pageno="false" format="default" /
>, different SCTP options
(e.g., regarding ordered delivery
), can be used for a
data channel. This section descri
bes the SCTP options
used for a CLUE data channel. <xr
ef target="section.oa" pageno="false"
format="default" /> describes how
SCTP options are signaled using SDP.
</t>
<t>
NOTE: While SCTP allows SCTP opti
ons to be applied per SCTP message,
<xref target="I-D.ietf-rtcweb-dat
a-channel" pageno="false" format="default" />
mandates that, for a given data c
hannel, the same SCTP options are applied
to each SCTP message associated w
ith that data channel.
</t>
</section>
<section anchor="section.cdc.sctp.ppid" title="SC
TP Payload Protocol Identifier (PPID)" toc="default">
<t>
A CLUE entity MUST use the PPID v
alue 51 when sending a CLUE message
on a CLUE data channel.
</t>
<t>
NOTE: As described in <xref targe
t="I-D.ietf-rtcweb-data-channel"
pageno="false" format="default" /
>, the PPID value 51 indicates that
the SCTP message contains data en
coded in a UTF-8 format. The PPID
value 51 does not indicate which
application protocol the SCTP message
is associated with, only the form
at in which the data is encoded.
</t>
</section>
<section anchor="section.cdc.sctp.reliability" ti
tle="Reliability" toc="default">
<t>
The usage of SCTP for the CLUE da
ta channel ensures reliable transport of
CLUE protocol <xref target="I-D.i
etf-clue-protocol" pageno="false" format="default" />
messages.
</t>
<t>
<xref target="I-D.ietf-rtcweb-dat
a-channel" pageno="false" format="default" />
requires the support of the parti
al reliability extension defined in <xref target="RFC3758"
pageno="false" format="default" /
> and the limited retransmission policy defined in
<xref target="RFC7496" pageno="fa
lse" format="default" />. A CLUE entity MUST NOT use
these extensions, as messages are
required to always be sent reliably. A CLUE entity MUST
terminate the session if it detec
ts that the peer entity uses any of the extensions.
</t>
</section>
<section anchor="section.cdc.sctp.order" title="O
rder" toc="default">
<t>
A CLUE entity MUST use the ordere
d delivery SCTP service, as
described in <xref target="RFC496
0" pageno="false" format="default" />,
for the CLUE data channel.
</t>
</section>
<section anchor="section.cdc.sctp.streamreset" ti
tle="Stream Reset" toc="default">
<t>
A CLUE entity MUST support the st
ream reset extension defined in <xref target="RFC6525"
pageno="false" format="default" /
>.
</t>
<t>
As defined in <xref target="I-D.i
etf-rtcweb-data-channel" pageno="false" format="default" />,
the dynamic address reconfigurati
on extension ('Supported Extensions Parameter' parameter)
defined in <xref target="RFC5061"
pageno="false" format="default" /> must be used to signal the
support of the stream reset extension defined in <xref target="RFC65
25" pageno="false"
format="default" />. Other featur
es of <xref target="RFC5061" pageno="false" format="default" />
MUST NOT be used for CLUE data channels.
</t>
</section>
<section anchor="section.cdc.sctp.multihome" titl
e="SCTP Multihoming" toc="default">
<t>
SCTP multi-homing is not supporte
d for SCTPoDTLS associations, and can therefore
not be used for a CLUE data chann
el.
</t>
</section>
<section anchor="section.cdcp.proc.close" title="
Closing the CLUE data channel" toc="default">
<t>
As described in <xref target="I-D
.ietf-rtcweb-data-channel" pageno="false"
format="default" />, to close a d
ata channel, an entity sends an SCTP reset
message <xref target="RFC6525" pa
geno="false" format="default" /> on its outgoing
SCTP stream associated with the d
ata channel. When the remote peer receives the reset
message, it also sends (unless al
ready sent) a reset message on its outgoing SCTP
stream associated with the data c
hannel. The SCTPoDTLS association, and other data channels
established on the same associati
on, are not affected by the SCTP reset messages.
</t>
</section>
</section>
<section anchor="section.oa" title="SDP Considerations" t <dt>WebRTC data channel</dt>
oc="default"> <dd>Refers to a pair of SCTP streams over an
<section anchor="section.oa.gen" title="General" SCTPoDTLS association that is used to transport non-media
toc="default"> data between two entities, as defined in <xref
<t> target="RFC8831" format="default"/>.</dd>
This section defines how to const
ruct the SDP Media Description
("m=" line) for describing the SC
TPoDTLS association used to realize
a CLUE data channel. The section
also defines how to use the
SDP-based "SCTP over DTLS" data
channel negotiation mechanism
<xref target="I-D.ietf-mmusic-dat
a-channel-sdpneg" /> for establishing
a CLUE data channel on the SCTPoD
TLS association.
</t>
<t>
NOTE: Other protocols than SDP fo
r negotiating usage of an SCTPoDTLS
association for realizing a CLUE
data channel are outside the scope
of this specification.
</t>
<t>
<xref target="I-D.ietf-clue-signa
ling" pageno="false" format="default" />
describes the SDP Offer/Answer pr
ocedures for negotiating a CLUE session,
including the CLUE controlled med
ia streams and the CLUE data channel.
</t>
<section anchor="section.oa.mediadesc" ti
tle="SDP Media Description Fields" toc="default">
<t>
<xref target="I-D.ietf-mmusic
-sctp-sdp" pageno="false" format="default" /> defines how
to set the values of an "
m=" line describing an SCTPoDTLS association. As defined in
<xref target="I-D.ietf-mm
usic-sctp-sdp" pageno="false" format="default" />, for a
CLUE data channel the val
ues are set as following:
</t>
<texttable anchor="table_SDP_medi
adesc" title='SDP "proto" field values'>
<ttcol align='center'>med
ia</ttcol>
<ttcol align='center'>por
t</ttcol>
<ttcol align='center'>pro
to</ttcol>
<ttcol align='center'>fmt
</ttcol>
<c>"application"</c>
<c>UDP port value</c>
<c>"UDP/DTLS/SCTP"</c>
<c>"webrtc-datachannel"</
c>
<c>"application"</c>
<c>TCP port value</c>
<c>"TCP/DTLS/SCTP"</c>
<c>"webrtc-datachannel"</
c>
</texttable>
<t>
CLUE entities SHOULD NOT
transport the SCTPoDTLS association used to
realize the CLUE data cha
nnel over TCP (using the "TCP/DTLS/SCTP"
proto value), unless it i
s known that UDP/DTLS/SCTP will not work
(for instance, when the I
nteractive Connectivity Establishment
(ICE) mechanism <xref for
mat="default" pageno="false" target="RFC8445"/>
is used and the ICE proce
dures determine that TCP transport is required).
</t>
</section>
<section anchor="section.oa.sctpport" tit
le="SDP sctp-port Attribute" toc="default">
<t>
As defined in <xref targe
t="I-D.ietf-mmusic-sctp-sdp" pageno="false" format="default"/>,
the SDP sctp-port attribu
te value is set to the SCTP port of the SCTPoDTLS association. A
CLUE entity can choose an
y valid SCTP port value <xref target="I-D.ietf-mmusic-sctp-sdp"
pageno="false" format="de
fault"/>.
</t>
</section>
</section>
<section anchor="section.oa.dcmap" title="SDP dcm
ap Attribute" toc="default">
<t>
The values of the SDP dcmap attri
bute <xref target="I-D.ietf-mmusic-data-channel-sdpneg"
pageno="false" format="default" /
>, associated with the "m=" line describing the SCTPoDTLS
association used to realize the W
ebRTC data channel, are set as following:
</t>
<texttable anchor="table_SDP_dcmap" title
='SDP dcmap attribute values'>
<ttcol align='center'>stream-id</
ttcol>
<ttcol align='center'>sub-protoco
l</ttcol>
<ttcol align='center'>label</ttco
l>
<ttcol align='center'>ordered</tt
col>
<ttcol align='center'>max-retr</t
tcol>
<ttcol align='center'>max-time</t
tcol>
<c>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>
NOTE: As CLUE entities are requir
ed to use ordered SCTP message delivery,
with full reliability, according
to the procedures in
<xref target="I-D.ietf-mmusic-dat
a-channel-sdpneg" pageno="false"
format="default" /> the max-retr
and max-time attribute parameters
are not used when negotiating CLU
E data channels.
</t>
</section>
<section anchor="section.oa.dcsa" title="SDP dcsa
Attribute" toc="default">
<t>
The SDP dcsa attribute <xref targ
et="I-D.ietf-mmusic-data-channel-sdpneg" pageno="false"
format="default" /> is not used w
hen establishing a CLUE data channel.
</t>
</section>
<section anchor="section.oa.example" title="Examp <dt>CLUE data channel</dt>
le" toc="default"> <dd>Refers to a WebRTC data channel realization <xref target="RFC8831" forma
<t> t="default"/>, with a specific set of
The example in <xref target="figu SCTP characteristics, with the purpose of transporting CLUE
re_SDP_example" pageno="false" format="default" /> shows protocol messages <xref target="RFC8847" format="default"/> between two CLUE ent
an SDP media description for a CL ities.</dd>
UE data channel. Examples of complete SDP examples can be found
in <xref target="I-D.ietf-clue-si
gnaling" pageno="false" format="default" />.
</t>
<figure anchor="figure_SDP_example" title
="SDP Media Description for a CLUE data channel">
<artwork><![CDATA[
m=application 54111 UDP/DTLS/SCTP webrtc-datachannel <dt>CLUE entity</dt>
a=sctp-port: 5000 <dd>Refers to a SIP User Agent (UA) <xref target="RFC3261" format="default"/
a=dcmap:2 subprotocol="CLUE";ordered=true > that supports the CLUE data channel
and the CLUE protocol.</dd>
]]></artwork> <dt>CLUE session</dt>
</figure> <dd>Refers to a SIP session <xref target="RFC3261" format="default"/> betwee
</section> n two SIP UAs, where a
</section> CLUE data channel, associated with the SIP session, has been
</section> established between the SIP UAs.</dd>
<section anchor="section.sec" title="Security Considerations"> <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 stre
ams 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 sin
gle 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"/>, diffe
rent 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 sen
ding 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 m
essage
is associated with -- only the format in which the data is encod
ed.
</t></aside>
</section>
<section anchor="section.cdc.sctp.reliability" toc="default" numbered="t
rue">
<name>Reliability</name>
<t>
The usage of SCTP for the CLUE data channel ensures reliable tra
nsport 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 pol
icy defined in
<xref target="RFC7496" format="default"/>. A CLUE entity <bcp14>M
UST NOT</bcp14> use
these extensions, as messages are required to always be sent rel
iably. A CLUE entity <bcp14>MUST</bcp14>
terminate the session if it detects that the peer entity uses an
y 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="t
rue">
<name>Stream Reset</name>
<t>
A CLUE entity <bcp14>MUST</bcp14> support the stream reset exten
sion defined in <xref target="RFC6525" format="default"/>.
</t>
<t>
Per <xref target="RFC8831" format="default"/>,
the dynamic address reconfiguration extension parameter ('Suppor
ted Extensions Parameter')
defined in <xref target="RFC5061" format="default"/> must be use
d 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="tru
e">
<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 cl
ose a data channel, an entity sends an SCTP reset
message <xref target="RFC6525" format="default"/> on its outgoin
g
SCTP stream associated with the data channel. When the remote pe
er 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 associati
on, and other data channels
established on the same association, are not affected by the SCT
P 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 SCTPo
DTLS
association for realizing a CLUE data channel are outside the sc
ope
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 ch
annel.
</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 associ
ation. 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> <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 wor
k
(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 r
equired).
</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="R
FC8841" 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" for
mat="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-t
ime 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 e
xamples 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 WebR TC data channel described in This specification relies on the security properties of the WebR TC data channel described in
<xref target="I-D.ietf-rtcweb-data-channel" pageno="false" forma t="default" />, including <xref target="RFC8831" format="default"/>, including
reliance on DTLS. Since CLUE sessions are established using SIP/ SDP, protecting the data reliance on DTLS. Since CLUE sessions are established using SIP/ SDP, protecting the data
channel against message modification and recovery requires the u se of SIP authentication channel against message modification and recovery requires the u se of SIP authentication
and authorization mechanisms described in <xref target="RFC3261" pageno="false" format="default" /> and authorization mechanisms described in <xref target="RFC3261" format="default"/>
for session establishment prior to establishing the data channel . for session establishment prior to establishing the data channel .
</t> </t>
</section> </section>
<section anchor="section.iana" title="IANA Considerations"> <section anchor="section.iana" numbered="true" toc="default">
<section anchor="section.iana.dc" title="New WebRTC data <name>IANA Considerations</name>
channel Protocol Value"> <section anchor="section.iana.dc" numbered="true" toc="default">
<t> <name>Subprotocol Identifier &quot;clue&quot;</name>
[RFC EDITOR NOTE: Please replace RFC-XXXX <t>
with the RFC number of this document.] This document adds the subprotocol identifier "clue" to the "WebSocket S
</t> ubprotocol Name Registry"
<t> as follows:
This document adds the 'CLUE' value to th </t>
e "WebSocket Subprotocol Name Registry"
as follows:
</t>
<figure>
<artwork align="left"><![CDATA[
Subprotocl Identifier: CLUE <table anchor="clue-reg">
Subprotocol Common Name: CLUE <name>Registration of 'clue' Value</name>
Subprotocol Definition: RFC-XXXX <tbody>
Reference: RFC-XXXX <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"/>
]]></artwork> <!-- draft-ietf-mmusic-sctp-sdp (RFC 8841) -->
</figure> <reference anchor="RFC8841" target="https://www.rfc-editor.org/info/rfc8
</section> 841">
</section> <front>
<section title="Acknowledgments"> <title>Session Description Protocol (SDP) Offer/Answer Procedures
<t> for Stream Control Transmission Protocol (SCTP) over Datagram
Thanks to Paul Kyzivat, Christian Groves and Mark Transport Layer Security (DTLS) Transport</title>
Duckworth for comments <author initials="C" surname="Holmberg" fullname="Christer Holmberg"
on the document. >
</t> <organization/>
</section> </author>
<section title="Change Log"> <author initials="R." surname="Shpount" fullname="Roman Shpount">
<t> <organization/>
[RFC EDITOR NOTE: Please remove this section when </author>
publishing] <author initials="S" surname="Loreto" fullname="Salvatore Loreto">
</t> <organization/>
<t> </author>
Changes from draft-ietf-clue-datachannel-17 <author initials="G" surname="Camarillo" fullname="Gonzalo Camarillo
<list style="symbols"> ">
<t> <organization/>
Editorial changes to Tables based on TSV-ART review. </author>
</t> <date month="January" year="2021"/>
</list> </front>
</t> <seriesInfo name="RFC" value="8841"/>
<t> <seriesInfo name="DOI" value="10.17487/RFC8841"/>
Changes from draft-ietf-clue-datachannel-16 </reference>
<list style="symbols">
<t> <!-- draft-ietf-rtcweb-data-channel (RFC 8831) -->
Category changed to Experimental. <reference anchor="RFC8831" target="https://www.rfc-editor.org/info/rfc8831">
</t> <front>
</list> <title>WebRTC Data Channels</title>
</t> <author initials="R" surname="Jesup" fullname="Randell Jesup">
<t> <organization/>
Changes from draft-ietf-clue-datachannel-15 </author>
<list style="symbols"> <author initials="S" surname="Loreto" fullname="Salvatore Loreto">
<t> <organization/>
Updates based on IESG review by Roman Danyliw. </author>
</t> <author initials="M" surname="Tüxen" fullname="Michael Tüxen">
<t> <organization/>
Make CLUE references Informative, as they </author>
are going to be published as <date month='January' year='2021'/>
Experimental RFCs. </front>
</t> <seriesInfo name="RFC" value="8831"/>
</list> <seriesInfo name="DOI" value="10.17487/RFC8831"/>
</t> </reference>
<t>
Changes from draft-ietf-clue-datachannel-14 <!-- draft-ietf-mmusic-data-channel-sdpneg (RFC 8864) -->
<list style="symbols"> <reference anchor="RFC8864" target="https://www.rfc-editor.org/info/rfc886
<t> 4">
ICE reference update. <front>
</t> <title>Negotiation Data Channels Using the Session Description
<t> Protocol (SDP)</title>
Reference draft versions updates. <author fullname="Keith Drage" initials="K." surname="Drage">
</t> <organization>Unaffiliated</organization>
</list> </author>
</t> <author fullname="Raju Makaraju" initials="M." surname="Makaraju">
<t> <organization>Nokia</organization>
Changes from draft-ietf-clue-datachannel-13 </author>
<list style="symbols"> <author fullname="Richard Ejzak" initials="R." surname="Ejzak">
<t> <organization>Unaffiliated</organization>
Editorial changes based on Gen-ART review from Brian Carpent </author>
er. <author fullname="Jerome Marcon" initials="J." surname="Marcon">
</t> <organization>Unaffiliated</organization>
</list> </author>
</t> <author fullname="Roni Even" initials="R." surname="Even" role="editor
<t> ">
Changes from draft-ietf-clue-datachannel-12 <organization>Huawei</organization>
<list style="symbols"> </author>
<t> <date month="January" year="2021"/>
Changes based on AD comments from Alissa Cooper (https://www.ietf. </front>
org/mail-archive/web/clue/current/msg04911.html): <seriesInfo name="RFC" value="8864"/>
</t> <seriesInfo name="DOI" value="10.17487/RFC8864"/>
<t> </reference>
- DCEP reference removed from s </references>
ecurity considerations. <references>
</t> <name>Informative References</name>
<t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3758.
- Editorial fixes. xml"/>
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.
<t> xml"/>
- NOTE: Comment regarding the S
ecurity Considerations is still pending. <!-- draft-ietf-rtcweb-data-protocol (RFC 8832) -->
</t> <reference anchor="RFC8832" target="https://www.rfc-editor.org/info/rfc8832">
</list> <front>
</t> <title>WebRTC Data Channel Establishment Protocol</title>
<t> <author initials='R.' surname='Jesup' fullname='Randell Jesup'>
Changes from draft-ietf-clue-datachannel-11 <organization/>
<list style="symbols"> </author>
<t> <author initials='S.' surname='Loreto' fullname='Salvatore Loreto'>
Changes based on WGLC comments from Juergen Stoetzer-Bra <organization/>
dler and Christian groves: </author>
</t> <author initials='M' surname='Tüxen' fullname='Michael Tüxen'>
<t> <organization/>
- Reference updates. </author>
</t> <date month='January' year='2021'/>
<t> </front>
- 'Reference' added to IANA registration data. <seriesInfo name="RFC" value="8832"/>
</t> <seriesInfo name="DOI" value="10.17487/RFC8832"/>
</list> </reference>
</t>
<t> <!-- draft-ietf-clue-protocol (RFC 8847) -->
Changes from draft-ietf-clue-datachannel-10 <reference anchor='RFC8847' target='https://www.rfc-editor.org/info/rfc8847'>
<list style="symbols"> <front>
<t> <title>Protocol for Controlling Multiple Streams for Telepresence (CLUE)</title>
Security Considerations modified and enhanced, based on <author initials='R' surname='Presta' fullname='Roberta Presta'>
comments <organization />
provided by Alissa Cooper. </author>
</t> <author initials='S P.' surname='Romano' fullname='Simon Pietro Romano'>
</list> <organization />
</t> </author>
<t> <date month='January' year='2021' />
Changes from draft-ietf-clue-datachannel-09 </front>
<list style="symbols"> <seriesInfo name="RFC" value="8847" />
<t>Reference updates:</t> <seriesInfo name='DOI' value='10.17487/RFC8847' />
<t> - draft-ietf-tsvwg-sctp-prpolicies published as RFC 7496 </reference>
</t>
<t> - Reference update of draft versions</t> <!-- draft-ietf-clue-signaling (RFC 8848) -->
</list> <reference anchor="RFC8848" target="https://www.rfc-editor.org/info/rfc8
</t> 848">
<t> <front>
Changes from draft-ietf-clue-datachannel-08 <title>Session Signaling for Controlling Multiple Streams for Telepr
<list style="symbols"> esence (CLUE)</title>
<t>Changes based on WGLC comments from Da <author fullname="Robert Hanton" initials="R." surname="Hanton">
niel Burnett:</t> <organization>Cisco</organization>
<t>- Editorial corrections.</t> </author>
<t>Changes based on WGLC comments from Pa <author fullname="Paul Kyzivat" initials="P." surname="Kyzivat">
ul Kyzivat:</t> </author>
<t>- Editorial corrections.</t> <author fullname="Lennard Xiao" initials="L." surname="Xiao">
</list> <organization>Huawei</organization>
</t> </author>
<t> <author fullname="Christian Groves" initials="C." surname="Groves">
Changes from draft-ietf-clue-datachannel-07 <organization>Huawei</organization>
<list style="symbols"> </author>
<t>Changes based on WGLC comments from Ch <date month="January" year="2021"/>
ristian Groves:</t> </front>
<t>- IANA considerations for dcmap attrib <seriesInfo name="RFC" value="8848"/>
ute removed.</t> <seriesInfo name="DOI" value="10.17487/RFC8848"/>
<t>- Explicit clarification that the dcma </reference>
p attribute max-time </references>
and max-retr parameters are not </references>
used with ordered/reliable <section numbered="false" toc="default">
transmission of SCTP messages.</ <name>Acknowledgements</name>
t> <t>
<t>- Indication that TCP transport should Thanks to <contact fullname="Paul Kyzivat"/>,
only be used if ICE is used, <contact fullname="Christian Groves"/>, and
and if usage of TCP is required by I <contact fullname="Mark Duckworth"/> for comments
CE.</t> on this document.
<t>- Informative reference to ICE added.< </t>
/t> </section>
<t>- Editorial corrections.</t> </back>
<t>Changes based on WGLC comments from Ma
rk Duckworth:</t>
<t>- Make it more clear that the rules re
garding usage of partial
reliability and ordered reliability
apply to CLUE data channels.</t>
<t>Changes based on WGLC comments from Pa
ul Kyzivat:</t>
<t>- Clarify that same SCTP options are a
pplied to each SCTP message
associated with a given data channel
.</t>
<t>- Switched location of sections 3.2 an
d 3.3.</t>
<t>- PPID table removed. Not needed, sinc
e 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 associat
ion' 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 negotiat
ion 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-sd
p 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 fr
om 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, a
s 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"->"SHOUL
D".</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-dat
a-channel-00.</t>
<t>Editorial nits fixed.</t>
<t>Changes based on comments from Paul Ky
zivat (http://www.ietf.org/mail-archive/web/clue/current/msg03559.html).</t>
<t>- Proto value fixed.</t>
<t>- Explicit text that the partial relia
bility 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 off
erer must not insert more than
one "m=" line describing an SCTPo
DTLS association to be used to
realize a CLUE data channel, as t
he draft already states that
only one CLUE data channel per CL
UE 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 supporte
d, 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 agreem
ent (IETF#89) to
use DCEP for the CLUE data channe
l.</t>
<t>Procedures updated, based on WG agreem
ent (IETF#89) that
offerer is responsible for sendin
g DCEP DATA_CHANNEL_OPEN.</t>
<t>Editorial changes, and alignments caus
ed by
changes in referenced specificati
ons.</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 comment
s 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 identifi
er for SDP">
Stream Control Transmission Proto
col (SCTP)-Based Media
Transport in the Session Descript
ion Protocol (SDP)
</title>
<author initials="C." surname="Holmberg"
fullname="Christer Holmberg">
<organization>Ericsson</organizat
ion>
</author>
<author initials="S." surname="Loreto" fu
llname="Salvatore Loreto">
<organization>Ericsson</organizat
ion>
</author>
<author initials="G." surname="Camarillo"
fullname="Gonzalo Camarillo">
<organization>Ericsson</organizat
ion>
</author>
<date day="20" month="April" year="2017"
/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ie
tf-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 Communica
tions</organization>
</author>
<author fullname="Salvatore Loreto" initi
als="S.L" surname="Loreto">
<organization>Ericsson</organizat
ion>
</author>
<author fullname="Michael Tuexen" initial
s="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-ie
tf-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 c
hannel negotiation
</title>
<author fullname="Keith Drage" initials="
K.D" surname="Drage">
<organization>Alcatel-Lucent</org
anization>
</author>
<author fullname="Raju Makaraju" initials
="R.M" surname="Makaraju">
<organization>Alcatel-Lucent</org
anization>
</author>
<author fullname="Juergen Stoetzer-Bradle
r" initials="J.S" surname="Stoetzer-Bradler">
<organization>Alcatel-Lucent</org
anization>
</author>
<author fullname="Richard Ejzak" initials
="R.E" surname="Ejzak">
<organization>Unaffiliated</organ
ization>
</author>
<author fullname="Jerome Marcon" initials
="J.M" surname="Marcon">
<organization>Unaffiliated</organ
ization>
</author>
<date day="23" month="April" year="2019"
/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ie
tf-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 Establ
ishment Protocol">
WebRTC data channel Establishment
Protocol
</title>
<author fullname="Randell Jesup" initials
="R.J" surname="Jesup">
<organization>WorldGate Communica
tions</organization>
</author>
<author fullname="Salvatore Loreto" initi
als="S.L" surname="Loreto">
<organization>Ericsson</organizat
ion>
</author>
<author fullname="Michael Tuexen" initial
s="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-ie
tf-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" initial
s="R.P" surname="Presta">
<organization>University of Napol
i</organization>
</author>
<author fullname="Simon Pietro Romano" in
itials="S P.R" surname="Romano">
<organization>University of Napol
i</organization>
</author>
<date day="21" month="September" year="20
18" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ie
tf-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</organizatio
n>
</author>
<author fullname="Christian Groves" initi
als="C.G" surname="Groves">
<organization>Huawei</organizatio
n>
</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-ie
tf-clue-signaling-14.txt" />
</reference>
</references>
</back>
</rfc> </rfc>
 End of changes. 17 change blocks. 
1069 lines changed or deleted 625 lines changed or added

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