Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing

[Tim Panton <[e-mail]>]

On 18 Oct 2011, at 12:43, Harald Alvestrand wrote:

> (Apologies for the length of this note - but I wanted to follow this argument a bit deeply)
> 
> In the discussions about RTCWEB signalling, I’ve had a change of heart.
> Or perhaps it’s just a change of terminology.
> 
> The high bit is this:
> I believe we need to standardize a negotiation protocol as part of RTCWEB.
> This needs to be described as a protocol, and cannot usefully be described as an API.
> 
> This note is to explain to my fellow WG members what led me to this conclusion, and - in some detail - what I think the words in the above paragraph mean.
> Those who don't want to read a long message can stop here.
> ----------------------------------------------------------------------------
> 
> The context of RTCWEB is the well known trapezoid:
> 
> +-----------+ +-----------+
> | Web | | Web |
> | | Signalling | |
> | |-------------| |
> | Server | path | Server |
> | | | |
> +-----------+ +-----------+
> / \
> / \ Proprietary over
> / \ HTTP/Websockets
> / \
> / Proprietary over \
> / HTTP/Websockets \
> / \
> +-----------+ +-----------+
> |JS/HTML/CSS| |JS/HTML/CSS|
> +-----------+ +-----------+
> +-----------+ +-----------+
> | | | |
> | | | |
> | Browser | ------------------------- | Browser |
> | | Media path | |
> | | | |
> +-----------+ +-----------+
> 
> or even the triangle, where the triangle is formed when the two Web severs on top are collapsed into one.
> 
> A design criterion for RTCWEB has been that it should be possible to write applications on top of RTCWEB simply - that is, without deep knowledge about the world of codecs, RTP sessions and the like.
> Another design criterion is that interworking should be possible - which means that SOMEWHERE in the system, deep knowledge about the world of codecs, RTP sessions and the like must be embedded; we can’t just simplify our options until everything’s simple.

I've generally found that "simplify our options until everything’s simple" is a very good policy for Version one of anything. 
But instead we have a complex set of PSTN-interop centric requirements, it is no surprise that we will come up with a complex PSTN centric solution.

Sadly this will be such a straight-jacket that no other new uses will flourish.

> 
> There’s one place in the ecosystem where this knowledge HAS to be - and that is within the browser, the component that takes care of implementing the codecs, the RTP sessions and the related features. If we can avoid requiring embedding it twice, that’s a feature.

Actually it isn't a universally desired feature. The web is full of multiple ways of manipulating the same object.
an HTML table can be specified in HTML, manipulated in a DOM via javascript, and styled in CSS . 
The writer of each of those bits of code needs to understand what a table is or does at least partially.

> 
> It used to be that I was a believer in APIs - that we should make the API the “king”, and describe the way you generate an RTP session as “you turn this knob, and get this effect”.
> After looking at the problem of Web applications that don’t have domain knowledge for a while, I’ve concluded that this doesn’t work. There’s the need for one browser to communicate with the other browser, and if the intermediate components are to have the ability to ignore the details, what’s communicated has to be treated like a blob - something passed out of one browser’s API and into another browser’s API, unchanged by the application - because the application must be able to ignore the details.

Extend that argument a bit further - the codecs  at each end can agree about their mutual compatibility very simply - without involving the rest of
the stack. All they have to do is expose a method on the decoder that can check the self-description sent by the encoder.

Instead we are making a monolithic codec/network/negotiation/(signalling soon) hunk of code instead of splitting out the parts and (for 
example ) exposing the codecs as objects with behaviours.

> 
> OK, now we have the API with blobs. We also have to make some assumptions about how those blobs are transported, who’s responsible for acting on them, and so on. And we have to make sure different browsers implement the blob the same way - that is, it has to be standardized.
> What’s more - we DO want to enable applications that are NOT simple. Including gateways, which are not browsers. So applications must be free to look inside the blob - break the blob boundary - when they need to. So this pulls in the same direction as the need for interoperability - the format, semantics and handling rules for these blobs has to be specified. In some detail.

We have an API with blobs only because we chose to stick with the ugliness that is SDP. Once you take that decision, the rest follows.

> 
> So we have:
> - a data format
> - a transmission path
> - a set of handling rules, in the form of states, processes and timers
> 
> This doesn’t look like an API any more. This looks like a protocol. We’ve got experience in describing protocols - but it becomes much easier to apply that experience when we call it a protocol.


Ok, lets design a protocol (if we must), but let's base it on the real capabilities of browsers, web coders abilities and the real needs of web users, 
not constantly looking over our shoulders at a legacy protocol that barely works in the environment it was designed for.

And will this new protocol have a standard API ?
> 

Tim.