About three years ago, Google announced an exciting new initiative called WebRTC for enabling real-time, multimedia communication using Web protocols. Starting in 2011, the work got chartered in two Internet standards groups. It was agreed that the Worldwide Web Consortium (W3C) would create an Application Program Interface (API) using Javascript and the Internet Engineering Task Force would determine which protocols should be used to support the real-time communication of media. In parallel, Google placed a substantial amount of code into the open source community and began to add WebRTC to its flagship Chrome browser. Very soon, Mozilla announced it would also be supporting WebRTC and began the work to add support for WebRTC in Firefox.
So you might be thinking, “Wow, very cool.” Google and Mozilla will work add WebRTC to the browsers, and contribute the work to the open source community and everybody can play. But Google didn’t simply want to have a proprietary initiative for WebRTC, but presumably wanted it to be widely adopted. To get widespread support of an initiative on the Internet, there need to be standards. So Google began to make submissions to the IETF and the W3C, and the WebRTC standards initiative was born.
I attended one of the early meetings of the WebRTC work in the IETF in Quebec City in the summer of 2011. There was tangible excitement in the air. All of the WebRTC sessions were attracting hundreds of people and representatives were attending from not only from Web companies, but all of the major telecom players. The IETF soon determined that the protocol work needed to be split between two working groups; the RTCWeb working group would work on an overall protocol framework and use cases, and make decisions on which protocols in the overall suite should be mandatory to implement. Several of the protocols being proposed were already under the jurisdiction of the MMUSIC working group – including SDP for media descriptions, ICE for NAT traversal and SRTP for media – so the applicable protocols were delegated to the MMUSIC working group. In the meantime, the W3C efforts began, using its own separate mailing list, and it worked on the API aspects within its user community. This community was very savvy regarding how to extend the Web to do all kinds of new things, such as supporting multiple cameras for video, stereo for music and a separate data channel, which could be used for content that didn’t fit the audio and video codec models being considered in the IETF. Ultimately, the W3C also divided up the API work between its WebRTC working group and a separate task force for a media capture API.
If you have any experience in the world of international standards, the process I just described might have already been setting off alarms bells for you. In order for WebRTC standardization to succeed, multiple working groups in both the IETF and the W3C would have to agree on the major principles and then hammer out all of the details. I’ve recently had the experience of participating on relatively small protocol activities in the IETF for media control and for a SIP header extension called User-to-User information. In both cases, the community of interest was relatively well-defined and there were already working examples of similar protocols in the marketplace. Nonetheless, the Mediactrl working group activity got officially kicked off in 2007 and the last major milestone was delivered in 2013 (yes, six years). The User-to-User SIP Header activity started around 2011 and may be approaching an end this year (three years). By contrast, WebRTC has multiple communities of interest that include Web browser software companies, Web application developers, network equipment manufacturers (both fixed line and mobile) and a variety of service providers. Since there are multiple communities of interest, getting a working consensus to enable standardization becomes much harder.
Let’s consider one example. Google has made investments in audio and video codec technology in recent years and has pushed for inclusion of relatively new video and audio codecs as part of WebRTC. It has even taken steps to minimize the potential royalty burden for developers, which is very important for small application developers who might be developing the bulk of their software using open source and don’t have budgets to pay royalties. Google also argued that these are codecs designed for the Internet, so they are also technically very suitable for WebRTC. However, there is also a great deal of standardization that has taken part in the mobile SIP community to adopt codecs that have commonly been used in initiatives like the IP Multimedia Subsystem (IMS) and the emerging LTE network. Most, if not all, of the medium to large players in telecom generally already have license agreements in place that allow them to use standard codecs such as AMR Narrowband for audio and H.264 for video in their products.
In order to keep the market from becoming too fragmented and to encourage widespread interoperability, the IETF wanted to specify “Mandatory to Implement” (MTI) codecs for both audio and video in WebRTC. But when efforts were made to gain consensus, there was an impasse, since the application developer community wanted the “royalty free” codecs made mandatory and the existing telecom players favored being able to use the codecs with which they’d already had experience. The matter of MTI codecs was resolved for audio at IETF meeting 84 in August 2012, but the decision on a MTI codec for video is scheduled to be taken up again in the November 2013 MMUSIC meeting.
The codec situation is just one example where the different communities of interest have had different ideas about what should be standardized. There have also been long drawn out controversies about whether the SDP Offer Answer protocol was the right choice to manage audio and video for WebRTC. So, is there a solution for this? Is it possible to successfully create standards when there are multiple communities involved with different goals and areas of expertise?
The answer I would give is yes, but it is very hard work. About 15 years ago, both the Internet and fax communities became very interested in creating standards for fax over IP. I was co-chair for the IETF working group on fax (along with David Crocker from the Internet mail community) and there was also strong interest within the International Telecommunications Union (ITU) to move forward with IP fax standardization. We started a mailing list in late 1996 and spent most of the first year just defining a common set of terms so the fax and Internet communities could talk to each other. There were also other hurdles, since the ITU and IETF processes were very different. But the marketplace was making strong demands for fax over IP standards, so eventually agreements were hammered out about where the various elements of standardization would take place and efforts to communicate between the two different communities began to bear fruit. The initial standards for both the IETF and the ITU were agreed by the middle of 1998. More work needed to be done after this to add additional features and take the results of interoperability tests into account, but the two communities now had a working arrangement and steady progress was made.
Is there a lesson here for WebRTC standardization? Perhaps. The communities of interest are more diverse than what we had to deal with for the IP fax case, but agreeing on a common set of terms is absolutely essential and efforts to build bridges of understanding between the different communities can make a huge difference for the better. When I attended an interim meeting in February 2013 – which included about 80 people from both the IETF and the W3C – there were still differences in terminology for concepts such as the meaning of a “track” of audio, but the group present worked hard to make progress.
In the time since, I’ve seen a lot of good faith efforts to resolve the various technical and communications issues and find a way to move forward. As was the case for IP fax, there is a big commercial push to make WebRTC work for a variety of applications, so the motivation to create effective standards is there. So keep a close eye on this space. Making standards is messy work, but there have already been many cases where Internet standards such as SMTP email, HTTP for the Web and HTML5 have had a dramatic positive effect on the everyday lives of consumers and businesses. Time will tell how this will work out in the case of WebRTC.
Want to learn more about the latest in WebRTC? Be sure to attend WebRTC Conference & Expo, Nov. 19-21 in Santa Clara, Calif. Join Cisco and Mozilla for a session, “IETF and W3C Standards Reports,” to hear about the progress of the standards and how they will come to conclusion and release. Stay in touch with everything happening at WebRTC Conference & Expo. Follow us on Twitter.
Edited by
Rachel Ramsey
