Re: [ACTION-49] DataChannel issues

Does #3 allow running whatever I want over the channels and not having to put it inside some other next protocol handshake? I think it might but not sure - I'd see that as a good thing because it makes it easier to to use the data channel to intemperate with things like BFCP and various far end camera control protocols. 

On Jun 27, 2012, at 9:09 , Randell Jesup wrote:

> On 6/27/2012 5:00 AM, Stefan Hakansson LK wrote:
>> On 06/27/2012 12:04 AM, 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.
>> 
>> I also like #3 best (or #4 - they do not seem that different to me).
> 
> The main difference is with #3 (w/SDP) you can pre-define the channels you want and avoid setup time after the PeerConnection gets connected. Many apps will just have a fixed set of data channels.  Downside is having to deal with the SDP side of things (more code, more complexity).  Martin Thompson wanted to find ways to optimize DataChannel creation, especially at call-start time.
> 
> Note that #3 does allow for the option of not using SDP, but queuing the creations inside PeerConnection.  This gives the user the nice API and is simpler, but also slower at startup.
> 
>> 
>> But a couple of questions:
>> 
>> * Is there really a gain in adding "addDataChannel" and
>> "closeAllDataChannels"? In the current draft [1] you can do "dc =
>> pc.createDataChannel" and then dc.close. Would that not be sufficient?
> 
> It would, especially in case #3 (for #4, it would involve a mandatory renegotiation right after call start - a bad thing).
> 
>> For the very first data channel created there is an SDP o/a needed, but
>> the app can treat that as opaque, just do the
>> createOffer-setLocal-send... thing whenever a "renegotiationneeded"
>> event is fired. And likewise, if all data channels have been closed a
>> re-negotiation would be needed again, but this could happen as a result
>> of the app closing all of them, no need for "closeAll".
> 
> Yes, those are all true, but especially the first would impact initial data channel creation time at call startup.  close/closeAll aren't mandatory at all, but they give you a 'hook' for dropping the association or keeping it warm (if you expect randomly arriving traffic, like if you use it to proxy other data - you don't want it autoclosing, so app developers would need to prop it open with a dummy connection).
> 
>> * I have never understood why there should just be a limited set of data
>> channels signaled in the SDP o/a. If data is added, could not all SCTP
>> streams be used? And if the app tries to open more than 64k (or whatever
>> the limit is) there would be an error.
> 
> There's a delay to negotiate more streams (and in theory it can fail). We don't want to default to 65536 streams, because they do cost memory - not much, but there are tables in SCTP of streams.  The protocol will automatically add streams as needed; the suggested default is 16 simultaneous.
> 
> -- 
> Randell Jesup
> randell-ietf@jesup.org
> 
>

Received on Thursday, 28 June 2012 17:59:19 UTC