Subject: [rtcweb] Getting rid of SDP

From: Cullen Jennings <[email-masked]>
Date: Mon, 5 Mar 2018 12:43:22 -0700

SDP is pretty awful. 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 [email-masked] 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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 5 Mar 2018 21:56:01 +0100

Hi Cullen,

The proposal goes far beyond of getting rid of SDP, but replacing 
DTLS/SRTP with QUICK, modifying ICE and changing all the media stack all 
together. Without entering to discuss the technical merits of it, I find 
it very difficult to shallow that replacing the current w3c api to 
remove the SDP requires such a huge impact on webrtc.

IMHO, the two discussions should be independent, and I am much more 
worried to remove SDP than replacing my whole media stack. Also, as 
already stated on the w3c list, a enough low level api would allow to 
cover both media over dtls/ice/srtp as usual  and media over quic.

Best regards
Sergio

On 05/03/2018 20:43, Cullen Jennings wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 6 Mar 2018 07:39:38 +0100

Nice to see that you too are arguing that we should get rid of SDP's
design errors!

There are of course design errors (I think) in the proposal you made too
(the most glaring one is that you tie sources to clients - in order to
be generic building tools, sources need global IDs - otherwise we can't
build distribution trees for Baumgartner's parachute jump from space
using the same technology as chatting with Grandma). 128-bit random
numbers are lovely global identifiers. (This is the same error that went
into the original design of the http URL - tying location with identity.
But I digress.)

I'd also like to have a security story that hangs together - each layer
has unique security properties that it needs to make sure are
satisfiable - from the neeed to not make DDOS simple at the network
layer to the assurance that I'm talking to Grandma and not some
CGI-generated scammer-face at the application layer. We've so far failed
to have a security story in WebRTC that is both comprehensive and
attractive to deploy - I'd like to see us do better next time around.

I'm a little bit hesitant to ask this, but .... should we go back and
look at what use cases we plan to solve in this Grand Unified Scheme of
Things?

Harald

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 6 Mar 2018 18:01:50 +1100

Yes, please, let's make a list of the use cases and the problems.
Otherwise it feels like we're re-inventing technology for technology's
sake.

Kind Regards,
Silvia.

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 06 Mar 2018 18:30:19 +0000

I just recently sent an email to the list summarizing a previous list
thread asking people to share use cases that people were looking at.  So,
in a sense I think we've already gone through the exercise of seeking use
cases, getting them, and summarizing them.  The conclusion I came to was
that a set of orthogonal low-level APIs would meet the use cases people had
expressed.

On Mon, Mar 5, 2018 at 11:02 PM Silvia Pfeiffer <[email-masked]>
wrote:

> >> SDP is pretty awful. 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.
> >>
> >> it is being discussed on the [email-masked] 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
> >>
> >>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 6 Mar 2018 11:34:04 -0800

I agree with Peter; we also have input from Sergio's developer survey that
indicates a supermajority of WebRTC developers want lower-level APIs.

One notable aspect of Cullen's proposal is that it aims to replace
basically everything all at once, when several of the individual pieces
could be considered separately (e.g. Snowflake, media-transport-over-QUIC).
Even if we don't think it makes sense to pursue all these pieces, we should
be able to find common ground on a couple pieces for WebRTC v2.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 16 Mar 2018 11:39:18 +0000

> On Mar 6, 2018, at 6:39 AM, Harald Alvestrand <[email-masked]> wrote:
> 

Totally agree we need a 128 bit integer that is globally unique for the source. I was thinking that the hash of the concatenation of conferenceID, endpointID, sourceID would be that. So this may be somewhat just a terminology issue. 

> attractive to deploy - I'd like to see us do better next time around.

Makes sense. Do you have thoughts on some particular security problems that we should be able to solve and either currently don't solve or solve in a way that is painful to use?

> look at what use cases we plan to solve in this Grand Unified Scheme of

This draft was way lacking in goals of what it was trying to fix. I think we need to be clear about what we are trying to accomplish that we can't already do so good to get input on that.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 16 Mar 2018 11:40:52 +0000

> On Mar 6, 2018, at 7:01 AM, Silvia Pfeiffer <[email-masked]> wrote:
> 

Totally agree,  I will drive some of the goals into the next version.

---

From: westhawk <[email-masked]>
Date: Fri, 16 Mar 2018 14:35:42 +0100

> On 6 Mar 2018, at 20:34, Justin Uberti <[email-masked]> wrote:
> 
> I agree with Peter; we also have input from Sergio's developer survey that indicates a supermajority of WebRTC developers want lower-level APIs.
> 
> One notable aspect of Cullen's proposal is that it aims to replace basically everything all at once, when several of the individual pieces could be considered separately (e.g. Snowflake, media-transport-over-QUIC). Even if we don't think it makes sense to pursue all these pieces, we should be able to find common ground on a couple pieces for WebRTC v2.

Cullen’s  ‘quixotic' proposal we could call it :-) 

Another input we should be putting into this process are the proposals that were rejected first time around on
grounds that seem less valid than they did.

We are already incorporating much from the skype/ms proposal that became ORTC.
I think we should look again at what was in the adobe RTMFP based proposal to see if
(for instance) the way it does identity is worth replicating.
I’d also like us to take a second look at IAX2 - specifically the way it obviates ICE. 
(basically setting up a connection via a known good intermediary e.g. a TURN server, then whilst that is up 
probing other possible paths, then flipping over when one of them comes good).

We also need to make a clear stand on legacy interop - much of the complexity we got into
is (IMHO) due to us not knowing what was a consistent level of legacy support.

Tim.