One document matched: draft-jesup-rtcweb-data-protocol-03.xml
<?xml version="1.0"?>
<?rfc symrefs="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc strict="yes" ?>
<rfc ipr="trust200902"
docName="draft-jesup-rtcweb-data-protocol-03.txt" category='std'>
<front>
<title>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>US</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>FI</country>
</postal>
<email>salvatore.loreto@ericsson.com</email>
</address>
</author>
<author initials="M." surname="Tuexen" fullname="Michael Tuexen">
<organization abbrev='Muenster Univ. of Appl. Sciences'>
Muenster University of Applied Sciences</organization>
<address>
<postal>
<street>Stegerwaldstrasse 39</street>
<code>48565</code>
<city> Steinfurt</city>
<country>DE</country>
</postal>
<email>tuexen@fh-muenster.de</email>
</address>
</author>
<date />
<area>RAI</area>
<workgroup>RTCWeb Working Group</workgroup>
<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>
</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.ietf-rtcweb-data-channel'/> the protocol
uses Stream Control Transmission Protocol (SCTP) <xref target="RFC4960"/>
encapsulated on Datagram Transport Layer Security (DTLS) <xref target="RFC6347"/>
as described in <xref target='I-D.tuexen-tsvwg-sctp-dtls-encaps'/> to benefit
from their already standardized transport and security features.</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>
<section title='Terminology'>
<t>This document uses the following terms:
<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>
<t hangText='Channel:'>
A bidirectional channel consisting of two SCTP streams.</t>
</list></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><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 SHOULD default to 16
streams.</t>
<t>It is recommended that additional streams be available dynamically based
on <xref target="RFC6525"/>.</t>
</section>
<section title="Control Messages">
<t>Data Channel Control Messages are sent to manage opening bidirectional
channels. A DATA_CHANNEL_OPEN_REQUEST message is sent on the Stream that is intended to be
used to send in that direction, and a response (DATA_CHANNEL_OPEN_RESPONSE)
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_REQUEST was sent on. This allows association of the
Streams that define the bidirectional channel. Finally, a DATA_CHANNEL_ACK
is sent on the original Stream to complete the 3-way handshake.</t>
<t>Errors are returned by setting the error field of the DATA_CHANNEL_OPEN_RESPONSE
message to a non-0 value. In this case the original sender of
DATA_CHANNEL_OPEN_REQUEST shall close the channel.</t>
<!-- Open questions:
* Should we reserve stream 0 in both directions for control messages
dealing with errors?
* Should we add an ERROR message. This would make the handling
of DATA_CHANNEL_OPEN_RESPONSE messages easier?
* Should we get rid on unused message fields?
* Should we integrate the unordered capability in the Channel Type?
Then we would have:
- Reliable, ordered.
- Reliable, unordered.
- Partially TTL Reliable, ordered.
- Partially TTL Reliable, unordered.
- Partially RTX Reliable, ordered.
- Partially RTX Reliable, unordered.
This would be not too much for a byte...
All of this can simply be changed in the code...
-->
<section title='DATA_CHANNEL_OPEN_REQUEST Message'>
<t>This message is sent initially on the stream used for user messages
using the channel.</t>
<figure align='center'>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Channel Type | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reliability Parameter | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
| Label |
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging">
<t hangText="Message Type: 1 byte (unsigned integer)">
<vspace blankLines="0"/>
This field holds the IANA defined message type for the the DATA_CHANNEL_OPEN_REQUEST
message. The suggested value of this field for IANA is 0x00.</t>
<t hangText="Channel Type: 1 byte (unsigned integer)">
<vspace blankLines="0"/>
This field specifies the type of the channel to be opened:
<list style='hanging'>
<t hangText='DATA_CHANNEL_RELIABLE (0x00):'>
The channel provides a reliable bi-directional communication channel.</t>
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT (0x01):'>
The channel provides a partial reliable bi-directional Communication
channel. User messages will not be retransmitted more times than
specified in the Reliability Parameter.</t>
<t hangText='DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02):'>
The channel provides a partial reliable bi-directional Communication
channel. User messages might not be transmitted or retransmitted
after a specified life-time given in milli-seconds in the Reliability Parameter.
This life-time starts when providing the user message to the Javascript engine.</t>
</list>
</t>
<t hangText="Flags: 2 bytes (unsigned integer)">
<vspace blankLines="0"/>
This field contains the bitwise OR of the following flags:
<list style='hanging'>
<t hangText='DATA_CHANNEL_FLAG_OUT_OF_ORDER_ALLOWED (0x0001):'>
If this flag is set, the channel does not need to preserve the
message sequencing.</t>
</list>
</t>
<t hangText="Reliability Parameter: 2 bytes (unsigned integer)">
<vspace blankLines="0"/>
This field is ignored if a reliable channel is used.
If a partial reliable channel with limited number of retransmissions is
used, this field specifies the number of retransmissions. If a partial
reliable channel with limited lifetime is used, this field specifies
the maximum life-time in milli seconds.</t>
<t hangText="Priority: 2 bytes (integer)">
<vspace blankLines="0"/>
The priority of the channel.</t>
<t hangText="Label: Variable Length (sequence of characters)">
<vspace blankLines="0"/>
The name of the channel in UTF-8, including a trailing '\0' byte.</t>
</list>
</t>
</section>
<section title='DATA_CHANNEL_OPEN_RESPONSE Message'>
<t>This message is sent in response to an DATA_CHANNEL_OPEN_REQUEST message on
the stream used for user messages using the channel. Messages with the
error field set to non-0 values can be sent on any stream; it is suggested
that they be sent (if possible) on an unused stream.</t>
<figure align='center'>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Error | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse Stream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging">
<t hangText="Message Type: 1 byte (unsigned integer)">
<vspace blankLines="0"/>
This field holds the IANA defined message type for the the DATA_CHANNEL_OPEN_RESPONSE
message. The suggested value of this field for IANA is 0x01.</t>
<t hangText="Error: 1 byte (unsigned integer)">
<!-- Should we have a separate ERROR message? -->
<vspace blankLines="0"/>
TBD.</t>
<t hangText="Flags: 2 bytes (unsigned integer)">
<!-- Should we have a separate ERROR message? -->
<vspace blankLines="0"/>
TBD.</t>
<t hangText="Reverse Stream: 2 bytes (unsigned integer)">
<vspace blankLines="0"/>
The identifier for the incoming stream of the channel. The corresponding
DATA_CHANNEL_OPEN_REQUEST message was received on this stream.</t>
</list>
</t>
</section>
<section title='DATA_CHANNEL_ACK Message'>
<t>This message is sent in response to an DATA_CHANNEL_OPEN_RESPONSE message on
the stream used for user messages using the channel. Reception of this message
tells the opener that the channel setup handshake is complete.</t>
<figure align='center'>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging">
<t hangText="Message Type: 1 byte (unsigned integer)">
<vspace blankLines="0"/>
This field holds the IANA defined message type for the the DATA_CHANNEL_ACK
message. The suggested value of this field for IANA is 0x02.</t>
</list>
</t>
</section>
</section>
<section title='Procedures'>
<section title="Adding a Channel">
<t>When one side wants to add a channel, it picks an unused outgoing stream;
if no unused streams are available a negotiation to increase the number
is done.
It then sends a DATA_CHANNEL_OPEN_REQUEST control message on the outgoing stream.</t>
<t>The channel_type and reliability_parameters fields of an incoming
DATA_CHANNEL_OPEN_REQUEST message MUST be used to set up the reverse
stream for the Data Channel so that both directions use the same options.
So both directions are either reliable or use the PR-SCTP extension
defined in <xref target='RFC3758'/> using the same policy and parameter.</t>
<t>When an DATA_CHANNEL_OPEN_REQUEST is received on an incoming
stream, an unused outgoing stream is picked; if no unused streams are
available a negotiation to increase the number is done. A
DATA_CHANNEL_OPEN_RESPONSE message is sent on the outgoing stream,
with the Reverse Stream field set to the incoming stream the
DATA_CHANNEL_OPEN_REQUEST message came in on. If for any reason the
entity receiving the DATA_CHANNEL_OPEN_REQUEST can't open the channel,
then it should respond with an DATA_CHANNEL_OPEN_RESPONSE with an
error value set. Any stream can be used for the
DATA_CHANNEL_OPEN_RESPONSE, but it is recommended that the message be
sent any unused-but-available-stream, and if none are available it may
be sent on any stream.</t>
<t>When a DATA_CHANNEL_OPEN_RESPONSE is received, the Reverse Stream value is matched
against all pending DATA_CHANNEL_OPEN_REQUEST messages. If no match can be found, the
DATA_CHANNEL_OPEN_RESPONSE message SHOULD be ignored. If a match is found, then if
the error value is 0 a DATA_CHANNEL_ACK message is sent on the originator's outgoing
Stream for the channel. If the error value is non-zero, the open failed, and the
originator SHOULD close down the originally-selected outgoing stream and
notify the application.</t>
</section>
<section title="Closing a Channel">
<t>Data Channels shall be closed by resetting the outgoing stream
If an incoming stream is reset by the peer, an corresponding outgoing
stream reset SHOULD be issued. If both streams of a channel are reset,
the channel is closed and the streams are available for reuse for new channel opens.</t>
</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>Data may be sent before the 3-way handshake is complete; if so it must be
sent with in-order delivery set in order to avoid race conditions cause by a
handshake message being lost. This is an exception to the requirement to send
all data using the channel reliability settings.</t>
<section title="Message Length">
<t>The maximum size for messages in this protocol is 2GB (0x7FFFFFF
bytes). In order to avoid blocking all other streams while sending a
large message, a TBD extension to SCTP is required. [If that draft
does not become available, in-protocol chunking of the data would be
required, either using in-packet framing or multiple PPIDs.]</t>
<t>In order for code using this protocol to be compatible with an
alternate transport over WebSockets, it is recommended that string
message size be kept within certain bounds. WebSockets mandates a
maximum length for UTF-8 string Send()s of 123 characters. If
transport over WebSockets is not envisioned, then the limitation is
moot.</t>
</section>
</section>
</section>
<section title="Signaling" anchor="signaling">
<t>This is an application protocol that will normally run on top of
SCTP. In the case of rtcweb, it will run over SCTP/DTLS (SCTP on top
of DTLS). This protocol should be specified in the <fmt>
section of the m=application SDP line (<xref target='fig-sdp-line'/>), details TBD (see <xref target='I-D.ietf-mmusic-sctp-sdp'/>). The <fmt> section
should include the virtual port over the rtcweb DataChannel's SCTP
association runs on. (This would allow for more than one
association to be used on a DTLS connection; it's an open question if this flexibility is needed.)</t>
<t>An a=fmtp line will be used to specify that this protocol is to be used,
and any options. Options would include the number of streams (streams=N), and
may include pre-definitions of data channels to be opened as
soon as the association is available.</t>
<figure title='Data Channel SDP media line' anchor='fig-sdp-line'>
<artwork>
m=application <port> SCTP/DTLS <virtual-port>
a=fmtp:<virtual-port> protocol=webrtc-datachannel;streams=32
</artwork>
</figure>
<section title="Startup considerations">
<t>It has been suggested that in order to speed up channel creation
that an initial set of channels be allowed to be specified in the SDP,
as a very common case for applications will be a fixed set of data
channels. This SDP format would support that: (line split for readability)</t>
<figure title='Data Channel SDP media plus channels' anchor='fig-sdp-startup'>
<artwork>
m=application <port> SCTP/DTLS <virtual-port>
a=fmtp:<virtual-port> protocol=webrtc-datachannel;streams=32;
stream=0;type=0;name="foo";
stream=1;type=1;max-rexmit=4;inorder;name="bar";
stream=2;type=2;max-rexmit-time=400;name="timed 400ms max"
</artwork>
</figure>
<t>The answer would echo the channel definitions from the offer, with
the associated stream numbers to associated with the channel. This
would mean that the data channels would be available to use
as soon as the association has been negotiated.</t>
<t>This may need to be specified via MMUSIC.</t>
</section>
</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:
<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>The authors wish to thank Cullen Jennings, Adam Berquist, Justin Uberti, Randall Stewart, ...
for there invaluable comments.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3758"?>
<?rfc include="reference.RFC.4960"?>
<?rfc include="reference.RFC.6347"?>
<?rfc include="reference.RFC.6525"?>
<?rfc include="reference.I-D.ietf-mmusic-sctp-sdp"?>
<?rfc include="reference.I-D.tuexen-tsvwg-sctp-dtls-encaps"?>
</references>
<references title="Informational References">
<?rfc include='reference.I-D.ietf-rtcweb-overview' ?>
<?rfc include='reference.I-D.ietf-rtcweb-data-channel' ?>
</references>
</back>
</rfc>
<!-- Change log
-->
| PAFTECH AB 2003-2026 | 2026-04-23 12:54:34 |