Microsoft's web browser chat standard challenged by Google and Mozilla

A few weeks ago, Microsoft announced that it used the CU-RTC-Web standard to launch a demo that allowed Windows users of Internet Explorer 10 to video chat with users of the Mac OS X version of Google's Chrome web browser. At the time, Microsoft was a bit critical of another competing web standard, WebRTC, which it said was "far from complete and stable."

Today, Google and Mozilla jointly announced that they have used WebRTC to successfully launch a video chat between the Chrome and Firefox browsers. The efforts were demoed in a video, shown above, which saw Mozilla’s Chief Innovation Officer, Todd Simpson, talking with Google’s Director of Product Management, Hugh Finnan. The chat took place with the Mac versions of those browsers.

The WebRTC standard video chat can be checked out now if you download the desktop Chrome 25 beta and Firefox Nightly for Desktop. Google states, "In Firefox, you'll need to go to 'about:config' and set the 'media.peerconnection.enabled' pref to 'true'. Then head over to the WebRTC demo site and start calling."

The World Wide Web Consortium (W3C) is currently considering both WebRTC and Microsoft's push for CU-RTC-Web but there's no word yet on which direction the W3C might take.

Source: Google Chromium blog

Report a problem with article
Previous Story

Rumor: Nokia's EOS Windows Phone due this summer

Next Story

From The Forums: Windows 8 from an OS X user perspective

65 Comments

Commenting is disabled on this article.

Of the players involved, Microsoft, Mozilla, and Google, who has the most experience creating APIs?

Just as a majority reading this post, I don't have the expertise to know which approach is better. A majority posting here are picking the "better" by who they perceive as the better company. But, objectively considering what facts I do know, it seems obvious that there is one company that has the vast experience and know-how to create a quality long-term, future considerate API for browser-to-browser communication. All parties have an agenda, but which one(s) have proven that they can build a platform that adapts to more unknown future uses? Which one(s) have built any quality APIs?

Anytime MS does anything, everyone automatically assumes it must be bad because MS is so evil and Google/Apple are awesome, right?

Never mind the fact that with MS, there's no Ajax, and thus 99% of the modern web doesn't exist as we know it.

IE8, 9 and 10 ALL support AJAX. All of Microsoft's web properties are built using AJAX and HTML5 standards. Where did you get this?

Anthony S said,
IE8, 9 and 10 ALL support AJAX. All of Microsoft's web properties are built using AJAX and HTML5 standards. Where did you get this?

Microsoft created AJAX, and XHTML and a majority of the technology the web uses. Some of these technologies were available in IE4 and IE5, which is why Netscape lampooned them as 'non-standards compliant' as the MS technologies were 'then' rejected by the W3C only to be adopted 5-10 years later.

Remember when people would make websites and set the 'font' tag to WingDings, because the non-standard IE would use the WingDings font, and HOW HORRIBLE it was that browser would allow the site designer to DEFINE a font? Now this is NORMAL, yet nobody is thanking IE or Microsoft or apologizing for being stupid ******* in the 90s.

thenetavenger said,

Microsoft created AJAX, and XHTML and a majority of the technology the web uses.

An employee of Netscape invented Javascript, who is now the CTO of Mozilla, I hope you didn't forget about that majority. Now, Mozilla is the leading browser-maker to push for mobile device-based API's (which Google, Apple, and Microsoft are doing little to support, even though they're all touting their mobile phones being great for the Internet). While everyone else is focusing on their proprietary app stores, Mozilla is working on creating these API's and publishing them. Not only that, Android already supports these API's if you download Firefox (or maybe it was Nightly) on it. That shows how feasible of a task this is.

thenetavenger said,

Microsoft created AJAX

MS never created AJAX at all. As a matter of fact, no one created AJAX. AJAX existed since 1995 (when PHP and JS were both available). Its just people never used it.

pes2013 said,

MS never created AJAX at all. As a matter of fact, no one created AJAX. AJAX existed since 1995 (when PHP and JS were both available). Its just people never used it.

Look up XMLHttpRequest... You're just making yourself look ignorant.

Defcon said,
Anytime MS does anything, everyone automatically assumes it must be bad because MS is so evil and Google/Apple are awesome, right?

Never mind the fact that with MS, there's no Ajax, and thus 99% of the modern web doesn't exist as we know it.


This article has nothing to do with Apple, Internet Explorer, or Ajax.

pes2013 said,

MS never created AJAX at all. As a matter of fact, no one created AJAX. AJAX existed since 1995 (when PHP and JS were both available). Its just people never used it.

roflmao.

Kwanza said,

Look up XMLHttpRequest... You're just making yourself look ignorant.

MS did it differently. All browsers choose not to implement a ActiveX compatible solution. Was/Is ActiveX insecure? You damn right.


roflmao.

http://en.wikipedia.org/wiki/Ajax_(programming)

Don't laugh because you make yourself uneducated that has no idea what they are talking about. Please read.

pes2013 said,

MS did it differently. All browsers choose not to implement a ActiveX compatible solution. Was/Is ActiveX insecure? You damn right.

I don't think anyone but Microsoft could implement an ActiveX solution; that's why MS's version failed. Can you describe how wonderful Microsoft's involvement in JavaScript has been?

Microsoft pushes a standard. Competitors freak out and insist on being allowed to reinvent the wheel because...what? Pride? I don't get it.

/don't go praising the standards-drafting committee process by default
//OSI was approved and approved and approved and TCP/IP still stomped it out of sheer momentum

As far as I was aware. Web-RTC has been around since 2011 and was the original standard that Microsoft is branching off to add improvements and/or changes it thinks are advantageous.

Regardless, competition is a good thing at this stage.

WebRTC predates MS' and is based on open standards which have their IP rights handed over with them. MS' is based on more closed standards which are not complete (and was started well after WebRTC). WC3 has voted for WebRTC overwhelmingly.

Phalanger said,
WebRTC predates MS' and is based on open standards which have their IP rights handed over with them. MS' is based on more closed standards which are not complete (and was started well after WebRTC). WC3 has voted for WebRTC overwhelmingly.

Yes WebRTC was first, but sucks ass, which is why Microsoft 'fixed' it, offering the functionality needed.

Prior to 'today' Firefox and Chrome were incompatible when using WebRTC, partially due to how WebRTC works.

Closed Standards? What about Microsoft's proposal is a closed standard? This is the ignorant crap that somehow people never challenge. Microsoft provided EVERYTHING, nothing CLOSED or based on CLOSED standards. PERIOD.

This line of closed source project and open source projects is really mind-bendingly ignorant. If you want a REAL WORLD example of a 'closed standard' go look up VP8/WebM from Google, it is 'viewable' but NOT a Standard and CLOSED to ALL OUTSIDE INPUT. Which makes it far more CLOSED than WMV/VC1 and any MPEG 'standard'. (Google only controlled + code visible = CLOSED STANDARD)

thenetavenger said,

This line of closed source project and open source projects is really mind-bendingly ignorant. If you want a REAL WORLD example of a 'closed standard' go look up VP8/WebM from Google, it is 'viewable' but NOT a Standard and CLOSED to ALL OUTSIDE INPUT. Which makes it far more CLOSED than WMV/VC1 and any MPEG 'standard'. (Google only controlled + code visible = CLOSED STANDARD)

Actually, the proper comparison would be with H.264, which you have to pay for.

By the way, closed to outside input? At least look up what you're saying before you make false statements. http://www.webmproject.org/code/

Majesticmerc said,

Regardless, competition is a good thing at this stage.

When you are looking at different products to buy.

In web standards/web browsers, NO. It is not good.

thenetavenger said,

This line of closed source project and open source projects is really mind-bendingly ignorant. If you want a REAL WORLD example of a 'closed standard' go look up VP8/WebM from Google, it is 'viewable' but NOT a Standard and CLOSED to ALL OUTSIDE INPUT. Which makes it far more CLOSED than WMV/VC1 and any MPEG 'standard'. (Google only controlled + code visible = CLOSED STANDARD)

The only reason MS went its own way is because it wants to base it on two piece of technology which it own IP on, the codecs and the transport method. WebRTC contains WebM/VP8 and SPD, two things will would stop MS being able to forces users to pay for the use of their IP, and would also be dangerous because it would means the codecs are widely supported meaning their use in other video systems would degrade the need to pay MS for its part in the H264/H265 patient pool.

No one is going with MS on this one and they are doing it driven by an urge to make money through forcing people back into their IP, nothing to do with which technology is best for the industry. That's why WC3 has voted strongly in favour against MS'.

pes2013 said,

When you are looking at different products to buy.

In web standards/web browsers, NO. It is not good.

I think it is good. Any legitimately useful additions that Microsoft add to their proposal are likely to be integrated into the WebRTC standard, and if they aren't added, people will likely start using the MS fork instead. Either way, the best standard wins. Once the standard starts maturing, one fork will go away and all parties will work on finer details of the single spec.

Incidentally, this is how most of the W3C standards work. CSS properties, for example, are often implemented differently by the browser engines (Gecko, Webkit, etc) with a vendor prefix (e.g. -moz-border-radius, -webkit-border-radius). Eventually the W3C picks one proposal (or a combination of both) and makes that the standard. The prefix is stripped from the front and all browsers are forced to implement that to be standards compliant.

Majesticmerc said,

I think it is good. Any legitimately useful additions that Microsoft add to their proposal are likely to be integrated into the WebRTC standard, and if they aren't added, people will likely start using the MS fork instead. Either way, the best standard wins. Once the standard starts maturing, one fork will go away and all parties will work on finer details of the single spec.

Incidentally, this is how most of the W3C standards work. CSS properties, for example, are often implemented differently by the browser engines (Gecko, Webkit, etc) with a vendor prefix (e.g. -moz-border-radius, -webkit-border-radius). Eventually the W3C picks one proposal (or a combination of both) and makes that the standard. The prefix is stripped from the front and all browsers are forced to implement that to be standards compliant.


You said it yourself: "people will likely start using the MS fork instead"

Pluto is a Planet said,
Does this graph look like a complete flop?

https://hacks.mozilla.org/2012/08/opus-support-for-webrtc/

Or how about this extremely fast FPS on WebGL?

https://developer.mozilla.org/en-US/demos/detail/bananabread


You're advertising fast FPS while it directly accesses the GPU? Strange that it can reach high speeds.
It is still different from IE's aproach of GPU acceleration.
WebGL is not something that should be promoted. You wouldnt give a website DirectX access either. Its an attempt for Google and Mozilla to keep up with their ancient document approach of website rendering.

Shadowzz said,

You're advertising fast FPS while it directly accesses the GPU? Strange that it can reach high speeds.
It is still different from IE's aproach of GPU acceleration.
WebGL is not something that should be promoted. You wouldnt give a website DirectX access either. Its an attempt for Google and Mozilla to keep up with their ancient document approach of website rendering.

Reply when you can figure out how to explain that WebGL is a complete flop.

Note that WebRTC is a draft right now. Just because Chrome and Firefox have a basic version running, doesn't mean it will stay this way.
WebRTC can still evolve a lot.

It's very much possible WebRTC and CU-RTC-Web will converge to a single standard.

Majesticmerc said,
Interesting. Anybody have a TL;DR of the advantages of each?

http://blogs.msdn.com/b/intero...ver-the-web-cu-rtc-web.aspx

--

While the overarching goal is simple to describe, there are several critical requirements that a successful, widely adoptable Web RTC browser API will need to meet:

•Honoring key web tenets - The Web favors stateless interactions which do not saddle either party of a data exchange with the responsibility to remember what the other did or expects. Doing otherwise is a recipe for extreme brittleness in implementations; it also raises considerably the development cost which reduces the reach of the standard itself.

•Customizable response to changing network quality - Real time media applications have to run on networks with a wide range of capabilities varying in terms of bandwidth, latency, and packet loss. Likewise these characteristics can change while an application is running. Developers should be able to control how the user experience adapts to fluctuations in communication quality. For example, when communication quality degrades, the developer may prefer to favor the video channel, favor the audio channel, or suspend the app until acceptable quality is restored. An effective protocol and API should provide developers with the tools to tailor the application response to the exact needs of the moment.

•Ubiquitous deployability on existing network infrastructure - Interoperability is critical if WebRTC users are to communicate with the rest of the world with users on different browsers, VoIP phones, and mobile phones, from behind firewalls and across routers and equipment that is unlikely to be upgraded to the current state of the art anytime soon.

•Flexibility in its support of popular media formats and codecs as well as openness to future innovation - A successful standard cannot be tied to individual codecs, data formats or scenarios. They may soon be supplanted by newer versions that would make such a tightly coupled standard obsolete just as quickly. The right approach is instead to support multiple media formats and to bring the bulk of the logic to the application layer, enabling developers to innovate.

While a useful start at realizing the Web RTC vision, we feel that the existing proposal falls short of meeting these requirements. In particular:

•No Ubiquitous deployability: it shows no signs of offering real world interoperability with existing VoIP phones, and mobile phones, from behind firewalls and across routers and instead focuses on video communication between web browsers under ideal conditions. It does not allow an application to control how media is transmitted on the network. On the other hand, implementing innovative, real-world applications like security consoles, audio streaming services or baby monitoring through this API would be unwieldy, assuming it could be made to work at all. A Web RTC standard must equip developers with the ability to implement all scenarios, even those we haven't thought of.

•No fit with key web tenets: it is inherently not stateless, as it takes a significant dependency on the legacy of SIP technology, which is a suboptimal choice for use in Web APIs. In particular, the negotiation model of the API relies on the SDP offer/answer model, which forces applications to parse and generate SDP in order to effect a change in browser behavior. An application is forced to only perform certain changes when the browser is in specific states, which further constrains options and increases complexity. Furthermore, the set of permitted transformations to SDP are constrained in non-obvious and undiscoverable ways, forcing applications to resort to trial-and-error and/or browser-specific code. All of this added complexity is an unnecessary burden on applications with little or no benefit in return.

The Microsoft Proposal for Customizable, Ubiquitous Real Time Communication over the Web
For these reasons, Microsoft has contributed the CU-RTC-Web proposal that we believe does address the four key requirements above.

•This proposal adds a real-time, peer-to-peer transport layer that empowers web developers by having greater flexibility and transparency, putting developers directly in control over the experience they provide to their users.

•It dispenses with the constraints imposed by unnecessary state machines and complex SDP and provides simple, transparent objects.

•It elegantly builds on and integrates with the existing W3C getUserMedia API, making it possible for an application to connect a microphone or a camera in one browser to the speaker or screen of another browser. getUserMedia is an increasingly popular API that Microsoft has been prototyping and that is applicable to a broad set of applications with an HTML5 client, including video authoring and voice commands.

--

TL;DR; CU-RTC-Web > WebRTC.

Phalanger said,
You should look at sources other that MS for views on MS tech.

http://arstechnica.com/informa...eo-spec-despite-w3c-rebuff/

You will see the WC3 favours WebRTC (22-4 in their last vote).


Because the ones voting are mostly idiots who just want a quick browser to browser api while MS's proposed spec is for browser to anything including many legacy hardware (read most of the things you currently use).

Why should you settle for an inferior spec when the other can do all this one can and more?

The technical details are all in there (both specs). Feel free to check them out and see if MS is lying or not. The only way you will support WebRTC is if you only care about a standard to video chat between facebook accounts while ignoring the rest of the world.

Crimson Rain said,
Why should you settle for an inferior spec when the other can do all this one can and more?

The technical details are all in there (both specs). Feel free to check them out and see if MS is lying or not. The only way you will support WebRTC is if you only care about a standard to video chat between facebook accounts while ignoring the rest of the world.


SDP is support in a lot of hardware and software solutions. MS' only in their proprietary systems.

Here we go; Double standards AGAIN.

Im sorry but they should simply go the Microsoft way. Not because MS is better or IE is better (in most cases they are not, they aren't even cross platform) but MS sets the standard and has the most market share.

Period.

pes2013 said,
Here we go; Double standards AGAIN.

Im sorry but they should simply go the Microsoft way. Not because MS is better or IE is better (in most cases they are not, they aren't even cross platform) but MS sets the standard and has the most market share.

Period.


That's not how it should work. The better spec should be the standard.

The market share of the browser counts for very little in the case of standard selection. Picking a specific implementation of a standard just because "it's got the most market share" is the road to hell, since it could be far inferior to the competing standard. Regardless of which standard gets picked, the market leader would have to implement it anyway, so it doesn't make a difference whose browser is most popular.

Actually, I think it is more because of experience. Microsoft built a messenger network that used video chat. They purchased a software package, and therefore have input from the Skype group, a product that has literally billions of hours of video and audio calls, and it takes a lot of experience to have a network that can handle that much coordination of data.

But Google and Mozilla held one video chat between two people - well let's let them design it all then.

nohone said,
Actually, I think it is more because of experience. Microsoft built a messenger network that used video chat. They purchased a software package, and therefore have input from the Skype group, a product that has literally billions of hours of video and audio calls, and it takes a lot of experience to have a network that can handle that much coordination of data.

But Google and Mozilla held one video chat between two people - well let's let them design it all then.

Right attitude, but the wrong conclusion.

Microsoft's expertise with MSN and Skype will certainly prove valuable, they still have to try to translate that into an open standard, which Skype and MSN are not (although MSNP was reverse engineered AFAIK). It's also worth noting that Google also has IM experience with Google Talk, although not as much as Microsoft with MSN and Skype.

While you're correct that Google and Mozilla shouldn't simply write the standard on their own (assuming you were being sarcastic), to simply hand it off to Microsoft is equally bad. Competition between standards (at least in the initial stages) is good, since it allows the best implementation to organically grow. Once the standards become more mature, one will prevail and be chosen as the best standard, at which point all parties can work on the same standard. This is how it works for HTML and CSS currently.

Majesticmerc said,

Right attitude, but the wrong conclusion.

Microsoft's expertise with MSN and Skype will certainly prove valuable, they still have to try to translate that into an open standard, which Skype and MSN are not (although MSNP was reverse engineered AFAIK). It's also worth noting that Google also has IM experience with Google Talk, although not as much as Microsoft with MSN and Skype.

While you're correct that Google and Mozilla shouldn't simply write the standard on their own (assuming you were being sarcastic), to simply hand it off to Microsoft is equally bad. Competition between standards (at least in the initial stages) is good, since it allows the best implementation to organically grow. Once the standards become more mature, one will prevail and be chosen as the best standard, at which point all parties can work on the same standard. This is how it works for HTML and CSS currently.

Oh I definitely believe that they should all work together, find a spec that includes all their experience in creating AV communication tools, and use the best one. I doubt that will happen, though, as Google seems to have the attitude that either they own the standards, or they will just write their own and call it standard.

And let's not forget, that if Apple had submitted the specs to FaceTime like they promised to standards bodies, then we could have their input, but they only recognize specs when it gets them good PR as being open, otherwise we don't need standards.

Crimson Rain said,

That's not how it should work. The better spec should be the standard.

No, it should not be a competition where everyone writes their own spec, and one is judged to be better so that is the one that is chosen. Every spec has strong and weak points, and accepting the entirety of a spec when another spec may have ways of fixing the weak points in the first spec is bad. Take the best parts of all specs, and use them to build one that is the best.

nohone said,
Actually, I think it is more because of experience. Microsoft built a messenger network that used video chat.

That's very true, MS had a messenger network that allowed video chat using only official clients, each time a third party client managed to get video chat working (especially those that ran on *nix), an update was released that stopped them working.

n_K said,

That's very true, MS had a messenger network that allowed video chat using only official clients, each time a third party client managed to get video chat working (especially those that ran on *nix), an update was released that stopped them working.

What is wrong with that? They had a network that was not built to be, nor was it advertised to be open. Google does not advertise their search engine to be open, but in the past if someone figures out a way to game the system without actually hacking into their servers, they change it quite quickly. Or how about Ubuntu, Apple, Redhat, and every other software maker give people free reign to upload software to their software - the internet demands to be open and free, does it not?

Crimson Rain said,

That's not how it should work. The better spec should be the standard.

I completely agree. But, its just easier for consumers. Its a bitch for developers

primexx said,
we'd still be stuck on IE6 if we did it your way

No, we wouldn't. If companies would have worked together instead of competed, IE6 would have never happened in the first place. A lot of fault goes to MS on IE6 but I think other companies are to blame as well....

nohone said,
Actually, I think it is more because of experience. Microsoft built a messenger network that used video chat. They purchased a software package, and therefore have input from the Skype group, a product that has literally billions of hours of video and audio calls, and it takes a lot of experience to have a network that can handle that much coordination of data.

But Google and Mozilla held one video chat between two people - well let's let them design it all then.


Don't worry about Google's experience in building web services to scale with users, including video services. Whether the video and audio source is a YouTube clip or a webcam makes no difference to a router. It's purely a client-side detail. The only difference is that there's a new requirement of low latency, but this is why they're using RTP, a very proven protocol for real-time video conferencing.

Edited by Northgrove, Feb 5 2013, 10:36am :

pes2013 said,

No, we wouldn't. If companies would have worked together instead of competed, IE6 would have never happened in the first place. A lot of fault goes to MS on IE6 but I think other companies are to blame as well....

Like whom?

BajiRav said,

Well we do have WebKit now to fill in for IE6

Dumbest comment I've read in a while. Care to elaborate?

Northgrove said,

Don't worry about Google's experience in building web services to scale with users, including video services. Whether the video and audio source is a YouTube clip or a webcam makes no difference to a router. It's purely a client-side detail. The only difference is that there's a new requirement of low latency, but this is why they're using RTP, a very proven protocol for real-time video conferencing.

This is nothing like Youtube, nothing at all. Google has experience storing a bunch of bits and delivering them to the user efficiently. Youtube is about distributing bits from a data warehouse to the client. In a web cam chat, all a server does is coordinate the handshake between the two, once that is done no data would go to a server - if it is that is very inefficient. Why send data from user1 -> server -> user2, when you could do user1 -> user2?

Web chat is about encoding video on a device having a wide range of web camera resolutions with wide range of processors (arm to an i7), sending that data across a pipe of varying width (from 3G to fiber) decoding it on another device with a varying degree of processors, and displaying it on a wide range of video devices - and doing it in both directions at the same time. If there were an extra hop in between of sending the data to a server, not only would there be lag, but it would also be very inefficient since a server would be receiving thousands to millions of streams at the same time (choking the pipe in and out of the server) when all it is doing is retransmitting.

Google's experience with Youtube will not do it any good. Google voice, that would help, but not Youtube.

Webkit follows the CSS Working Group's recommendation to use prefixes for draft features, and then drop them when they become candidate recommendations.

We can argue that the prefixes suck--they certainly do cause some pain--but all browsers implement and use them. And just as with javascript, most developers use fallbacks for css too.

fobban said,
Webkit follows the CSS Working Group's recommendation to use prefixes for draft features, and then drop them when they become candidate recommendations.

We can argue that the prefixes suck--they certainly do cause some pain--but all browsers implement and use them. And just as with javascript, most developers use fallbacks for css too.


The fault partially lies with Webkit, by refusing to drop support for standardized prefixes, they are supporting lazy developers. In short, basically the same situation that caused the IE6 problem. We can all dance to the open standard tune all day but that doesn't change the fact that lazy developers caused the problem in both cases.

IE6 was the culmination of the Browser wars between IE and Netscape. If Netscape had been following the standard earlier, rather than constantly creating competing versions of html code, then maybe they would have been able to keep up the market share and keep Microsoft on its toes. But no, IE6 became the de facto standard, and the thorn in web developers' sides (though initially it was the best browser) while Microsoft ignored the web browser.

Webkit using prefixes isn't a problem. Developers using prefixes for production sites IS a problem. Prefixes are for pre-standards and should not be used in production code. But of course users want features, so developers cave (some more quickly than they should) and give the users features, then have to deal with the pain of quirky pre-standard/standard mixed code, across mixed browser install bases.