RE: DataChannels API

I prefer 2 (don't have an opinion between a and b).  I think it is much
safer to create a data channel only when both parties in the call
explicitly decide to do so.  I don't see the advantage of 3, but I could
live with it.  

- Jim

-----Original Message-----
From: Randell Jesup [mailto:randell-ietf@jesup.org] 
Sent: Thursday, September 06, 2012 10:09 AM
To: public-webrtc@w3.org
Cc: Enda Mannion (emannion)
Subject: Re: DataChannels API

On 9/6/2012 9:23 AM, Stefan Hakansson LK wrote:
> On 09/03/2012 03:27 PM, Stefan Hakansson LK wrote:
>> On 08/31/2012 11:05 PM, Randell Jesup wrote:
> [...]
>>> Open Issues:
>>> ==========
>>>
>>> When can createDataChannel() be called?
>>> ----------------------------------------------------------
>>>
>>> Currently pc.createDataChannel() must be called after onconnected 
>>> fires.  This was a point of discussion at the meeting and on the 
>>> rtcweb list, since DataChannels need some RTTs to establish; 
>>> allowing the application to pre-request data channels would allow 
>>> them to be included in the signaling (and thus save 1 RTT off the 
>>> setup time).
>>
>> I think this makes sense.
> Clarification: I mean the possibility to pre-request must be supported

> (and if not supported it is unclear how peerConnection would ever go 
> to open state if no audio or video is added).

The API (as it currently exists and has existed in the draft) has caused
me to presume that we would add m=application lines for SCTP/DTLS to all
WebRTC offers, and always respond with m=application lines if they were
in the offer.  (We don't *have* to do this; we could renegotiate on the
first createDataChannel() call, but I'd prefer not to for latency
reasons.)

Given this, after a PeerConnection gets connected, the SCTP/DTLS
association would connect automatically, and then remain idle waiting
for DataChannel connections to be created.  In the BUNDLE case, this is
all on one port.

We have options (expanding on the comments in my post in full enumerated
detail):

1) Connect association always (per above).  Always offer; always answer
if offered.

1a) pc.createDataChannel() must wait for onconnected to fire
1b) pc.createDataChannel() can be called before onconnected and is
queued internally
1c) pc.createDataChannel() can be called before CreateOffer and the
creation is exposed in SDP to cut out 1RTT from channel creation at
startup.  If called after CreateOffer and before onconnected it's queued

2) Connect association on demand.  No m=application line by default.  
pc.createDataChannel() before CreateOffer causes m=application to be
added.

2a) pc.createDataChannel() calls are exposed in SDP in CreateOffer (when
CreateOffer is needed because there was no association yet).
2b) pc.createDataChannel() calls are queued internally

3) Have a DataConnection object created by pc.createDataConnection().  
createDataChannel() is on that object. If pc.createDataConnection()
controls if the m=application line is included in an Offer, and if added
later causes a renegotiation. Calling dataconnection.close() would cause
a renegotiation to disable the m=application line (port 0).

3a) Current limit of one DataConnection applies - you can only call
createDataConnection() once; if it exists or is being negotiated a
second call returns an error.
3b) Multiple DataConnections are allowed.  Note this would require
pseudo-ports for SCTP in the SDP since with BUNDLE they'd all run across
one DTLS connection.

3x) With option 3 and especially 3b, there's an option to run some other
sort of protocol in addition to the DataChannel protocol. However, you'd
need to define the JS API for that protocol and integrate that with
DataConnection, or define a 3rd object (DataProtocol?) which
createDataChannel() (and whatever this 3rd protocol needs) are hung off.

Anyone who has an opinion, please indicate which option (and why!), and
if others are acceptable, please let us know that.  If you don't care,
that's fine to say, or just don't say and we'll assume you don't care.
:-)

Right now I've implemented 1a (which is simple).  My preference is
probably for 2a, though 2b is simpler and we could (via the IETF) switch
to 2b later if we want.  My reason for preferring 2a is to avoid needing
to signal a dataconnection and always create an association which will
heartbeat (though that doesn't use any real bandwidth) if we don't plan
to use it.  Secondary plus for me is that call setup with a DataChannel
is marginally simpler (one less callback function needed).  Note on 3x: 
3x gains you little unless we plan to offer other protocols *at the JS
level*.

--
Randell Jesup
randell-ietf@jesup.org

Received on Thursday, 6 September 2012 15:10:48 UTC