Re: DataChannels API

On 2012-09-08 00:26, 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.
>

A clarifying question: are you voting for a solution where data channels 
only can be set up when the SCTP association is created? Or would it be 
OK to add more channels later (with an extra SDP exchange)?

I would say that our API is optimized for creating new channels on the fly.

/Adam

> 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 Tuesday, 11 September 2012 11:22:43 UTC