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

[Adam Roach <[e-mail]>]

On 7/19/13 10:03, Iñaki Baz Castillo wrote:
> All these "smaller details" are in fact issues and problems we don't
> need. Issues not needed at all in WebRTC, issues that WebRTC
> developers and vendors should NOT care about. If those "smaller
> details" do exist is due the mandate of SDP. And all the time the WG
> (or WGs) will spent "fixing/defining" them is just wasted time, since
> nothing useful is being done for WebRTC by "defining" those "minor
> details".
>

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.

I understand the temptation to think that starting over makes all the 
problems go away. There's a mental trap in thinking that all you really 
need is to announce ports and codecs and get on with it. But then this 
person over here really needs simulcast. And that person over there 
insists that RTCP NACK feedback is critical for his application. And 
then I need to be able to tell you that your 1280x720 video stream is 
going to overwhelm my limited ability to decode and that you really need 
to turn it down to QCIF. And, before you know it, you've reinvented 
something approximately as complex as SDP that everyone is just going to 
shove into a JSON blob and send across the wire. As an added bonus, by 
deciding that legacy interop is of no value, you've limited the utility 
of the overall system by setting Metcalfe's law on fire and throwing it 
over the railing of the third-floor balcony.

Your pain point isn't SDP syntax. Yeah, it's ugly, but it's not hard. 
Your pain point isn't offer/answer. 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.

No, your pain point here is that non-master-slave networked 
communications are not easy to get right, and it is the height of hubris 
to think that you inherently know better than everyone else who has 
worked in this space before you. Consider that TCP has far fewer moving 
parts than even a simple one-stream-audio-only call setup and took 85 
pages to specify.

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.

/a

____
[1] What we call "glare" in telecom and SIP, but a phenomenon that 
arises whenever you have connections made between peers without a 
master/slave arrangement; see RFC 793, page 32, for example.

[2] For the uninitiated, "comment 22" was a shorthand developed at last 
year's TPAC for the sentiment "SDP offer/answer is hard".