Re: DataChannels API

On 9/7/2012 6:26 PM, Ejzak, Richard P (Richard) wrote:
> Among the options for DataChannel API, I prefer 2a.
>
> There is almost no cost to establishing and maintaining as many DataChannels as might be needed in advance using SDP, whereas there is extra signaling and delay to establish one on the fly.  It would also be useful to verify all at once that the needed set of DataChannels can be established by the application.

Speed of setup is helped by 2a.  Knowing if all were accepted *and* 
established is not affected by 2a vs 2b, or even by 2 vs 1.  You still 
have to wait for onopen to fire on all the channels before you know if 
all opened.  (Depending on the SDP impl, you may be able to sniff the 
SDP and know if it was accepted, but you're still gated on the 
association coming up.)

> The tradeoff is between implementing the control protocol versus implementing the SDP extensions.  I think the SDP extensions are more efficient and generally more useful so would prefer that we start with them and only add the control protocol later if necessary.

I think there's a misunderstanding of the options presented.  All of 
these presume a control protocol; some just give different ways to 
access it and speed up initial handshakes and channel establishment by 
effectively sending the control info over existing SDP.  Any later opens 
would be slowed down by using SDP (at best it would itself *over* a 
DataChannel, but SDP is orders of magnitude heavier-weight than the 
control protocol proposed, both in processing and complexity.)

> This approach would also make it easier to signal in advance the desire to use a DataChannel for other protocols, such as MSRP, BFCP, T.140 or perhaps any new telepresence control protocols to be defined in CLUE.  We don't yet have RFC's describing how to use DataChannel transport with these protocols, but that should be pretty straightforward.  We need a clean extensibility mechanism to support these other non-audio/non-video protocols.

My proposal for the SDP opens the chance at the IETF level to specify 
any higher-level protocol to run over SCTP (or SCTP-DTLS). The separate 
issue in the W3C context is if more than one association can exist per 
PeerConnection (no unless option 3 is taken), and if so how it's 
specified - and how it interacts with the JS app - random protocol 
support would likely require exposing the majority of the SCTP API to JS.

>
> Using a DataChannel for T.140, for example, should not change the basic API for data transfer between the JS and the browser.  All that is needed is to be able to signal use of t140 on a DataChannel in the SDP, and to specify the ProtocolID for use in SCTP (the browser should not need to know anything about t140 to do this).  These could even potentially be signaled to the browser during set local via the SDP without impacting the API itself, although it would be cleaner to pass the protocol name and ProtocolID to the browser when creating the DataChannel.

This would require a very different API between the JS and the browser 
(see above).

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Tuesday, 11 September 2012 14:01:58 UTC