Open letter to the WebRTC Committees

Dear WebRTC standardization committees,

I work for a company that provides middleware, allowing developers to easily implement video conferencing across all major platforms. For web apps we're currently using our own NPAPI/ActiveX plugin to do all the heavy lifting.. But we're closely watching the WebRTC movement. It's a great opportunity for us to provide an excellent user experience without the need to install any native software.

Until now, we've been monitoring the movement rather passively, but the recent announcement of the CU-RTC-Web proposal led me to express some concerns that IMHO are common to the developer community.

Comments on Option 1

The main reason why I've been always passively following the API proposals was the simple assumption that we can deal with any API as long as the use cases defined in the initial IETF draft will be covered. Whether it's PeerConnection00, DeprecatedPeerConnection, or battery of interfaces proposed by CU-RTC-Web, it's really not a major issue. Once the API is available, we'll be able to implement it in our libraries easily.

That said, the PeerConnection API brings a bit too narrow semantics, focusing mostly on P2P communication (we're more conference oriented) and thus would require some nasty hacks, but it's not a big deal, we can live with it.

Also, I think that voters for Option 1 in the poll are exaggerating with the statement that the API's ease of use is more important than its power. In my opinion, once you'll give developers those capabilities there will be tons of libraries like jQuery, Prototype or Mootools that will simplify life of the community enough. I really don't see a problem with building the PeerConnection API on top of the CU-RTC-Web. This will give developers more choice and features, and the best community driven libraries will quickly surface.

The only meaningful difference from having it implemented in the browser is that it will be easier for the community to maintain such a library. This will be more efficient than waiting for browser vendors to meet and agree on how to update an API in order to provide a new feature or fix.

Comments on Option 2

You may think that if I could participate in the recent poll, I'd vote for the CU-RTC-Web, but actually it's not the case. While I definitely think that a more powerful API is better, the MS proposal is simply too late for such a radical change. Why such a pool wasn't created before the PeerConnection00 was introduced in Chrome canary builds? Why was the CU-RTC-Web proposal so late? I can remember that there were negotiations at some stage, but I can't understand why MS didn't propose their views months ago.

What really matters to developers, at least IMHO

Ultimately the cross browser interoperability is the most important factor here. Things like the API definition can make only our job slightly more or less difficult, but it won't affect the job's feasibility.

For us, the worst outcome that could come from the WebRTC movement is a situation where the browsers cannot communicate between each other. Sure, we can smooth the differences using MCUs or other bridges, but we need be aware of an impact such an approach has to an ability to scale a service up. This problem is amplified by the general trend for NPAPI/ActiveX native browser plug-ins being disallowed, because "nowadays you can do everything in DOM".

I'm pretty sure that there won't be significant problems with having consensus on the networking stack, but I'm not so confident with regards to the media codecs used. We've seen this previously, when the <audio> and <video> tags were standardized. The difference is that with HTML media tags it is still feasible to serve different static content depending on the browser used by the client. It is not convenient, but it still is feasible. On the other hand, with the WebRTC if different codecs are being employed by different browsers this whole facility will be simply useless.

Assuming large problems with getting consent here, I'd like to ask you to consider adding to the standard an ability to extend the browser capabilities by native components acting as codecs and packetizers. With NPAPI extinct I actually don't see any other option to free developers from the browser vendor lock-in problem.

Summing up

WebRTC seems to be in a great place now that 4 out of the 5 major browser vendors are at the table. All we need is some kind of consensus, which we are not sure a poll will provide. Consensus is more important, at least IMHO, than whether Option 1, Option 2 or any combination of them is chosen.

To summarize, I've got few requests to the standards committees and browsers vendors working on WebRTC:

1.    Please agree on having the same WebRTC API, so it will be easier for us to use the technology.
2.    If that's impossible, please at least ensure that you'll be using the same networking stack and make the features detection simple and legit.
3.    Please agree on having same, baseline codecs so the media streams do not have to be transcoded on the server side.
4.   If that's impossible, please introduce to the standard an extension API, allowing 3rd party developers to install and register their own codecs/packetizers.


--
Ted Kozak
Phone No:  +48509942825<tel:%2B48509942825>
e-mail: ted@cloudeo.tv<mailto:ted@cloudeo.tv>
http://www.cloudeo.tv<http://www.cloudeo.tv/>