Re: [rtcweb] data channel protocol comments and potential agenda topic

[Randell Jesup <[e-mail]>]

On 7/22/2012 3:54 PM, Michael Tuexen wrote:
> On Jul 22, 2012, at 6:15 PM, Stefan Hakansson LK wrote:
>
>> On 07/22/2012 05:08 PM, Ejzak, Richard P (Richard) wrote:
>>> I grant you that the API discussion belongs in W3C.  I don't propose
>>> to ignore the websocket API, but surely some adaptations could be
>>> considered (in W3C) if they have potential to bring advantages.
>>>
>>> But several other points I made are unrelated to the design of the
>>> API and do belong in rtcweb.  In particular, it should be possible to
>>> create a data channel (once the SCTP association is established)
>>> without the use of a data channel control protocol and without
>>> requiring it to be pre-specified in SDP.  This is my main suggestion.
>> I think, if doable, that is a good idea. However, I think the authors determined that the data channel control protocol was needed (but Randell/Salvatore/Michael know the details).
> The data channel protocol is required, because:
> * a channel is bi-directional and we need a mechanism to handle collisions.
> * a channel has symmetric properties (like partial reliability
>    policy, partial reliability parameter, priority, ordered/unordered.
>    These need to be communicated.
> If channels are unidirectional, things get much simpler...

Correct.  My initial proposal was a much thinner layer around 
unidirectional SCTP streams, but people clearly preferred bidirectional 
channels, and in particular ones that echo the API (at the W3 level) of 
WebSockets, and I see the appeal and usefulness of that, including the 
"wait until onopen" characteristic - it makes it easy to substitute 
DataChannels for WebSockets and vice-versa (so long as the DataChannel 
doesn't *need* unreliability, and can function with a reliable 
channel).  It's an API that Web authors are comfortable with.

> Please note, that the data channel protocol is not that complex
> (it is basically a three-way handshake), and it is not required
> that the initiator delays sending user messages until the
> handshake is completed. You can actually send the first user message
> right after the first message of the handshake. They could even
> get bundled on the wire. However, this requires that the JS API
> allow this and I think the W3C voted against this.

Correct.  The protocol is *very* simple.  I'll note that my current 
draft indicates signaling for DataChannels that would at least be 
extendable (at the IETF/SDP level) to allowing other/alternate SCTP 
associations on the same DTLS channel, running other protocols, though 
for W3 WebRTC there would be a single one running the DataChannel protocol.

-- 
Randell Jesup
[e-mail]