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:22:33 +0000
Message-ID: <CAJrXDUE32uFiC6LoSDX4pZUBGE-Uj0V-MD3EX_S9t0p=SoEfwg@mail.gmail.com>
To: youenn fablet <yfablet@apple.com>
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, WebRTC WG <public-webrtc@w3.org>
On Mon, Mar 5, 2018 at 1:53 PM youenn fablet <yfablet@apple.com> wrote:

> On Mar 5, 2018, at 12:25 PM, Peter Thatcher <pthatcher@google.com> wrote:
>
> Even though you have discussion in the IETF going on at 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 like the idea of low level APIs.
> One important missing bit is the ability for web apps to do efficient
> frame processing from getUserMedia/video tracks.
> Moving that forward would be great, the current canvas based approach is
> not ideal.
>
> I do not see very compelling use cases for low-level audio/video
> encoder/decoder API on the other hand.
>

If you want to send media over QUIC or do your own crypto between encode
and network (perhaps over some low-level RTP transport), then you need
access to media after its encoded and before it's decoded.


> Maybe I should look at what was presented at TPAC but I would tend to put
> it at a much lower priority.
>

Here's what I presented:

https://docs.google.com/presentation/d/1Sg_1TVCcKJvZ8Egz5oa0CP01TC2rNdv9HVu7W38Y4zA/edit#slide=id.g29a8672e18_22_120



> 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.
>
>
> The only thing I think your proposal seeks that the three APIs above
> cannot provide is a mechanism for replacing the STUN/TURN message format.
> It could allow for new STUN/TURN message formats if run over QUIC, but if
> they need to be outside of QUIC, then it would need be standardized first
> in the IETF and then added into SLICE.
>
> On Mon, Mar 5, 2018 at 11:48 AM Cullen Jennings (fluffy) <fluffy@cisco.com>
> wrote:
>
>>
>> SDP is really awful - encoding SDP as parsed JSON does not help much.
>> What we need to do to greatly simplify things is get rid of SDP. The offer
>> answer is really complicated for modern systems that have more uniform
>> capabilities so I would like to get rid of offer answer too. To simplify
>> all the control, I think one needs to also simplify STUN, TURN, ICE, RTP,
>> and SRTP.
>>
>> I wrote a draft outlining that - it is at:
>>
>> https://datatracker.ietf.org/doc/draft-jennings-dispatch-new-media/
>>
>> it is being discussed on the dispatch@ietf.org email list ( you can join
>> at https://www.ietf.org/mailman/listinfo/dispatch). Glad to get PR at
>> https://github.com/WhatIETF/draft-jennings-dispatch-new-media
>>
>> Love to get feedback in general and also on how this, or parts of it,
>> would be a good way to go for the next version of WebRTC
>>
>> Thanks, Cullen
>>
>>
>>
>>
>>
Received on Monday, 5 March 2018 22:23:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 5 March 2018 22:23:09 UTC