- From: Lennart Grahl <lennart.grahl@gmail.com>
- Date: Mon, 5 Mar 2018 22:57:23 +0100
- To: public-webrtc@w3.org
- Cc: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
On 05.03.2018 22:01, Sergio Garcia Murillo wrote: > 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. Isn't that what ORTC does provide? Cheers Lennart
Received on Monday, 5 March 2018 21:57:49 UTC