Topic of the month covered by WebRTC “activists”
Before going into the topic I would like to welcome Andrew Hutton, Co-Chair of the IMTC WebRTC activity group and Head of Standardization at Unify. I know Andy for many years and it is a great pleasure having him join the Topic of the Month posts. You can reach Andy on Twitter: @huttonandy.
To the topic of this month
WebRTC Standards are being worked on at the IETF and W3C. Learning from the history of the SIP standard, we see that implementations by vendors are in many cases diverted from the pure standard to proprietary versions of SIP thus requiring mediation between vendor environments. Additionally, we experience rather slow progress of standards such as RCS. On the other hand, we do want to see WebRTC systems working with one another and more importantly, browsers being able to support any WebRTC client and enjoy the browser to browser interoperability.
For this month the topic is: Which areas of WebRTC should be covered by the standards and which areas should be left for the vendors to decide on? What level of interoperability and compatibility do we want to have?
Starting with my opinion on this topic.
I typically use Chrome for browsing but there are cases where I browser to a website and am requested to switch to Safari or IE. Not a fun experience.
This is what we don’t want to see with WebRTC based services. We want cross browser and mobile compatibility. Problem is that we can’t control what the vendors are doing but the more restrictive the standards will be, less chances vendors will comply.
With this in mind, WebRTC Standards should define the minimal must. It should cover only the areas required for enabling exchange of media between 2 browsers.
Currently, in most cases, this is what the standards bodies are doing. Signaling was left out of standards and most of the work is around media and security. As the basic things in WebRTC are pretty much well define, standard is also starting to touch small details that sometime dive into implementation related things and that is where I hope it will stop.
Learning from the lesson of SIP, over complicating and over standardizing results in incompatibility and proprietary forks from the standard.
It is also important to note that WebRTC is massively deployed already although WebRTC 1.0 is not sealed and closed yet. Vendors are working side by side with the standards and those that are not are making the mistake service providers have made waiting for RCS to be standardized. WebRTC standards ratification shouldn’t hold up vendors from launching services and adapting them down the road as standards evolve.
Link: Standards Play
The most effective standards, and the most effective progress in standards, come from standardizing where there is agreement. This may sound like a trivial answer, but it isn’t. Standards only have value when multiple parties (ideally many) care, so ultimately it is best to focus first on those items that more people/organizations care about. All groups that succeed ultimately end up doing this, whether by design or by fate. Gradually, the remaining items for discussion matter to fewer and fewer parties, until you reach a point where those who want the work to finish greatly outnumber those who care about the remaining items. Then the work ends until there are enough people left to start up something new.
In the case of WebRTC, as I stated in a recent WebRTCStandards post, we have recently quit arguing over major topics, instead making rapid progress on many smaller items. This is a sign that the work is ready to finish, although finishing the details can/will still take significant time. For those concerned about items such as DTMF timings, have no fear that those items are inordinately delaying the completion of the WebRTC 1.0 spec, because *they are not*. Discussion about such items, along with the other 37 remaining issues (at current count) and others that will no doubt arise, is part of the normal process of completing a standard, boring though it may be for onlookers. We had well over 100 outstanding issues a year ago, many of them major . . .
So, the summary here is that declaring a boundary for standards by fiat is ineffective at best. The vendors will decide on anything left after the standards bodies run out of steam. If, after WebRTC v1.0, there are enough parties who want something else standardized, then there will be a next version.
Link: Linkedin Profile
WebRTC was born within the standardization community due to a desire to move the real-time communications industry to a model that allows web speed innovation. To achieve this we realized from the start that it was necessary to limit what was standardized and therefore famously the IETF decided not to standardize the signaling plane of WebRTC, this has been proven to be the correct decision. Certainly WebRTC standardization has moved far beyond the level of a minimum viable product (MVP) but this was I believe necessary to get real-time voice, video, and data to work well over the open internet. The level of innovation we have seen from the WebRTC community has proven that the standardization strategy for WebRTC has been successful.
Want to joint Topic of the Month as contributor?
Rules of engagement for Topic of the Month: No product/company promotion. Contributors should have a wide market perspective.
If you would like to join this initiative and have your opinion published here in future posts please drop me a note.
Leave a Reply