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

Re: Getting rid of SDP

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>
Message-ID: <5f3d368c-b02e-b49e-d0ca-9463fe8e969a@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?

Received on Monday, 5 March 2018 21:57:49 UTC

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