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

Re: Getting rid of SDP

From: Suhas Nandakumar (snandaku) <snandaku@cisco.com>
Date: Tue, 6 Mar 2018 02:04:56 +0000
To: Peter Thatcher <pthatcher@google.com>
CC: youenn fablet <yfablet@apple.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, WebRTC WG <public-webrtc@w3.org>
Message-ID: <139BC2C0-A37E-4ED7-905E-AD6CC364E353@cisco.com>
Not saying this is exactly same .. but we can think of decomposition on lines similar to what is defined in here : https://tools.ietf.org/html/rfc7656#section-2.1

Sent from my iPhone

On Mar 5, 2018, at 4:01 PM, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:

On Mon, Mar 5, 2018 at 3:42 PM youenn fablet <yfablet@apple.com<mailto: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,

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:


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<mailto: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:


it is being discussed on the dispatch@ietf.org<mailto: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 Tuesday, 6 March 2018 02:05:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 March 2018 02:05:27 UTC