- From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Date: Mon, 5 Mar 2018 22:01:06 +0100
- To: public-webrtc@w3.org
- Message-ID: <a3783a21-8fa5-435e-3fd9-08608a62745b@gmail.com>
On 05/03/2018 21:45, Bernard Aboba wrote: > On Mar 5, 2018, at 15:30, Peter Thatcher <pthatcher@google.com > <mailto:pthatcher@google.com>> wrote: >> Even though you have discussion in the IETF going on at >> dispatch@ietf.org <mailto:dispatch@ietf.org>, I think that it's worth >> having discussion here about the Web API side of things. I think >> almost your entire proposal could be implemented in JS/wasm with the >> following Web APIs: >> >> - SLICE (what I proposed two virtual interims ago as part of >> https://github.com/w3c/webrtc-ice) >> - QUIC data streams (https://github.com/w3c/webrtc-quic) >> - A low-level audio/video encoder/decoder API (like what I proposed >> at TPAC in 2017) >> >> I think having those APIs available for your idea to be possible to >> implement in a web context (or other similar ideas) is a great >> direction to go. > > [BA] A major advantage of the approach above is that it is modular and > can deliver incremental functionality based on existing work in > RTCWEB, ICE and QUIC WGs without an inherent dependency on RTPv3 or > ICEv2 (though it can also accommodate those things if and when they > become available). +1 I don't think that starting by changing the the media protocols is the best way of defining an api. Let's define a low level modular api (that is what most devs want anyway) that could be reused in different scenarios (ICE+DTLS+ICE or quick) easily. Best regards Sergio
Received on Monday, 5 March 2018 21:01:27 UTC