W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2018

Re: Call for adoption - WEBRTC-QUIC

From: Randell Jesup <randell-ietf@jesup.org>
Date: Thu, 29 Nov 2018 14:15:59 -0500
To: public-webrtc@w3.org
Message-ID: <ee4cd739-1a16-ac37-3f1e-fa402409e0c8@jesup.org>
On 11/29/2018 7:58 AM, westhawk wrote:
>> On 29 Nov 2018, at 13:23, Zhu, Jianjun <jianjun.zhu@intel.com 
>> <mailto:jianjun.zhu@intel.com>> wrote:
>> On 2018/11/29, 12:25 PM, "Ted Hardie" <ted.ietf@gmail.com 
>> <mailto:ted.ietf@gmail.com>> wrote:
>> That leaves me puzzled as to why this is the best WG to develop an 
>> API for it.  As a data transport for HTTP/3, it seems like this would 
>> be of broader interest within the W3C.
>> Transferring data between peers is in WebRTC WG’s scope. I’m curious 
>> about was there any debate on adopting data channel.
> As I recall, there was some debate. Our experience at that point was 
> that adding data in a side channel was a good way to augment a call 
> and that DTMF didn’t do it, nor would server routed websockets.

And p2p was a big win (latency wise) over websockets.  (See below for 
more).  side-channels via server/signaling in SIP had many issues.... ;-)

> The data channel discussion was framed around area I think.
> Standalone data channel (with no associated call) came later and was a 
> surprising success (at least to me).

As one of the people who pushed for DataChannel at the start, and who 
proposed SCTP and multiple channels (instead of a single over-RTP 
channel as IIRC was initially proposed), standalone was always clearly a 
goal - the use case I used to justify it was things like games, which 
might or might not have associated media (and that might change over 
time).  I also was certain that providing a general tool instead of a 
specialized one would lead to many unanticipated usecases and 
applications, and one we considered early was use datachannels as a 
proxy for webtraffic (as uproxy ended up doing), and for implementing 
distributed call setup (thinking about the then-extant Arab Spring and 
blocking of single-source comm channels).

You can go look at some of the arguments from the IETF in taiwan, and 
the list (rtcweb) discussions, and the summary of the Stockholm W3/IETF 
interim when we hammered out the ducktyping to WebSockets and the 0-RTT 

Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam
Received on Thursday, 29 November 2018 19:16:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:45 UTC