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

Re: Getting rid of SDP

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 05 Mar 2018 22:19:12 +0000
Message-ID: <CAJrXDUFKnnEtjExuBmVEaLjp24hvvbV85vE8iH-f9G6QOwwSdA@mail.gmail.com>
To: Lennart Grahl <lennart.grahl@gmail.com>
Cc: public-webrtc@w3.org, Sergio Garcia Murillo <sergio.garcia.murillo@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

This archive was generated by hypermail 2.3.1 : Monday, 5 March 2018 22:19:47 UTC