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 23:56:58 +0000
Message-ID: <CAJrXDUH-d-4Vrk91zwf9BO3gAaBDqW9RwtVYu3QjFYRJhf1OGQ@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 3:42 PM youenn fablet <yfablet@apple.com> wrote:

> 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.
>
>
> I am not opposed to exposing capabilities of the platform to web pages, I
> just want to make sure we do that in the right order.
> If what is just missing for PERC-like scenarios is this encoder/decoder
> API, that would raise the priority to me.
>

I think breaking up the RtpSender into encoder and RtpTransport such that
you could inject your own encryption stage in between is a good way to go
about it.


> It seems though that this API might require additional APIS to being
> really useful (I probably need to read your presentation first).
>
> Also, to be clear, exposing decoders/encoders that the platform supports
> seems good to me as a principle.
> On the other hand, allowing web pages to provide their own JS/WASM
> encoders/decoders would require compelling scenarios that are not feasible
> otherwise.
>
I have not heard yet at any such scenario (again I might need to read your
> presentation first).
>
> Thanks for your efforts in moving this forward,
> Y
>
>
> 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 23:57:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 5 March 2018 23:57:36 UTC