Does WebRTC Standardization Matter?

Markets like open standards, but open standards take time. Last week, Acme Packet hosted the W3C and IETF WebRTC/RTCWeb (Web Real-Time Communications) working group meetings. After sitting through several hours of deliberation on seemingly mundane topics, such as SDP formatting, one might think there will be a very long time until WebRTC is standardized and broadly adopted. It took SIP three years to get from the initial draft submission to standardization in RFC2543. The first commercial SIP phones and services took another couple years after that. The first 3GPP draft with SIP took five years after the protocol was introduced. WebRTC was introduced in May of 2011, does that mean we won’t see real WebRTC services until 2016?

WebRTC as a standard and technology is very different from SIP. SIP started in academia, then made its way into becoming a standard, and eventually was adopted by vendors and service providers. On the other hand, Google introduced WebRTC in a working form, backing it with publically available open source code and intellectual property. This gives WebRTC a significant head start.

SIP was also competing with another standard, H.323, which was already implemented and in use when SIP was being standardized. There were heated debates as to which protocol was better and it took time for SIP to win over VoIP developers and users. WebRTC also has competition – Adobe’s Flash RTMP. However, RTMP is proprietary to Adobe, making it less attractive to large-scale providers that would have to pay royalties. In addition, Adobe and the rest of the industry are already moving toward HTML5 rather than Flash, so a HTML5-based alternative was needed. There are debates as to how some of the mechanisms inside WebRTC should work, but there is no one arguing for use of Flash or another standard instead.

WebRTC also benefits from a limited scope compared to SIP. SIP is a complete real-time communications protocol that includes call signaling. The 3GPP and other groups added considerably to the call signaling portion of SIP, making it suitable for broad use among the world’s thousands of PSTN operations. This signaling can get extremely complex, and as a result there are hundreds of pages of specifications around it. Not surprisingly, standards participates take a long time to come to agreement on these signaling operations. By design, WebRTC does not have these ambitions. Its purpose is to establish RTC sessions between browsers via websites. It does not include call signaling as part of its specification, so developers can use SIP, XMPP, or their own protocol, simplifying the standardization process.

Unlike SIP, WebRTC has a limited number of client issues it has to alleviate. As Tshai Levent-Levi points out in his recent NoJitter article, for WebRTC to work, a handful of browser vendors need to interoperate. With SIP, there are dozens of vendors involved in complex call flows that could potentially span 5-10 different pieces of infrastructure. Getting this level of complexity to work takes a lot of time. WebRTC’s limited scope and focus on the web browser allows it to minimize interoperability issues.

Another major advantage is WebRTC’s user experience – nothing has to change or be physically implemented to make it work. The first SIP phones were physical handsets that had to be shipped to the location where they were being used. Before automation tools arrived, each phone had to be individually configured. If an IT department at an enterprise wanted to implement a new SIP system, a person had to physically put a SIP phone on everyone’s desk. If an enterprise has 1000 employees and each phone takes an average of 20 minutes to install, that’s a full week of work for eight men. Fortunately, modern SIP systems and soft-clients are much improved, but they still typically require some effort by the user to get it set up the first time.

On the other hand, WebRTC does not have physical client constraints. WebRTC relies on the fact that web browsers are already ubiquitous and continuously in use, and therefore reuses the framework that is already there. In addition, browsers like Chrome automatically update themselves, meaning WebRTC support will just show up one day. Others have various mechanisms to push updates to the user, making upgrades relatively seamless. If you use Google’s Chrome browser, then you probably already support WebRTC.

For SIP, the signaling client is the hardest part to configure and update, but with WebRTC, a user can essentially download the SIP soft client whenever they want to make a call. This design allows the website to update and fix bugs in this signaling client – eliminating the need for a technician to upgrade a user’s phone.

So does this mean WebRTC will beat the SIP adoption pace? All the evidence overwhelmingly says yes. In fact, WebRTC has already beat most of SIP’s major milestones.  Google, Mozilla, and Opera are implementing WebRTC ahead of standardization, and there are several WebRTC services (Wello, Plivo, AddLive, Vidtel, Twilio, Bistri, TenHands, and others) already in use. Interoperability has already been demonstrated – first Microsoft demonstrated a CU- RTC-Web in Windows IE to WebRTC in Mac OS X Chrome call, and just last week Google and Mozilla demonstrated a cross-browser video call with Chrome and Firefox. In addition, a 3GPP project to incorporate WebRTC into IMS has been underway for several months. At this pace, standardization of WebRTC may just be a formality, rather than a prerequisite for market development. 

A large contingent of the Acme Packet team and Iwill be at Mobile World Congress in Hall 6 Booth G20 February 25 to 28. Stop by to talk about WebRTC, TSCF, Telco-OTT, and Acme Packet’s other solutions.

Biography: Chad Hart is Director of Product Marketing at Acme Packet. Chad’s focus includes defining and evangelizing solutions for the burgeoning OTT & Telco-OTT market for real-time communications services. Chad also supports service provider solutions, enterprise services, and cloud. Chad’s work at Acme Packet includes business intelligence, product marketing, analyst relations, and pricing. In addition to his current role at Acme Packet, Chad has also held positions as an industry analyst, product marketing, and product management. Follow him on Twitter and learn about Telco-OTT at:@chadwallacehart.