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 Tuesday, 11 September 2012 18:24:00 UTC