Microsoft’s Entrance to WebRTC: Speed Bumps Ahead?

At the beginning of August, Microsoft finally made its position public in the ongoing and increasingly popular topic of WebRTC/RTCWeb, and the projects aiming to standardize real-time communications (RTC) in web browsers. Instead of dipping their toes in, Microsoft is making big waves with an alternate proposal. 

Just as Justin Uberti of Google noted in his Google I/O 2012 presentation, “Real Time Communications, moving at web speed,” has been the promise of WebRTC, but did Redmond’s entrance shift it into high gear or toss a stick into the spokes?

The WebRTC and RTCWeb standards efforts have been in the works for some time now. With Google’s early WebRTC implementation already delivered into their Chrome Canary and Chrome Beta browser, making next-generation, real-time applications is a hot topic in both the web and communications industries. Acme Packet actively participates and contributes to WebRTC and has been matching Chrome’s early implementation with interoperable support within our session delivery network products. 

The term WebRTC refers to the standards work currently being done within the W3C, which develops standards for browser and web technologies (HTML5, CSS, etc.). The W3C has been hard at work standardizing the technology from a browser perspective and defining the standard APIs that web developers will have to leverage WebRTC in their applications. At the same time, the Internet Engineering Task Force (IETF) has been driving their own standards effort, called RTCWeb, with complimentary goals as the W3C. IETF has been focusing on the protocols and tools that the technology will use “on the wire,” such as SRTP, STUN/ICE/TURN, and codecs.

Web developers and communications technology companies have gobbled up the early implementations and already many very impressive demos and applications are being built. With Google leading the charge of major browser manufacturers with WebRTC support, Firefox and Opera have already implemented some components of WebRTC and have committed to full support within the next year. Until now, Microsoft and Apple have remained somewhat silent on WebRTC.

When Microsoft broke the silence, they (in principle) pledged their support for the ideals of WebRTC, but developed a brand new approach: CU-RTC-Web (Customizable, Ubiquitous, Real Time Communication over the Web). While this new approach proposes no significant changes to the ongoing IETF RTCWeb efforts, CU-RTC-Web goes directly against the current W3C WebRTC standards work, as an all-new proposal.

So, what is CU-RTC-Web all about?

In short, Microsoft is proposing that the existing APIs exposed by WebRTC are too limited, and that there needs to be greater flexibilities and liberties given over to the Web developer. If you imagine the gauge between dead simple, yet restrictive vs. complex, but with more options and power…CU-RTC-Web definitely moves the needle a bit more towards the complex. Probably the most notable changes they propose center around a “mid-level” API to the RTC media engines vs. the currently defined “high-level” API.

The current WebRTC APIs are wonderfully simple, and many may argue that simplicity is WebRTC’s strength. Most would agree that the barrier-to-entry for the current WebRTC APIs is so low, even a novice web application developer can take hold of them and, having no knowledge or understanding of the complexities of RTC, add a video or voice call to their app in no time. That said, the current WebRTC APIs give an application very little control, or information about a RTC session once it is established.

CU-RTC-Web aims to offer a JavaScript application with better visibility into the performance of the RTC session and mid-session control options. It gives the application a fine set of functions and callbacks to and from the media engine in the browser. These functions allow the application to be aware of details relating to the quality of the session and adjust some of the more technical details relating to the various RTC protocols used (i.e. STUN/ICE/TURN, RTP/RTCP). Of course, the cost of this greater power is that it requires significantly more JavaScript to wield CU-RTC-Web and much more knowledge of the underlying RTC protocols and tools.

Now, what are Microsoft’s motivations for CU-RTC-Web?

Most speculators agree that the obvious possibility is to support Skype in the browser. The co-authors of CU-RTC-Web are a veritable “all-star team” in the world of VoIP, including principle architects on Skype and Lync, and none other than one of the core contributors to SIP and the SDP offer/answer model…Jonathan Rosenberg. Microsoft’s acquisition of Skype, and the growing popularity of their Microsoft Lync unified communications software, certainly brings them “heavy-hitter” status in the world of RTC. The native Skype application today utilizes some pretty slick algorithms for adjusting and tweaking media parameters, such as codec and bitrate, to adjust to good, bad, and even changing network conditions. Thanks to these capabilities and the years of tweaking and tuning of their application, Skype has become quite robust and usable in almost any network environment. Using WebRTC in its current form for a Skype application within the browser, or perhaps a browser-to-Skype client call, would likely mean limitations in the applications abilities to perform like it currently does.

So, what will the impact of CU-RTC-Web be on the goal of ubiquitous real-time communications on the Web?

It’s hard to say at this point. Both approaches have their merits and perhaps further work in the standards bodies will yield some middle ground. However, one probable impact may be a slowdown in the speed at which these RTC capabilities will reach widespread consensus and adoption. As WebRTC and CU-RTC-Web are debated over the coming months, it’s possible that Microsoft may have just touched off somewhat of a VHS vs. Betamax or Blue Ray vs. HD DVD standards war. Given the way WebRTC has been accelerating, and seeing that application developers, and communications companies, such as Acme Packet are already building and preparing for WebRTC, I for one, hope this is just a minor speed bump that is quickly cleared, and we don’t have to wait too long for the W3C, Microsoft, Google, and the other browser manufacturers to sort this out.

Biography: Reid Stidolph is a Senior Systems and Sales Engineer at Acme Packet, where he works on aligning technology with Mobile Network Operators (MNOs) and Multi System Operators (MSOs) in North America.  He specializes in VoIP and Data architectures and technologies such as IP Multimedia Subsystem (IMS) and Evolved Packet Core (EPC). Reid also has a focus on web technologies, and their interactions with communications networks. He studied Electrical Engineering at the University of Wyoming, and has over 12 years’ experience in networking and telecommunications. In addition to his current role at Acme Packet, Reid's professional career includes experience with rural wireline Local Exchange Carriers (LEC), nationwide VoIP and Broadband carriers, and wireless network operators. 

Seamus Hourihan, senior vice president of corporate strategy at Acme Packet, will be discussing the future of WebRTC at the 2012 WebRTC Conference in Paris, France.  

Session: How WebRTC could Revolutionize IP Communications
Thursday, October 11, 9:30-10:00 a.m.

Session: What are Telcos Specific Needs?
Thursday, October 11, 2:00-2:30 p.m.

Acme Packet's Rhys Arkins, director of technical sales, will also be discussing WebRTC in his session, "The Changing Landscape of Service Delivery," on Tuesday, October 16 at ITU Telecom World 2012.