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.
ORTC API for WebRTC
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
Anonymous
October 27, 2014
This is perfect! Please announce support for Service Workers next (in the very least behind a flag or prefixed).Anonymous
October 27, 2014
Any plan to support H.265 in the near future in addition to H.264?Anonymous
October 27, 2014
@dholcombe 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.Anonymous
October 27, 2014
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+).Anonymous
October 27, 2014
The comment has been removedAnonymous
October 27, 2014
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.Anonymous
October 27, 2014
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 @disruptivedeanAnonymous
October 27, 2014
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.Anonymous
October 27, 2014
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.Anonymous
October 27, 2014
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?Anonymous
October 27, 2014
@Phil - ORTC is a standard too.Anonymous
October 27, 2014
According to this very blog: blogs.msdn.com/.../just-the-facts-recap-of-compatibility-view.aspx [Microsoft] "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.Anonymous
October 27, 2014
@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.)Anonymous
October 27, 2014
Aren't you guys a bit late to the party? (Google Hangouts)Anonymous
October 27, 2014
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.Anonymous
October 27, 2014
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.Anonymous
October 27, 2014
In other words, you are just interested in Chrome. Typical "open" warrior.Anonymous
October 27, 2014
This sounds great, IE and Skype together will be very useful for the customer.Anonymous
October 27, 2014
@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.Anonymous
October 27, 2014
The comment has been removedAnonymous
October 27, 2014
@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: http://i.imgur.com/CljrnzT.png (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. @CurrentMicrosoftIEStaff 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?Anonymous
October 27, 2014
@EricLaw and @Joel, I get the same behavior on github.com 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: stackoverflow.com/.../114267 Quote: 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 ;-) blogs.msdn.com/.../testing-sites-with-browser-mode-vs-doc-mode.aspxAnonymous
October 27, 2014
@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. From blogs.msdn.com/.../just-the-facts-recap-of-compatibility-view.aspx: 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.Anonymous
October 27, 2014
@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.)Anonymous
October 28, 2014
@Joel, "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.Anonymous
October 28, 2014
@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!Anonymous
October 28, 2014
@Dave, 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". blogs.msdn.com/.../testing-sites-with-browser-mode-vs-doc-mode.aspxAnonymous
October 28, 2014
The comment has been removedAnonymous
October 29, 2014
Those interested in understanding object support within WebRTC may want to take a look at the following presentation by Google, Microsoft and Hookflash: www.rtc-conference.com/.../ORTC_API_Update.pdfAnonymous
October 29, 2014
@Tom 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.Anonymous
November 03, 2014
Guys please stop hijacking the comments. This article is about WebRTC, lets stick to the topic -- commenting on internet ethics 101Anonymous
March 08, 2015
@Shijun Sun, From which date/month webRTC support is available? Whats the IE version for usage? There is no clear indication of release date.
