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

Adam Roach [mailto:adam@nostrum.com]
>
> I think any time someone says they've used the SDP directly as a control
> surface in a JavaScript application, it indicates a hole in the current WebRTC
> specification that we need to fix.
> 
> SDP is not supposed to be the WebRTC API surface.

But it is, at least in some sense, even if we come up with lots of constraint APIs.

> 
> I think we all pretty much agree that SDP is not supposed to be the WebRTC
> API surface.

Not sure about that, but suppose that's true for a moment...

> 
> I think we're pretty much all on the same page that we need to add stuff to
> the current API to handle these use cases.


But how can we possibly add stuff to the current API that runs directly counter to the fact that 1) the two browsers are attempting to negotiate things with one another over an SDP-based channel instead of doing what the application developer tells them to do and 2) because that negotiation is based on offer-answer, there is a state machine that will prohibit or allow certain state transitions at various times in the process?

This is a serious problem. As long as we assume that there is an API that emits SDP that is intended to be heard by the "far" browser and answered with more SDP from the "far" browser, any API that we specify will be akin to poking the browsers with a stick rather than directly grabbing the controls. Which is crazy, if you think about how the web server + the HTML and JavaScript that it emits is otherwise *completely* in control of what a browser does. (Short of the user closing the window, and even that can be intercepted!)

> 
> 
> 
> > Maybe I'm wrong, but I'm guessing what you're saying will sound like.
> >  "my use case (legacy interop) is the most important and my solution
> > (SDP) is the best solution for everyone and I know better because I've
> > been working on it for longer".  Hubris?
> 
> No, you've misunderstood pretty much everything I said. I'll summarize
> in fewer words.
> 
> My point is that we need to solve these problems one way or another, and
> SDP isn't really the reason it's difficult.

Some, but not all, of these "problems" need solving now. A whole lot can be deferred and certainly don't need a trip to MMUSIC *now* to sort out. An API that lets you send an audio and a video stream on the same RTP session could ship *today*, without any agreement as to what SDP represents that.

> 
> But by incorrectly deciding that SDP (or offer/answer, depending on who
> you listen to) is the reason it's hard, we're trying to throw legacy
> interop out the window for very little gain.

Legacy interop has been out the window for over a year now. We have ICE required, we have DTLS-SRTP required, and sort of by definition *anything* that WEBRTC has had to go to MMUSIC for more SDP parameters for isn't compatible with "legacy" gear.

> And, while not the only (or
> even main) consideration, legacy interop has significant value. It would
> be a shame to destroy that value based on a misconception.

The API we proposed can, and already has, achieved a greater level of legacy interop, simply by telling the browser what to do from the JavaScript app, and then in the same JavaScript app creating information that can be sent by the server to the legacy equipment in whatever way is compatible. Great thing about that is that when we find bugs with the legacy gear, we just change a little server code or JavaScript code that gets sent down from the server,... rather than hoping that some day the browser vendor will show up with an SDP tweak that fixes the issue.

> 
> These issues aren't hard because of SDP. These issues are hard because
> they're hard.

But 80% of the "how do I represent this for others" doesn't need to be solved before the spec is final with a spec like ours. When the spec says "SDP comes out this hole here and goes in that hole there", it does... and 100% done, too, otherwise browser vendors are going to be forced to object to that spec.

Matthew Kaufman

Received on Friday, 19 July 2013 18:25:50 UTC