Re: [rtcweb] Getting rid of SDP

[Justin Uberti <[e-mail]>]

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.

On Tue, Mar 6, 2018 at 10:30 AM, Peter Thatcher <[e-mail]>
wrote:

> 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 <[e-mail]>
> wrote:
>
>> 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.
>>
>> On Tue, Mar 6, 2018 at 5:39 PM, Harald Alvestrand <[e-mail]>
>> wrote:
>> > 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
>> >
>> > On 03/05/2018 08:43 PM, Cullen Jennings 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.
>> >>
>> >> 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 [e-mail] 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
>> >>
>> >>
>> >> _______________________________________________
>> >> rtcweb mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/rtcweb
>> >
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>