RE: DataChannels API

The SDP only solution (2a) would easily support the use of additional offer/answer exchanges to add/delete data channels from an existing SCTP association.  The first offer/answer exchange that includes any data channels would cause creation of the SCTP association and subsequent offer/answer exchanges would allow any reconfiguration of those data channels to be executed.  Such reconfiguration requires no SCTP traffic until one of the changed data channels is actually used, so the cost on the wire to make changes is actually lower with this approach when two or more data channels are changed at a time.  And this approach always has a lower cost on the wire to set up the initial set of data channels.

This approach requires a little bit more work for the JS app since data channel changes won't be executed until the next offer/answer exchange.  But this just makes management of data channels more consistent with the way in which audio and video tracks are managed, which I consider to be an advantage.


> -----Original Message-----
> From: Adam Bergkvist []
> Sent: Tuesday, September 11, 2012 6:22 AM
> To: Ejzak, Richard P (Richard)
> Cc:
> Subject: 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 13:48:30 UTC