Re: DataChannels API

On 09/08/2012 12:26 AM, 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.
>
> 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.
I think I'm lost at this point. My mental model of data channels doesn't 
allow me to process the suggestion above.

The SDP, in the simple case, is something the browser constructs in 
order that the application can send it to the other browser, and correct 
configuration of both browsers can occur.

A data channel carries data from one JS application to another JS 
application. The existence of the data channel is part of the browser 
configuration; the format of the data carried over the channel, 
crucially, is NOT.

Thus, if a data channel is to be used for T.140 traffic, *the browser 
will have no idea that this is the case*.
It will not produce SDP saying that this is the case, and if this is 
indicated in the incoming SDP, it will ignore that part, and produce no 
response for it (if it's ignorable).

The implication is that if T.140 carried on a data channel is going to 
be carried in SDP, that information has to be inserted and parsed by the 
JS application. The browser does not care, and should not care.

Am I the one who's wandered off the reservation?

              Harald

Received on Tuesday, 11 September 2012 15:00:28 UTC