- From: Peter Thatcher <pthatcher@google.com>
- Date: Mon, 05 Mar 2018 22:19:12 +0000
- To: Lennart Grahl <lennart.grahl@gmail.com>
- Cc: public-webrtc@w3.org, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
- Message-ID: <CAJrXDUFKnnEtjExuBmVEaLjp24hvvbV85vE8iH-f9G6QOwwSdA@mail.gmail.com>
On Mon, Mar 5, 2018 at 2:00 PM Lennart Grahl <lennart.grahl@gmail.com> wrote: > 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? > Yes, but ORTC doesn't provide: 1. Low enough level to be the "ICE controller" (SLICE does by going lower) 2. Access to encoder/decoders to enable sending media over QUIC. In other words, breaking up IceTransport into lower level pieces and RtpSender/RtpReceiver into lower-level pieces would provide even more flexibility than ORTC does. > > Cheers > Lennart > >
Received on Monday, 5 March 2018 22:19:46 UTC