RE: DataChannels API

Hi Randell,
1. I do not think it is necessary to address the use of different protocols over an entire SCTP/DTLS association at this time.  This may be useful for some applications but not necessary for many others.  It would certainly need browser support and require significant new API work, which I am not advocating.

2. I do think it would be useful to allow JS negotiation of different protocols on individual DataChannels (that share a single association).  I agree that your proposal has some support for this but a few small but important things are missing.

3. It should be possible to negotiate the characteristics of a set of DataChannels using SDP so that the application (which may support multiple variants) can negotiate a particular configuration of data channels all at once (alternative 2a).  This is not important if all users download the exact same app, but is crucial in supporting a community of apps that support different (but partly overlapping) sets of capabilities.

4. The only support you have for identifying the function of an individual channel is the "label".  There is no mechanism to reserve labels for any specific meaning across applications.  It also means that if two channels of the exact same type are needed then multiple labels need to be understood to imply the same function.  It should be possible to specify a protocol name and protocol ID for use by each channel in addition to the label.  If a proprietary application understands the label and a generic protocol identifier is sufficient, then nothing more is needed (the current proposal).  But if the app wants to both create a label for a channel and describe the function desired of the channel, it should be able to do so.  Neither of these needs to be vetted by the browser since it is for negotiation only between the JS apps.  The browser simply inserts the agreed Protocol ID into each transmitted SCTP packet.  These two items are added to the API and the SDP so that they can be negotiated between apps.

That's all that I think is needed.  There has already been discussion of 2a, and it seems that the addition of the protocol name and id fields (which could be optional) would be small.

Richard

> -----Original Message-----
> From: Randell Jesup [mailto:randell-ietf@jesup.org]
> Sent: Tuesday, September 11, 2012 1:23 PM
> To: public-webrtc@w3.org
> Subject: Re: DataChannels API
> 
> On 9/11/2012 12:12 PM, Ejzak, Richard P (Richard) wrote:
> > On 9/11/2012 9:01 AM Randell Jesup wrote:
> >> My proposal for the SDP opens the chance at the IETF level to specify
> >> any higher-level protocol to run over SCTP (or SCTP-DTLS). The separate
> >> issue in the W3C context is if more than one association can exist per
> >> PeerConnection (no unless option 3 is taken), and if so how it's
> >> specified - and how it interacts with the JS app - random protocol
> >> support would likely require exposing the majority of the SCTP API to
> JS.
> > It should not be necessary to support multiple associations to support
> multiple protocols.  Each channel should be able to have its own protocol.
> 
> Sure, and they do at one level (the app controls all the data going into
> and out of it).
> 
> However, I think we're talking past each other.  You're talking about
> the protocol running *on* the particular DataChannel, I was talking
> about the protocol running *over* the SCTP/DTLS association (i.e.
> webrtc-datachannels).  Other protocols designed to run on SCTP use
> streams in certain ways which would interact poorly with sharing an
> association, so we need to specify what protocol is used to run over the
> association.
> 
> Thus far we hadn't had any suggestions for defining the per-channel
> protocols.   Applications could encode the protocol into the labels;
> thus far we've said how the DataChannels are used and what they mean is
> up to the application.  This was stated long ago in the rtcweb
> discussions and generally agreed to (that most uses of DataChannels
> would be proprietary application/server-internal protocols, not
> standards built for other transports like T140).
> 
> > It would be really unfortunate if any extensibility mechanism for Data
> Channels to support (at least a limited class of) additional protocols
> required browser extensions.
> 
> Agreed, but right now the use of the DataChannels are totally in the
> application's hands.
> 
> For example, a game may open "chat", "moves" and "ai" channels.  A
> communicate-and-chat app might have audio, video, "JSEP" (for fast
> re-negotiate), "chat" (which could be T140, or not), and dynamically
> open channels when the user drops files onto the window with the
> filename as the label.
> 
> > Agreed that random (or completely general) protocol support requires
> exposing the SCTP API, but I would be happy with supporting "many common"
> protocols (even in restricted modes); with the ones I gave as good
> examples.
> 
> --
> Randell Jesup
> randell-ietf@jesup.org
>

Received on Wednesday, 12 September 2012 00:37:47 UTC