Re: DataChannels API

On 9/7/2012 4:39 AM, Stefan Hakansson LK wrote:
> To me,
>
> 2a seems like the most reasonable approach. I argued for 1 at the MV
> interim, but the response from the attendants was clear, 2 is what they
> preferred.
>
> And to me 2a seems like the cleanest approach. If there is no
> association when pc.createDataChannel() is called, an association will
> be created:
>
> 1. pc.createDataChannel makes the pc fire a "negotiationneeded" event.
> 2. When the app as a result of that event does pc.createOffer there will
> be an m-line for the data association in the SDP.

Correct.

> (I must admit I do not fully understand what is meant by 2b "calls are
> queued internally"; could you elaborate?)

In 2b, there are no pending channel creation entries in the SDP, just 
the m=application line (and and associated a=fmtp line).  When the 
association is connected (and onconnected fires), all pending channel 
creates would occur and open requests would be sent to the other side.

In 2a, there would be entries in the SDP for each channel creation 
pending with all the information needed to create it - effectively the 
dictionary values plus the outgoing stream number.  This means more work 
nailing down the SDP (in MMUSIC I presume), and more parsing and 
generation code.  The advantage is 1-1.5RTT faster opens (which is on 
top of the call creation, DTLS handshake and SCTP/DTLS connect times).


> Stefan
>
> On 09/06/2012 04:09 PM, Randell Jesup wrote:
>> 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 Friday, 7 September 2012 09:51:29 UTC