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

Re: Getting rid of SDP

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

Received on Monday, 5 March 2018 21:01:27 UTC

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