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 14:10:34 UTC