Bringing Interoperable Real-Time Communications to the Web

Together with the industry-leading expertise of Skype, we’re excited to announce development has begun on the ORTC API for WebRTC, a key technology to make Real-Time Communications (RTC) on the web a reality. 

We aim to make browser-based calls more convenient by removing the need to download a plugin.  It’s all about convenience – imagine you’ll be able to simply open IE and make a Skype call to friends, family, or get real-time support for that new device right from your browser.


We’ve been actively collaborating with the W3C and IETF to contribute and improve standards like the ORTC API for WebRTC to enable a wide range of features from simple conversations to scalable multiparty video conferences. With the momentum from over 80 participants that represent a variety of browsers, communications experts and start-ups, the W3C ORTC Community Group has issued a “Call for Implementations,” which signals the ORTC specification has reached significant stability. Building on top of the experiences from Skype and Lync and prototyping effort done by the Microsoft OpenTech, we are now working to deliver the ORTC API in Internet Explorer.

The ORTC specification supports the underlying protocols as defined by the IETF RTCWEB Working Group, which enables support for advanced video conferencing technologies such as simulcast and scalable video coding.  We are working with the web community on various fronts to influence how a subset of ORTC objects and methods become part of the WebRTC 1.0 API. This helps to provide a seamless transition from WebRTC 1.0 to a JavaScript object-based real-time communications model based on ORTC (i.e. WebRTC 1.1).

As part of this effort we are committed to innovate and offer better codecs as the technology matures. Our choices here are driven to benefit the broadest set of users – e.g. the primary video codec that is deployed both in communications endpoints and supported in hardware today is ITU-T H.264, which will be the supported video codec. For voice, we will offer codecs like Opus, G.722, and G.711 to enable the greatest experience for a broad variety of endpoints.

Where we are going

This is just the beginning of our implementation effort in IE.  We’re working closely with the web community to improve other existing standards for richer video interoperability, for example, features to adapt to changing bandwidth conditions and more.  In addition, Microsoft’s goal is to move forward to the future without compromising the present – and ensure easier interoperability between web browsers and billions of existing communications endpoints, including SIP-based VoIP endpoints, “Public Switched Telephone Networks” and “Video Teleconferencing” systems.

We will continue leveraging the deep knowledge we have within Skype and Lync, and over a decade worth of customer feedback from the millions of users, across the world.  With the combined assets of Microsoft and our collaboration from the web community and standard bodies, we are committed to building a great RTC experience for the web.  Follow along with our progress on status.modern.IE and let us know what you think on Twitter @IEDevChat.


Shijun Sun

Senior Program Manager, Internet Explorer


Comments (32)

  1. Hugh Isaacs II says:

    This is perfect!

    Please announce support for Service Workers next (in the very least behind a flag or prefixed).

  2. dholcombe says:

    Any plan to support H.265 in the near future in addition to H.264?

  3. Shijun Sun [MSFT] says:


    Thanks for the question!  We will offer other codecs when new technologies mature, including the corresponding communication protocols.  We don’t have any implementation plan yet at this point for H.265.  However, we are certainly paying close attention to it.

  4. Kevin L. says:

    Why not support the existing codecs that Mozilla & Google has spent months/years on that lead to WebRTC being what it is today *in addition to* this truly great effort of encouraging popular codecs such as H.264 also be supported?

    I agree with the user dholcombe to support H.265 along with H.264. It makes little sense to if H.265 is better suited for the video content that'll be needed to satisfy consumers using monitors/televisions with resolutions much large than 1080p (Ultra HD and 4K+).

  5. lirakis says:

    "Interoperable" with no other broswer, since no other browser has implemented ORTC, nor will they.  Basically IE and Microsoft will live in a little isolated world and cause horrible pain for any one who wants to interop with them… just like they always do – jerks.

  6. Kevin L. says:

    Lirakis: That's just not true. Several companies are part of the ORTC group.

    That said, for readers of this article, Microsoft should be more transparent what they felt was wrong w/ Web RTC 1.0 (even links from credible, third-party resources) to ease concerns of their motives for skipping support for WebRTC 1.0.

    I'm concerned Apple (Safari) hasn't been seen on any slides about whether or not they're part of the committee.

  7. Dean Bubley @disruptivedean says:

    This is good to hear. It would be useful to get some more concrete timelines, but I'm guessing that this means mid-to-late 2015 for full availability – at least in terms of my own market forecasts and predictions.

    It is worth noting that Google has already indicated that Chrome will include ORTC, so that definitely appears to be the "direction of travel" for the industry. It's also worth pointing out that there are several plug-in implementations for existing IE browsers that can support WebRTC.

    Dean Bubley

    Disruptive Analysis


  8. Phil Edholm @PEdholm says:

    The disconnects continue, unfortunately.  It seems Microsoft will ONLY support an ORTC based implementation, not the current standard and Google will NOT support H.264, only VP8.  So we end up with verticalized camps all over again.  The value proposition of webifying communications is a strong value for the entire industry.  We need to agree on one committed standards that are widely supported to make it easier for the user communities.

  9. Sri N. says:

    Excellent news! Finally! Hopefully you can provide us with working partial implementations in Beta format at regular intervals rather than make us all wait for a year.

  10. Joel says:

    The major enterprise site I'm working on is finally moving into full blown standards mode (and NON-compatibility mode)

    We were told by Microsoft that requesting "Edge" as our compatibility mode setting (or any of the other Standards Mode settings that this would FORCE IE to render in standards mode and NOT use compatibility mode.

    However we are finding the exact opposite.  If end users have our domain in their compatibility mode list (because we had to use this before) then they will STILL get our application running in compatibility mode EVEN when we force EDGE mode rendering through either the HTTP header or meta tags.

    We can't just get 100's of 1,000's of end users (many under IT group policy that lock this setting down) to remove our domain from their compatibility mode list instantaneously.  How can we force IE to be in "non-compatibility mode" from our code… at least until we can tell them all to remove our domain from their settings?

    We can't just tell them now and wait 2-3 months for all of them to update as the new code for the application won't work until deployed and the old code won't work in non-compatibility mode.

    There has to be a way to force the end user out of the compatibility view list? Right?

  11. Yannick says:

    @Phil – ORTC is a standard too.

  12. Joel says:

    According to this very blog:…/just-the-facts-recap-of-compatibility-view.aspx


    "Site owners are *always* in control of their content. By default, Internet Explorer uses DOCTYPE switching to determine Quirks v. Standards mode (again, Standards mode maps to IE8 Standards by default). Site owners can choose to use the X-UA-Compatible tag to be absolutely declarative about how they’d like their site to display and to map Standards mode pages to IE7 Standards. Use of the X-UA-Compatible tag overrides Compatibility View on the client."

    This appears to be horribly broken – can someone from Microsoft please confirm that there is a way around this?!

    We've had to shelve development (support for IE) until we have a solution to this problem.

  13. @Joel: What, specifically, makes you think that the app is running in Compatibility Mode? Is it the UA string? Or the result of some API?

    (The X-UA-Compatible declaration will impact the document mode, but not the UA string.)

  14. Jokester says:

    Aren't you guys a bit late to the party? (Google Hangouts)

  15. Jeremy says:

    Out of curiosity, why not a compromise on the codecs issue?  Like, you can send whatever you want (example: codec X), but have to be able to decode X, Y and Z?

    Don't get me wrong–I'm not about to look a gift horse in the mouth–but the continued insistence on "one" protocol for video makes it really, really hard for developers, consumers, etc. to provide a coherent experience.  IE will talk to FF (which supports H.264 as a payload), but not Chrome?  That's an extremely difficult failure to illustrate to a user, particularly when a developer has no control over who's showing up on what browser.  It will–more or less–mandate the use of an MCU to do transcoding on the backend.

  16. Nick Galea says:

    We are not interested in Skype or Lync. We are interested in allowing real time, open standards, communications between browsers. This ORTC proprietary stuff means that IE will not be compatible with Chrome. So we have to keep pushing Chrome and FF as the only real open standard browser available.

  17. @nick galea says:

    In other words, you are just interested in Chrome. Typical "open" warrior.

  18. Jana Meiser says:

    This sounds great, IE and Skype together will be very useful for the customer.

  19. Vitor Canova says:

    @Joel @EricLaw [ex-MSFT]

    I had similar problem. I didn't know X-UA-Compatible overrides the user settings. I only realized that after F12 tools implemented that think where it says from where it is loading the Document Mode. So I ended up showing an "Update your browser" for some time.

  20. Dean Bubley @disruptivedean says:

    An important thing to recognise is that WebRTC / ORTC is not just about browser-to-browser or peer-to-peer communications.

    If anything, the needle is switching to mechanisms for implementing WebRTC-type communications inside native apps, especially on mobile, where the browser UI is not ideal for many use-cases that want voice and video as secondary features (eg "speak to the driver" in a taxi app). This is why there is a huge array of cloud platforms emerging, that act as bridges for WebRTC, either inside a specific app, or gatewaying to other systems and services. I'd expect most of these to support ORTC as well as WebRTC, and to do transcoding if necessary as well. That doesn't mean that P2P use-cases will disappear, but they will certainly not be the only game in town.

    This isn't a problem unless you are a staunch "web not apps" believer. For everyone else, this just improves the "democratisation" of voice and video into the web and apps. (Arguably, "appification" of voice and video is more important  than "webification", especially in mobile").

    My take on the announcement (+unanswered questions) –…/microsoft-now-definitely-supporting.html

    Dean Bubley

    Disruptive Analysis

  21. Joel says:

    @EricLaw [ex-MSFT]

    Thanks for answering! – We can see it locally that if the domain is in the compatibility view list that setting the site will render in compatibility mode (when viewed in the dev tools). Likewise removing it from the list locally also shows it to be running in Standards Mode when looking in the dev tools.

    To compare we tried other sites and noticed that the issue is widespread.  If you go to Github and look at their site you'll see the HTML5 doctype (to trigger Standards Mode and the meta tag: <meta http-equiv="X-UA-Compatible" content="IE=edge"> to "attempt" to get the most standards mode (non-compatibility mode) possible.

    By default this works well and a check of the dev tools shows that indeed the site is running in full standards mode.  HOWEVER if you add the github domain to the compatibility view list, then you run in compatibility mode… even though the site is trying to force standards mode.

    Best of all, Github catches this… and shows a huge banner at the top of the site quoting:

    'Please note that GitHub no longer supports Internet Explorer versions 7 or 8.

    We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox.

    If you are using IE 9 or later, make sure you turn off "Compatibility View".'

    See a screenshot here: (this is in IE10 btw)

    So long story short, although we were told in February 2009 that we (the web site/application developers) that we would always be in control of how our content was treated – this doesn't seem true at all.

    We really, really, really want to give our end users a better experience in IE (and all browsers) but a simple update of production code to "force" standards will be thwarted in IE browsers leaving us in a pickle.  Many of our enterprise clients have their browser settings locked down by IT and thus simply "asking" the user to turn it off will be futile and more likely frustrate them endlessly with a SaaS application that doesn't work where the only fix is one they don't have permission to apply.


    What solutions do you propose for this? or is this actually a critical oversight in the compatibility mode list design that needs to be rectified in a patch ASAP?

  22. Tom Winter - MediQuant says:

    @EricLaw and @Joel,

    I get the same behavior on as Joel describes under IE 10. But I looked under F12 when I have github in the compatibility list, and it says document mode is Standards but browser mode is IE10 Compat View. So it is in Standards mode.

    Found this that talks about the difference:…/114267


    Document Mode is what the browser uses to render the page: IE9, IE8, IE7 or Quirks. Browser Mode sets how the browser identifies itself to the web server and to JavaScript.

    End Quote

    So sounds like it's just browser mode here which appears to just change the user agent sent to the server. Perhaps that's what github is checking to see if it should display this banner?

    Also found this guy which seems the definitive answer (until Eric replies 😉…/testing-sites-with-browser-mode-vs-doc-mode.aspx

  23. Tom Winter - MediQuant says:

    @Joel and @EricLaw,

    Found this in the article Joel linked to originally. It seem like it might be key here. If Joel has server-side code that checks the UA String, it's not going to work how he wants if his site is in compatibility mode.


    What this means to developers is that if your site pivots on the User Agent string, adding just the X-UA-Compatible tag (to cause IE8 to display your site in IE7 Standards mode) won’t make your website compatible – you’ll also need to update your User Agent string detection logic as well.

  24. Joel says:

    @Tom Winter – MediQuant

    To clarify, yes in the F12 dev tools I see my site (in IE10) running in "Document Mode: Standards" (in the list on the right) and in (Browser Mode: IE10 Compat View) in the list on the left.

    I can't get the "Browser Mode" to be just "Internet Explorer 10" if the domain is in the compatibility mode list.

    Now if this just munges the user agent string to "spoof" IE as an older-ish browser to servers that are sniffing it then maybe my worries are all for naught.  However if *ANY* JavaScript methods/properties/implementations are not available/correct to mimic older IE versions (e.g. they provide the broken getElementById(id) method implementation then this isn't going to fly.  Ditto for any CSS that should work in modern IE browsers (rounded corners, attribute selectors, opacity, etc.)

  25. Tom Winter - MediQuant says:


    "I can't get the "Browser Mode" to be just "Internet Explorer 10""

    No you cannot. But why does that matter? As the article I linked to says the only thing this does is change the UA sent to the server, how conditional comments are handled, and the default document mode if none is asked for (which is N/A for you since you are asking for one). The browser mode does not affect JavaScript and CSS, etc. The document mode does. They are two different things. Your document mode is Standards as you asked for. So you'll get standard JS, CSS, etc. We're in the middle of upgrading to Standards mode and we've had no problems with this stuff since we don't do anything on the server side with the UA and we don't use conditional comments. Everything works as in Standards mode because we asked for Standards mode.

  26. Dave says:

    @Tom do your users have your app/site in their compatibility list though?

    If as you said the JS and CSS is not affected that's fine. I think we’d all like some confirmation from Microsoft on this though cause it is confusing as heck!

  27. Tom Winter - MediQuant says:


    I honestly don't know about our users. All are in corporate environs but I don't think we've ever told anyone to put our site in compatibility mode. But for what we do it doesn't matter since the compatibility mode affects "Browser Mode" not "Document Mode" and we don't make any decisions based on Browser Mode. In the IE 10 time frame I did add code to specifically ask for IE 5 Quirks mode (which is a Document Mode) since IE 10 was more aggressive about putting you into Standard mode if you didn't say what you wanted, forcing your site to break and you to fix it (that's basically what they said on this blog about why they did that.)

    For our Standards mode stuff the Browser Mode ("regular" or compatibility) doesn't seem to affect anything. Which makes sense since Browser Mode is not the same thing as Document Mode. The article I linked to makes it very clear that they are two different things and that they do different things. It clearly says what Browser Mode does (which is what compatibility mode affects).

    It sounds like you want them to state that the Standards Document Mode under "regular" Browser Mode will work the same as Standards Document Mode under compatibility Browser Mode. To me it seems obvious that it would. Browser Mode is documented by Microsoft (in the article I linked to) as doing three specific things, none of which affect how Standards Browser Mode works. They say clearly what Browser Mode does; I'm not sure why they'd then need to say all the things it does not do. They do not talk about a Standards Document Mode under Compatibility Browser Mode" I assume because there is no such thing.

    Calling them "Browser Mode" and "Document Mode" is confusing. "Browser Mode" might have been better called "Server-side Browser Alias" since that's what it is. "Document Mode" might better be "Client-side Operational Behavior".…/testing-sites-with-browser-mode-vs-doc-mode.aspx

  28. Phil Edholm says:

    I wanted to make a couple of comments on my earlier post as some thought it was negative on ORTC, nothing is farther from the truth.  I applaud the Hookflash team for developing and driving an object oriented (ORTC) WebRTC API.  From all I understand, this standard holds great promise and will be great for developers when it comes to completion.  It is also great that it is positioned as WebRTC 1.1, an augmentation to, not a replacement of the existing standards efforts. I also am excited about Microsoft supporting an open standard in IE for web based applications to use communicators utilities. This will dramatically increase the velocity of the webification of communications, a transformation that will create great benefits and opportunities.

    Yannick, ORTC is not yet a standard and while it is moving forward, it is not approved, nor, as I understand, has ORTC been fully sanctioned by the W3C.  That is not to be negative to ORTC, all appearances are that ORTC will become a part of WebRTC 1.1 in the future and being a valuable part of the overall WebRTC ecosystem. BTW, the current WebRTC 1.0 is not a fully approved standard either, though that should happen in early 2015.

    My earlier comments were, from general frustration.  I was identifying the current state of affairs in web based commutations (defined as having comms built into web devices and browsers and other peering components).  They are not specific to this announcement or ORTC.  The following are a few comments on the current state of the industry.

    – We do not have agreement to implement WebRTC 1.0 from either Microsoft or Apple.

    – Microsoft is committed to ORTC in WebRTC 1.1, but that will take at least 6-12 months to come to fruition, probably longer to standards approvals. In the interim, Microsoft has not indicated it will support the current standard.

    – We still have an issue with codecs with a number of vendors preferring the H.264/5 versions and Google preferring the VP8/9.  This is an open interoperability issue for developers, companies looking to use WebRTC and end users trying to use WebRTC based services.

    The result of these challenges is that the timing of a common, very inter-operable WebRTC implementation with broad support is still unclear.  Hopefully, with WebRTC 1.1 (ORTC) and agreements on codecs we can close this gap in 2015.  In the interim, it is great to see Microsoft committing to an open WebRTC 1.1/ORTC implementation and that Google is supporting that as well.

    Finally, as a Lync/Skype user, I am excited about the prospect of having a WebRTC based guest mechanism in those tools.  I think it will significantly enhance their value.  While the current web based guest access works, it is challenging and I believe that Microsoft will enhance both offers with an open web based paradigm hat works well across all browsers.

  29. Bernard Aboba says:

    Those interested in understanding object support within WebRTC may want to take a look at the following presentation by Google, Microsoft and Hookflash:…/ORTC_API_Update.pdf

  30. AndyCadley says:


    Browser Mode = How the Browser announces itself (can't be controlled by the document, because the browser has to send this *before* receiving anything)

    Document Mode = How the Document is interpreted by the browser.

  31. Mod says:

    Guys please stop hijacking the comments. This article is about WebRTC, lets stick to the topic — commenting on internet ethics 101

  32. Shrini says:

    @Shijun Sun,

    From which date/month webRTC support is available? Whats the IE version for usage? There is no clear indication of release date.