Re: DataChannels API

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.

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

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*.
>

Received on Friday, 7 September 2012 08:40:18 UTC