W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2012

Re: [ACTION-49] DataChannel issues

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 4 Jul 2012 11:04:29 +0200
Message-ID: <4FF4071D.4050800@ericsson.com>
To: Randell Jesup <randell-ietf@jesup.org>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>, Michael Tuexen <tuexen@fh-muenster.de>
Thanks for putting together these examples.

On 2012-06-27 00:04, Randell Jesup wrote:
> On 6/26/2012 5:18 AM, Stefan Hakansson LK wrote:
>> Adding a DataChannel object [ACTION-49]
>>       Proposal written up by Randell
>>       Not clear what the benefits of introducing it is
>
> Options follow.  I prefer option #3 (with default channels in SDP, but
> I'm also ok with them being held internally for creation on connection).
> Note all of these assume the decision made in Stockholm, which was to
> mirror the WebSockets API (channels must wait on onopen before you call
> send()).
>
> The connection object's main advantage is being able to ask it directly
> for global stats, etc, instead of having those be methods on
> PeerConnection - and if for any reason we want to enable DataChannels
> via something other than PeerConnection, you'd have a discrete
> object/interface already defined for it; or you could allow two data
> connections (associations) per PeerConnection (though there are very
> limited reasons I can see why).
>
> I think "keep it simple, optimize only the common cases" is the right
> tack.  Option #3, with the only optimization being to allow default
> channels in the SDP because that's a very common case.
>
> #1. Minimal internal state, use onopen for adding initial channels:
>
>          connection = pc.createDataConnection(default_streams,...);
>          connection.onopen = connection_onopen;
>          ...
>          pc.createOffer()/createAnswer();
>          ...
>
>          function connection_onopen() {
>             channel_1  = connection.createDataChannel(....);
>             channel_1.onopen = chan_1_connected;
>             channel_1.onmessage = chan_1_messages;
>          }
>
>          function chan_1_connected() {
>             channel_1.send("foo");
>          }
>          etc
>          ...
>          connection.increaseMaxChannelsTo = 1234; // not really needed
>          ...
>          connection.close();
>
> #2. Connection object, early channel creation -
>       Good for static channels; can add channels later.
>
>          connection = pc.createDataConnection(default_streams,...);
>          connection.onopen = connection_onopen; // optional
>          channel_1 = connection.createDataChannel(....);
>          channel_1.onopen = chan_1_connected;
>          channel_1.onmessage = chan_1_messages;
>          ...
>          pc.createOffer()/createAnswer(); // SDP includes channels
>          ...
>
>          function chan_1_connected() {
>             channel_1.send("foo");
>          }
>          etc
>          ...
>          connection.increaseMaxChannelsTo = 1234; // not really needed
>          ...
>          connection.close();  // disconnects all DataChannels
>

The connection object has the nice feature that we get the continuation 
behavior that Anant was talking about at the Stockholm meeting (in that 
case for createOffer()) - you get the object that you use to create 
channels when you have created the connection. But it also feels a bit 
unnecessary. We only allow one connection at a time so there's a create 
function that's only OK to run once until the first connection is 
closed. We introduce an additional layer (with event listeners) that, if 
we disregard from data channel errors (we have onopen/onerror on the 
channel object), will pretty much have the same state as the 
PeerConnection unless the developer closes the connection.

> #3. No connection object, early channel creation -
>       Good for static channels; can add channels later.
>
>
>          pc.addDataChannel(default_streams,...);
>          channel_1 = pc.createDataChannel(....);
>          channel_1.onopen = chan_1_connected;
>          channel_1.onmessage = chan_1_messages;
>          ...
>          pc.createOffer()/createAnswer(); // SDP includes channels
>          // OR the channels are started automatically once the
>          // connection/association is live
>          ...
>
>          function chan_1_connected() {
>             channel_1.send("foo");
>          }
>          etc
>          ...
>          // Don't let user bump channels by hand, leave to automatic
>          ...
>          pc.closeAllDataChannels();  // disconnects all DataChannels
>

We need to think about the naming if we go for an approach like this. 
The method addDataChannel() may be interpreted as the counterpart of 
addStream() which takes a MediaStream as argument. Perhaps it could be 
called something like enable..(). I'm not sure we need it though.

One motivation to have it would be that with the explicit call we could 
avoid cases like:

1. createDataChannel()
wait a while
2. initial offer/answer

Then the channel would open. But if you do it the other way around:

1. initial offer/answer
wait a while
2. createDataChannel()

Then you would have to signal again to get the channel to open. The 
developer has to know this or use the negotiation callback.

I'm not really sure what I prefer. Just writing what I'm thinking.

/Adam

> #4. No connection object, no early channel creation -
>       All channels added after pc is connected.
>
>          pc.addDataChannel(default_streams);
>          ...
>          pc.createOffer()/createAnswer(); // SDP just has data connection
>          ...
>
>          function on_pc_connected() {
>             channel_1 = pc.createDataChannel(....);
>             channel_1.onopen = chan_1_connected;
>             channel_1.onmessage = chan_1_messages;
>          }
>
>          function chan_1_connected() {
>             channel_1.send("foo");
>          }
>          etc
>          ...
>          // Don't let user bump channels by hand, leave to automatic
>          ...
>          pc.closeAllDataChannels();  // disconnects all DataChannels
Received on Wednesday, 4 July 2012 09:04:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC