The Microsoft in the Room – IE and WebRTC (or ORTC?)

As WebRTC has matured to a state where it’s first implementations are ready for companies to launch real services around it, the readiness of various companies to adopt WebRTC has fanned out quite a bit. Some are already charging ahead as early adopters, while others are playing it conservative. Of those in the conservative camp, one of the common doubts that gives them pause is: “What about IE?”

When speaking to those interested in WebRTC, but concerned about Internet Explorer (IE), many times we’ve tried to assure them not to worry: our friends in Redmond won’t be too far behind. We often point to the undeniably significant contributions from Microsoft to WebRTC, especially considering that they bring to the table two titans of VoIP industry (Lync and Skype). We highlight some of their early IE WebRTC demos (using beta code) as signs of progress. We’ve rationalized the absence of  a Microsoft equivalent to what Chrome and Firefox are shipping, by noting the slower release cycle for IE. However, we’ve come to realize that to some, IE support is a really big deal.

Even though the Firefox and Chrome browser share has ballooned to a combined ~%60 overall (depending on which source you believe), there are certain classes of companies and industry segments where IE usage is much greater. This can be due to things like user demographic, or IT policies for end user devices. No matter how you spin it, to some, the promise of ubiquitous web based real-time communications nowhere close to a reality, until Microsoft climbs aboard. For those waiting, news last week from Microsoft would suggest that you won’t have to wait much longer for IE to catch up to the rest.

What’s the news?

Announced through Microsoft’s Skype blog, a number of juicy details surrounding their WebRTC plans were revealed:  http://blogs.skype.com/2014/10/27/bringing-interoperable-real-time-communications-to-the-web/

At a high level, this news reflects Microsoft’s deep commitment to RTC on the web, and lays out their plans for the near future. This all sounds good, right? As is so often the case, the devil is in the details.

What does this mean?

Looking just beneath the surface of Microsoft’s plans here, a few details stand out as potentially having significant implications:

• The API in IE: Imminent plans to deliver ORTC (or WebRTC 1.1 as ORTC supporters call it), in IE…but not WebRTC 1.0
• The Codecs: H.264 for video & Opus, G.711, G.722 for audio. VP8 is not part of the deal
• Microsoft’s interests outside the web: The importance of interoperability with “billions of existing communications endpoints”

The API in IE

Microsoft’s intentions are further clarified on their IE Web Platform Status app: https://status.modern.ie/webrtcobjectrtcapi?term=webrtc

It would seem that IE intends to skip implementation of the current form of WebRTC (aka WebRTC v1.0), and jump right to ORTC. Supporters of ORTC have proclaimed it “WebRTC 1.1”, which could provoke some debate. Declaring your own plans to be the industry’s “v1.1”, while the industry as a whole has not yet finalized consensus on exactly what “v1.0” is, could certainly be seen as premature. At the same time, it would be accurate to point out that some of the concepts and mechanics of ORTC are gaining support and popularity, to the point that are being adopted by the standard “v1.0” specification, and players like Google are adding support for it in their implementations.

Call it what you will, you may recall our previous post, which points out that ORTC is backwards compatible with WebRTC, and the differences lie mostly in the browser API and signaling framework. The intention is that much of the on-the-wire protocols (STUN/ICE/TURN, DTLS-SRTP, Media stream bundling, etc.) would be the same.

While a “world wide web” without completely homogeneous browser API implementations sounds like it would be bad, it is certainly much closer to the reality we see today. Through the W3C, HTML5 aspires to deliver a state of nirvana for web developers, in which they have to write code once, and it works on all different browsers exactly the same. However, browser capability detection and handling is common practice on the web, due to the realities of browser makers in differing stages of implementation and/or interpretation of HTML5. While everyone agrees that WebRTC should strive to have all implementations be as close the same as possible…if you take pragmatic look at a world in which Microsoft does not implement WebRTC 1.0 and goes right to a backwards-compatible ORTC, it may not be so bad. Certainly it would be much worse if IE elected to use completely different on-the wire protocols, as this would certainly defeat interoperability entirely. Now with RTC on the web, as with other browser based capabilities, the work of interoperability will fall to the JavaScript developers to sort things out. Most WebRTC JS libraries already do detection for varying WebRTC implementations today. With IE ORTC on the scene, it is likely that JS libraries will evolve to detect, leverage, and normalize to their API surface, making today’s WebRTC apps operate with little modification.

One caveat here, is that the previously mentioned points about being on-the-wire compatible with other implementations of WebRTC is not entirely true (yet). This is because of one one major yet-to-be-determined item for the IETF: what video codecs shall be used. So…what does Microsoft say about the codecs?

With IE ORTC on the scene, it is likely that JS libraries will evolve to detect, leverage, and normalize to their API surface, making today’s WebRTC apps operate with little modification.

The Codecs

While the news of an upcoming IE implementation is mostly positive, the announcement could also be seen as a thinly veiled attempt to show momentum on one side of a video codec debate, that has been on the back-burner for a while. They clearly state their plans with regard to the codecs they intent to implement:  Opus, G.711, G.722 for audio and H.264 for video. No VP8.

Audio

When it comes to audio codecs, the WebRTC specification indicates both Opus and G.711 as the Mandatory-to-Implement (MTI) audio codecs for any WebRTC-complaint implementation. However, the IETF has recently adopted a document that recommends other voice codecs to interoperate with legacy networks, which includes G.722 among others.

Video

This creates a rather large rift in RTC on the web, as Chrome browsers and IE browsers will have no common codec with which to share a video call. That said, some WebRTC community members are willing to take some progress vs. no progress, saying, “even though Microsoft’s announcement is about ORTC and H.264,  it is better than nothing. At least it will provide audio and hopefully datachannels with no plugins in IE, plus video support interoperable with a large percentage of the market. One can always deploy a transcoding solution as a fallback“. I’m sure transcoding vendors will be very happy with this sentiment.

As highlighted in previous posts, the last time the video codec topic was discussed at the IETF it was not possible to reach a consensus. The decision at that time was to put the topic on-hold, to spend the cycles working on other topics in order to progress with the standardization effort. So now, after several months, the can of worms has been re-opened. Next week there will be a new IETF meeting in Honolulu, and the Video Codec topic is part of the agenda for the RTCWeb WG. It’s worth noting that within the IETF there are some voices, mostly from VP8 supporters, claiming it does not make much sense to re-discuss this now, as nothing has changed substantially since last time it was discussed (note VP8 is currently under consideration to become an international standard, but it will take some time).

• On October 2, Ericsson announced the OpenWebRTC project (along with it’s browser Bowser), stating they support not only VP8, but also H.264 using Cisco’s OpenH264.

  

• On October 14, Cisco announced OpenH264 is used in Ericsson’s OpenWebRTC and Mozilla’s Firefox (note Firefox does not support H.264 unless one installs Cisco’s plugin).

  

• On October 27, Microsoft announced plans to support WebRTC, well in fact it was about supporting the ORTC API and H.264 video codec

  

• Cisco published few days ago a draft on VP8 litigation status but Google has already responded saying the document is missing information about a couple of on-going invalidity actions. By the way, the current AVC/H.264 Patent List and Patent holders according to MPEGLA can be found here.

Oh, and in case you missed it, Mozilla has recently announced a partnership with the GSMA (a group of nearly 800 mobile service operators in 220 countries) in order to “bring relevance to the Web for potential users, and open up possibilities for revenue growth for operators who have seen declines in returns from traditional revenue streams like voice and messaging services“.

It would appear is if many are gearing up for a battle royal, as the endless codec debate heats up next week in Hawaii.

Microsoft’s interests outside the web

No matter how you interpret Microsoft’s motivations for their choice in codecs, it is clear that a focus on the interoperability with RTC far beyond the World Wide Web is a driver for them. With substantial deployments of VoIP outside the web (e.g. Skype, Lync), it is obvious why this is a big deal to Microsoft, and everyone that uses their services. They surely know a thing or two about producing a high quality RTC offering.

You could say that of those making browsers, other than Microsoft, there is not much at stake for the rest beyond RTC on the web. Google may be the only other entity besides Microsoft with some real pre-WebRTC RTC (Google Talk, Hangouts). However, they have had the luxury of being in the driver’s seat for most of the early days of WebRTC. As a result, much of WebRTC in it’s current form is almost an evolution of what Google was already doing with Google Talk and Hangouts, and naturally interoperable with everything else in the Google/libjingle bubble. So for Google, and many others riding the Google platform coattails, WebRTC can exist on an island, and that is ok for them. (BTW, speaking of the Google platform, Android L’s WebView now supports WebRTC. So as Tim Panton mentioned: “building WebRTC apps on Android just got easy”.)

However, for Microsoft and others, there is much at stake beyond just web. There is plenty to indicate that working with RTC outside the web (including “legacy”) is important for them, and we’re not just talking about their position on codecs. Almost certainly their adoption of more powerful ORTC browser API, alludes to many of the more advanced use cases that may stem from their rich history in RTC. Surely they want to be empowered to bring their experience and lessons learned to the web as well.

Whether Microsoft’s announcement makes you roll your eyes at the thought of more codec debate, or cheer at the possibility of WebRTC coming to Internet Explorer, the news serves to demonstrate Microsoft’s ongoing commitment and efforts toward Real-Time Communication on the Web.

Next week, Victor will be discussing this and some other topics at the 1st WebRTC Stockholm meetup. Our friends from the OpenWebRTC project will also join us in this free event. If you happen to be around make sure to register soon as we have already 95 confirmed participants and only 15 spots left.

{“authors”: [“reid“, “victor“]}