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 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 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) 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 "clue"</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/ |