Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

Is WebRTC exclusively targeting browser interoperability ? I'm not 
trying to nitpick, but this is a vital point of issue.

If yes, then why do we need to carry so much legacy SDP stuff to achieve 
basic sending of media between browsers? Seems like an incredible 
designoverkill to me. It's much easier to define a minimal feature set 
with a wire protocol that can achieve basic media between browsers. You 
could define "SDP-light" and that would be sufficient.

If no, then why isn't JavaScript the entity generating the SDPs rather 
than the browser binaries?

If the browsers aren't the end-all-be-all for interoperability, then all 
those SDPs have work not just between browsers, but untold numbers of 
SIP devices, servers, gateways, relays, desktop applications and mobile 
devices. Either all of those devices have to become equally capable of 
handling every WebRTC SDP produced from every browser, every version, 
working around every format difference, as every other device on the 
planet -- or -- we'll have to extract the SDP information using JS 
libraries and signal a format strictly compatible to our network 
environment. Personally, I think most will choose the latter in 
practice. Even SIP people using SDP will end up extracting the browser's 
SDP and recreate their own SDP instead.

Given how tough it is for two browser vendors (who even have access to 
each other's source code) to get this SDP negotiation right, I'm 
extremely concerned about an entire planet of devices getting this stuff 
right.

The trouble isn't that SDP isn't expressive enough or it's too ugly a 
format, it's that it's too expressive (okay, and it's ugly too). The 
trouble isn't that it's easy to negotiate O/A only for simple cases, 
it's that when we end up having to signal this stuff in "our own way", 
we'll be fighting with an O/A state negotiation machine instead of 
controlling the RTP engine directly with knobs and dials.

As a developer, I want:
1) to control what the RTP engine does on the wire (to ensure 
compatibility between devices);
2) strict, well defined, easy-to-understand API contracts that do not 
change, and are only extended in well defined ways;
3) knobs and dials to control the exposed capabilities, and _not_ a 
negotiation machine to not fight where I can only indirectly "do what I 
want";
4) predictable outputs, i.e. not having random extensions or odd 
differences in the middle some blob format show up from 
version-to-version, and from browser-to-browser;


I do not believe we can address these by tweaking the SDP format, or 
defining SDP better, or making wrappers for SDP.

The problem is fundamentally SDP O/A as the mandated.


-Robin


> Cullen Jennings <mailto:fluffy@iii.ca>
> 19 July, 2013 9:24 PM
>
>
> Well lets prioritize fixing them. Which ones are causing 
> interoperability problems between browsers?