14 Comments

Summary:

Microsoft published a first prototype for plugin-free video chat in the browser Thursday. However, it’s a bit different from what Google and others have in mind.

webrtc

Microsoft’s Open Technologies unit published a prototype implementation of browser-based video chat today that allows a user of a Mac OS-based Chrome browser to chat with a user running IE 10 on Windows. The demo shows both how serious Microsoft is about web-based video chat and how far away the industry still is from a common, open standard for real-time communication.

Microsoft has been working for some time on web-based real-time communication, and could one day use this kind of technology to take Skype to the browser, as well as make it interoperable with other messenger platforms and applications. The company started to participate in efforts to standardize this kind of browser-based communication last summer, albeit with a somewhat different take than others.

Previous efforts around web-based, plugin-free voice and video chat were largely driven by Mozilla and Google, with the latter contributing a lot of its technology to an effort dubbed WebRTC, which is short for web-based real-time communications. Work on WebRTC had been progressing in 2012, and parts of the technology has already been implemented in Chrome and Opera.

However, Microsoft argued that some of the core assumptions of that approach were wrong. In particular, the company took issue with efforts to make Google’s VP8 video codec the default choice for WebRTC. Microsoft’s own proposal, dubbed CU-WebRTC, would instead leave it up to the developer of each app to settle on a codec as well as on other specifics, like the data formats used to communicate.

The company reiterated this position in a blog post Thursday, which was co-authored by Skype Senior Architect Martin Thomson, Lync Principal Architect Bernard Aboba and Microsoft Open Technologies Principal Program Manager Adalberto Foresti. In it, the trio writes:

“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.”

The post also admits that Microsoft’s initial proposal wasn’t exactly embraced by everyone: “The proposal generated both positive interest and healthy skeptical concern from working group members,” it states. However, the trio believes that the industry is nonetheless making progress towards a common standard – it may just take a bit longer to get there.

Image courtesy of Flickr user  Tsahi Levent-Levi.

  1. Tsahi Levent-Levi Thursday, January 17, 2013

    Definitely a most interesting development.

    If they can get the mindshare of developers that it is easy to connect CU-WebRTC to WebRTC implementations, but enable more use cases then they just might be able to make the changes they want in the standards.

    Share
  2. It is not ideal that two ‘standards’ are developing, but there will be middleware developers (like ourselves http://www.addlive.com) who will fill the gaps quickly.

    Share
  3. This is so typical of Microsoft, trying to disrupt the collaboration between others with their own thing because they don’t want to use “Google’s” open source VP* codec, that is now better than h.264 [1], and VP9 will soon be released, and so they try to somehow tie these “web communication” accounts to Skype, and most likely to avoid having WebRTC completely disrupt “Skyping” because it would work across web browsers and across clients.

    [1] Comparison between latest VP8 and h.268 from a month ago:

    http://pacoup.com/2012/12/20/vp8-webm-vs-h-264-mp4-december-2012/

    And doesn’t Skype already use VP8? I don’t get them.

    http://gigaom.com/2011/08/03/skype-vp8-video-conferencing/

    http://blog.webmproject.org/2011/08/one-to-one-vp8-video-calling-now.html

    Share
    1. Microsoft’s approach makes sense as VP8 codec is not good. If you deep dive, you will know why Google’s other products like Google Hangout do not use VP8 at all!

      Google wants to leverage WebRTC to gain browser market share for Chrome; So does Microsoft for IE 10 with CU-WebRTC.

      Share
  4. Sigh, another typical Microsoft embrace, extend and extinguish strategy. Who didn’t see that coming…

    Share
  5. Ugh. It’s like SOAP all over again where transport neutrality laid birth to a standard that was so open and complex that’s many argue was dead before it started. Sure, Internet standards should strive to be imclusive but never at the cost of practical utility.

    Share
    1. Erik Lagerway Friday, January 18, 2013

      +1 Jose, this is not helping.

      Share
      1. Jose de Castro is right on and he’s telling the truth.

        Any protocol or framework trying to address interoperatibility problem is seldom successful, especially if the protocol or framework are driven by a specific company with its own purpose. RPC, CORPA, EJB, SOAP, WebRTC….

        No two vendors implemented the stack the same way, with the result of getting one stack to talk to another one could be a nightmare

        Share
  6. Robert Welbourn Thursday, January 17, 2013

    Let’s not forget that there’s an awful lot of H.264 out there, particularly in mobile devices and video conferencing systems. It makes sense to allow WebRTC to be interoperable with those.

    Share
  7. Can a codec sit that high on the stack, at the application layer? I know calls can be made from the app layer to a codec on the lower network layer.

    Share
  8. WebRTC has no mandatory to implement codec (yet) but some kind of baseline codec seems useful if you want users with different browsers to be able to talk to each other. WebRTC absolutely does not and will not disallow browser vendors using H.264. But, it’s worth remembering that real-time codecs have different characteristics than other codecs. Opus, for example, is a real-time audio codec that beats all of the other real-time audio codecs substantially and it has nothing to do with the AAC codec that makes up the audio part of what people call H.264 video.

    Share
  9. Any protocol or framework trying to address interoperatibility problem is seldom successful, especially if the protocol or framework are driven by a specific company with its own purpose. RPC, CORPA, EJB, SOAP, WebRTC….

    No two vendors implemented the stack the same way, with the result of getting one stack to talk to another one could be a nightmare.

    Share
  10. Like always Microsoft has the great ideas

    Share

Comments have been disabled for this post