RE: DataChannels API

I completely agree that the browser "does not care and should not care" about the protocol carried within a data channel.  I am suggesting that the API allow the JS to specify the reliability characteristics of a data channel and the ProtocolID (as I mentioned this could also be done via SDP during set local or set remote) to be used in the data channel without requiring the browser to understand or validate it.  The JS can then specify within the SDP to the peer JS that it wants t140 (for example) on the data channel and supply t140 protocol units to the browser as blobs of data to be transmitted. 

Richard

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no]
> Sent: Tuesday, September 11, 2012 10:00 AM
> To: public-webrtc@w3.org
> Subject: 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:48:00 UTC