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

On Fri, Jul 19, 2013 at 9:37 AM, Adam Roach <adam@nostrum.com> wrote:

> 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.
>

It's interesting that most or your list of things that needed to be solved
without SDP (simulcast, FEC, correlation of RTP streams with
MediaStreamTracks, glare) still haven't been solved for WebRTC even with
SDP, despite many months (years?) of effort.

I don't think anyone is saying "without SDP, there would be issues".  I
think they're saying "without SDP, the issues are much easier/faster to
solve, and the API would be much more usable and implementable".   And I
don't think that's a naive opinion.




>
> 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


I think you are conflating signalling with API surface.  If we focus on
making a good API rather than on signalling, we can make something much
more simple and leave signalling up to the application.


> 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.


Again, you are conflating API surface and signalling.  An API that doesn't
have SDP in it doesn't preclude web apps from using SDP for signalling.
 There's no loss here for those app that choose to use SDP.  There is only
gain for web developers chooses not to use SDP for the signalling in their
web application.  And if they choose not to use SDP and use JSON instead,
why are you so opposed?  There is a world outside of legacy interop, you
know.




>
>



> 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.
>

You are underestimating how painful it is to deal with the current API,
both because you are very familiar with it (with many years of experience)
and because the use cases you care about are the ones the API was defined
for (legacy interop).  But as soon as you ask someone who is not familiar
with SDP (a lot of web devleopers), or someone who is doing more advanced
or different things than what you have thought of, they will give you a
different answer.   They feel pain, and it is because of the poor API
surface.



>
> 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.
>

Please try to consider what you sound like to a web developer who is trying
to use WebRTC and finding SDP to be difficult API surface.  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?


>
> 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.
>

There is a vast difference that you are not taking into account.  The SDP
O/A, if in JS, is a complexity cost only paid by those web applications
that need it.  But if baked into the API, every app must pay the cost of
the complexity.

In general, this emails seems to be arguing that  SDP is the optimal API
surface for expressing all these complex things, and  yet in other
occasions, I've heard you admit it's a terrible API surface.  So does that
mean the optimal API surface is terrible?  I don't think so.  It will be
work, but I think the work will be worth it in the end.

That said, the chairs have asked us to delay discussing a better API, so
we'll have to wait before we can discuss details of how an API could be
done without SDP.


>
> /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".
>
>