- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Tue, 11 Sep 2012 14:22:37 -0400
- To: public-webrtc@w3.org
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