RE: DataChannels API

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.  

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.

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.

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.

Richard

Received on Friday, 7 September 2012 22:27:28 UTC