RE: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

From: Adam Roach [mailto:adam@nostrum.com]:
> 
> I think this is a hopelessly naïve interpretation of the facts on the ground.
> Simply discarding SDP doesn't magically make the underlying issues go away.
> We would still need to settle a vast number of issues around things like
> simulcast, FEC, codec parameters, indication of supported codecs, correlation
> of RTP streams with MediaStreamTracks, attempts by both parties to
> operate on the same stream simultaneously [1], etc. Basically, with very rare
> exception, the same set of problems that we need to solve if we *don't*
> throw SDP out the window.

Not today we wouldn't. We'd need a handful on knobs that let the most common use cases be implemented under JavaScript control, and then we could look at what other APIs need to be added later. None of simulcast, FED, or any of those things (with the exception of the "a=fmt" section for codec parameters or an equivalent) needs to be done to get WebRTC out the door.


> ...
> Your pain point isn't SDP syntax. Yeah, it's ugly, but it's not hard.
> Your pain point isn't offer/answer.

Yes it is. It immediately limits the possible operations that *any* API would be able to achieve.

> Two unilaterally declared sessions that are
> simply blasted out onto the wire only satisfies the simplest of use cases; you
> need a negotiation, and any attempt to define how that negotiation looks is
> going to arrive at something with enough rules that it is substantially as
> complicated as offer/answer.

Simply not true. Offer/answer is only one way to get two things to talk to each other, and it is a "trunk side" "peer to peer" negotiation that assumes no intelligence in the middle.

> 
> No, your pain point here is that non-master-slave networked
> communications are not easy to get right

Aha! I think I see your problem here.

If we give the web developer some JavaScript APIs, then it isn't "non-maser-slave networked communications". In fact it is exactly the opposite. 

Just like all other "HTML5" technologies we should be assuming that the web server and the HTML+JS it sends down *is the master*, telling the browser exactly what it should do. In this scenario, there are a multitude of ways, from simple to complex, to ensuring that both (or more, for any non 1-1 use case) ends are sending data over their network connection that the other end can use and render.

> I understand comment 22 at its core [2], but it has a corollary: any system
> that replaces SDP O/A will end up being similar in complexity once all
> interested parties' use cases have been factored in.

I doubt it. But even if that's true, it will give the JavaScript developer direct control over what is happening, and that's a win. And likely, much of the "extra complexity" you are thinking of will end up in shared JS libraries, not baked into a browser. And the legacy interop you're concerned about? Any compatibility issues will get fixed right in that same place, long before any browser vendor works out exactly what is necessary to work with a particular device that a web site operator cares for their users to connect to.

Matthew Kaufman

ps. Comment 22 isn't "SDP is hard"... rather it is "if you were using our API, you wouldn't be encountering this issue at all"

Received on Friday, 19 July 2013 18:38:57 UTC