One document matched: draft-jesup-rtcweb-data-protocol-00.xml
<?xml version="1.0"?>
<?rfc symrefs="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="trust200902"
docName="draft-jesup-rtcweb-data-protocol-00.txt" category='std'>
<front>
<title abbrev="data protocol P2P in RTCWEB">
WebRTC Data Channel Protocol
</title>
<author initials="R." surname="Jesup" fullname="Randell Jesup">
<organization>Mozilla</organization>
<address>
<postal>
<street></street>
<code></code>
<city></city>
<country>USA</country>
</postal>
<email>randell-ietf@jesup.org</email>
</address>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>salvatore.loreto@ericsson.com</email>
</address>
</author>
<author initials="M." surname="Tuexen" fullname="Michael Tuexen">
<organization>Muenster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<code>48565</code>
<city> Steinfurt</city>
<country>Germany</country>
</postal>
<email>tuexen@fh-muenster.de</email>
</address>
</author>
<date year="2012" />
<area>RAI</area>
<workgroup>RTCWeb Working Group</workgroup>
<keyword></keyword>
<keyword></keyword>
<abstract>
<t>The Web Real-Time Communication (WebRTC) working group is charged to provide
protocols to support for direct interactive rich communication using
audio, video, and data between two peers' web-browsers. This document
specifies an actual (minor) protocol for how the JS-layer dataChannel
objects provide the data channels between the peers.</t>
<t>This minor protocol has applicability to other bidirectional uses of SCTP. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The Data Channel Protocol is designed to provide, in the WebRTC context
<xref target='I-D.ietf-rtcweb-overview'/>, a generic transport service
allowing Web Browser to exchange generic data in a bidirectional peer to
peer fashion. As discussed in <xref target='I-D.jesup-rtcweb-data'/> the
protocol uses Stream Control Transmission Protocol (SCTP) <xref
target="RFC4960"/> encapsulated on Datagram Transport Layer Security (DTLS)
<xref target="RFC6347"/> to benefit from their transport and security
already standardized features.</t>
</section>
<section title="Opening handshake">
<t>The opening handshake is based on the multimedia session description
exchange that happens between the browsers, typically through a Web Server
acting as the signaling service.</t>
<t>The draft <xref target='I-D.ietf-mmusic-sctp-sdp'/> defines the protocol
identifier, 'SCTP/DTLS', and defines how to establish an SCTP association
over DTLS using the Session Description Protocol (SDP).</t>
<t>The SCTP association is created with the number of streams specified by
the application, and if not specified, then it shall default to 16
streams.</t>
<t>It is recommended that additional streams be available dynamically based
on <xref target="RFC6525"/>.</t>
</section>
<section anchor='con' title="Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target='RFC2119'/>.</t>
<section title='Terminology'>
<t>This document uses the following terms:</t>
<t><list style='hanging'>
<t hangText='Association:'>An SCTP association.</t>
<t hangText='Stream:'>A unidirectional stream of an SCTP association.
It is uniquely identified by a stream identifier.</t>
</list></t>
</section>
</section>
<section title="Control Messages">
<t>Data Channel Control Messages are sent to manage opening bidirectional
channels. A DATA_CHANNEL_OPEN is sent on the Stream that is intended to be
used to send in that direction, and a response (DATA_CHANNEL_OPEN_RESPONSE)
using the same structure is sent back on the Stream to be used for the
other direction, with a reverse_direction_stream entry holding the Stream
number the DATA_CHANNEL_OPEN was sent on. This allows association of the
Streams that define the bidirectional channel.</t>
<t>Errors are returned by setting the first 16 bits of the msg_type_data
field to a non-0 value. In this case the original sender of
DATA_CHANNEL_OPEN shall close the channel.</t>
<t>
<figure title='Data Channel control messages: OPEN and OPEN_RESPONSE Messages' anchor='fig-control-msg'>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPID = Data Channel Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg_type | channel_type | flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reverse_direction_stream | reliability_parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg_type_data \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'msg_type' contains:
DATA_CHANNEL_OPEN 0
DATA_CHANNEL_OPEN_RESPONSE 1
'channel_type' contains:
DATA_CHANNEL_RELIABLE 0
DATA_CHANNEL_RELIABLE_STREAM 1
DATA_CHANNEL_UNRELIABLE 2
DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT 3
DATA_CHANNEL_PARTIAL_RELIABLE_TIMED 4
'flags' contains:
DATA_CHANNEL_FLAG_OUT_OF_ORDER_ALLOWED 0x0001
all other bits are reserved
'msg_type_data' contains:
for DATA_CHANNEL_OPEN:
a DOMString label for the data channel
for DATA_CHANNEL_OPEN_RESPONSE:
a 16-bit value for errors or 0 for no error
'reliability_parameters' contains (as unsigned 16-bit numbers):
for DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT:
the maximum number of retransmits or 0 for none
for DATA_CHANNEL_PARTIAL_RELIABLE_TIMED:
the maximum time in ms to attempt to deliver the data
or 0 for no attempts.
</artwork>
</figure></t>
<t>Note that the forward and reverse-direction Stream numbers may be
different if both sides attempt to open the same Stream number at the same
time, and the protocol does not require they be the same.</t>
<t>Control messages shall be sent on the relevant Streams, and shall be
sent using reliable, in-order delivery.</t>
<section title="Adding a Channel">
<t>
When one side wants to add a channel, it picks an unused Stream, and if
need be, negotiates an increase in the number of Streams available. It
then sends a DATA_CHANNEL_OPEN control message on the Stream, with
reverse_direction_stream set to 0, though that value MUST be ignored by the
recipient.</t>
<t>When a DATA_CHANNEL_OPEN is received on a Stream, an unused Stream is
picked, and if need be, negotiates an increase in the number of Streams
available. A DATA_CHANNEL_OPEN_RESPONSE is sent on the Stream, with
reverse_direction_stream set to the Stream the DATA_CHANNEL_OPEN request
came in on.</t>
<t>When a DATA_CHANNEL_OPEN_RESPONSE is received, the
reverse_direction_stream value is matched against all pending
DATA_CHANNEL_OPENs. If no match can be found, the
DATA_CHANNEL_OPEN_RESPONSE should be ignored. If a match is found, then if
the error value is 0 the bidirectional Data Channel is now established and
ready for use. If the error value is non-zero, the open failed, and the
originator should close down the originally-selected Stream and notify the
application.</t>
<t>An alternative to embedding the control messages on the Streams used for
data transfer would be to put them on a reserved Stream (0 for example),
and add an additional field for the forward_direction_stream.</t>
<t>The channel_type and reliability_parameters fields of the
DATA_CHANNEL_OPEN message MUST be used to set up the reverse side of the
Data Channel so that both directions use the same options.</t>
</section>
<section title="Closing a Channel">
<t>Data Channels shall be closed by doing an SCTP Stream Sequence Number
reset, which should guarantee that all data sent before closing is
delivered or has been abandoned (for partially-reliable Data Channels).</t>
</section>
</section>
<section title="Sending and Receiving Data">
<t>Data shall be sent using PPID's other than the Data Channel Control
PPID. These PPID's should be registered with IANA via (TBD). The meaning
of these data PPIDs and the format of the data shall be specific to the
usage of this protocol, and typically shall be provided to the higher
layers to allow proper decoding of the data.</t>
<t>For WebRTC, data PPID's for DOMStrings and binary data blobs shall be created.</t>
<t>All data sent on a Data Channel in both directions MUST be sent over the
underlying Stream using the reliability defined when the Data Channel was
opened.</t>
<t>It is recommended that message size be kept within certain bounds (TBD).</t>
</section>
<section title="Security Considerations" anchor="sec-security">
<t>
To be done.
</t>
</section>
<section title="IANA Considerations" anchor="sec-IANA">
<t>
This document also defines three new SCTP Payload Protocol Identifiers
(PPIDs). RFC 4960 <xref target="RFC4960"/> creates the registry from which these
identifiers have been assigned. The following values have been
reserved:
</t>
<t><list style='hanging'>
<t hangText='WebRTC Control -'> #To Be Assigned</t>
<t hangText='DOMString -'> #To Be Assigned</t>
<t hangText='Binary Data -'> #To Be Assigned</t>
</list></t>
</section>
<section title="Acknowledgments">
<t>Many thanks for comments, ideas, and text ... (TBD)</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.I-D.ietf-mmusic-sctp-sdp"?>
<?rfc include="reference.RFC.4960"?>
<?rfc include="reference.RFC.6347"?>
<?rfc include="reference.RFC.6525"?>
</references>
<references title="Informational References">
<?rfc include='reference.I-D.ietf-rtcweb-overview' ?>
<?rfc include='reference.I-D.jesup-rtcweb-data' ?>
</references>
</back>
</rfc>
<!-- Change log
-->
| PAFTECH AB 2003-2026 | 2026-04-23 08:20:20 |