
Microsoft goes its own way with Web audio/video spec, despite W3C rebuff - coloneltcb
http://arstechnica.com/information-technology/2013/01/microsoft-goes-its-own-way-with-web-audiovideo-spec-despite-w3c-rebuff/
======
7rurl
The big problem with Microsoft's spec is that it doesn't specify a protocol,
so it is impossible for other browsers to implement the standard. The spec
only says that RTP will be used but not what specific profile or codecs.
Microsoft's prototype uses a plugin for Chrome and IE that implements their
proprietary protocol.

The WebRTC spec on the other hand does specify a protocol via the RTCWeb IETF
specs. The SDP used in WebRTC is part of that. Also the Chrome and Firefox
teams are working hard to get the two browsers talking to each without
resorting to prototype plugins and instead using their own separate
implementations of the WebRTC protocol.

When/if Microsoft publishes the protocol specs, then their UC-RTC-Web spec
will truly be complete and we can judge it on its merits compared to WebRTC.
Also in a very real sense the WebRTC spec is more complete since it does
specify a protocol.

~~~
mook
Small correction: Chrome and Firefox teams are using basically the same
implementation of WebRTC; see [http://mxr.mozilla.org/mozilla-
central/source/media/webrtc/t...](http://mxr.mozilla.org/mozilla-
central/source/media/webrtc/trunk/README) \- it's an import of the Chromium
code into Mozilla. Having the source available definitely makes
interoperability easier and is better than having a blobby bit, though.

------
beagle3
A lot of people here are arguing that "Microsoft has legitimate concerns". Of
course MS are framing it like that - would you really expect them to say "We
made this proposal because Google+Firefox+Apple are neutering our
Embrace+Extend+Extinguish ritual, and additionally the WebRTC thing is going
to demolish the $8B value of our skype purchase"?

The fact that they may have good technical arguments should not confuse you.
They're not doing anything to make the web better. They are doing everything
to make Microsoft's hold in the market stronger. Everything else is
incidental.

Story time:

Back in 1999, I worked on instant messaging infrastructure, and as a result
followed the related IETF workgroup closely. That workgroup had very
interesting discussions that went absolutely nowhere over a few years. At some
point, everyone threw their hands up in the air and adopted XMPP - not because
it was good (far from it, compared to other suggestions that were made) - but
because an implementation was made and progressing, and becoming a de-facto
standard.

What I realized through 1999-2002 following the standardization process was
that, although every single argument ever made was of a technical nature, it
was a game played between AOL, MS, Netscape and the other members of the
workgroup, the game being "either you guys accept my existing infrastructure
and give me dominance, or I'm not sharing my toys". And since no one gave up,
toys -- to this day -- are not shared, and IM networks are still mostly
disjoint.

The WebRTC game might be more delicate, but the validity of the technical
arguments (which was there in the IM discussions too) should not confuse you.
It's about market control and dominance, not about technical excellence.

~~~
Camillo
Sure, but are the other players completely disinterested?

Some of them might have pure motives: take Mozilla, for instance, which seems
to see WebRTC as a trojan horse to force the market to adopt non-MPEG codecs.
They have the users' best interests in mind, but it's not obvious that their
focus on that aspect necessarily yields the best web RTC standard.

~~~
beagle3
> but it's not obvious that their focus on that aspect necessarily yields the
> best web RTC standard.

Best RTC standard for who?

I believe that patent-free RTC (as WebRTC provides by virtue of preferring
WebM) is better than a patent-encumbered even if it has a slightly better
session initiation/description protocol.

Regardless - yes, one should definitely try to map the underlying reasons and
subtext of every statement. But the bottom line is:

Google has been working, in public and with a freely usable implementation, on
a specification. Mozilla adopts same specification (and mostly same codebase).
Said specification ALREADY works on iphones, android phones, Chrome, Firefox
and even IE (with the right plugin).

Microsoft proposes something, not completely defined, only provides a plugin
implementation, only for IE and Chrome, unsupported on any phone. In my book,
it needs a much better story than just "better session descriptor".

And frankly, with Microsoft's past of hijacking the web standards, the office
openxml iso process hijacking, all the linux patent threats and the android
patent extortion that is STILL ongoing, they need to work much, much, harder
before I even give them the benefit of a doubt.

~~~
ZeroGravitas
There seems to be widespread confusion about WebRTC already adopting VP8/Webm
as a mandatory-to-implement codec. No such decision has been made. Though the
two furthest along implementations (Chrome and Firefox), which also happen to
have about a billion users between them are both pushing VP8 which might make
it a defacto standard anyway.

They (IETF WebRTC) _have_ adopted the Opus audio codec as mandatory-to-
implement, which isn't officially part of WebM (though apparently Chrome 25
can play it in that container) as it's far more suited to real-time
communication than Vorbis.

For the video codec, they were going to call for consensus (basically on VP8
vs H.264) but Google mysteriously suggested that the decision be delayed on
the day before it was supposed to have happened, claiming to have something in
the works that would solve the whole problem to everyone's satisfaction.

My wild guess (given the fact that the VP9 encoder and decoder is now
available to download from mainline codebase and is beating x264 and H.265
objectively and subjectively [1] for pre-recorded content--and I'd maybe guess
that even VP8 beats H.264 for standard WebRTC use cases) is that they're
working out some behind the scenes political deal with other industry partners
to jump straight to VP9, either by getting all relevant parties on board
regardless of patent sabre-rattling, or by working something out with patent
holders to neutralise that threat. Both are a bit wild as I said, the more
boring explanation is that Google feared losing the call for consensus and had
something brewing to sway a few swing voters but didn't have it ready in time.

[1]: <http://forum.doom9.org/showthread.php?p=1611395#post1611395>

------
kenjackson
I'd like to hear the counter, but MS's rationale here seems solid. And given
they have it working compatibly in IE10 and Chrome seems like they're moving
in good faith.

I know that a lot of HN likes to say, "M$ can't do that because everyone knows
they're evil" -- I'd like to actually see good technical arguments for why
what they're doing isn't prudent.

~~~
magicalist
> I'd like to hear the counter, but MS's rationale here seems solid.

That's partly because Peter Bright (the story author) overstates Microsoft's
case. SDP _is_ a problematic part of the current spec, but most of those
problems are just things that it can't do yet, and if you look at the mailing
list thread responses to the messages he links to, you can see most of the
discussion is about moving SDP expansion discussions back to the IETF working
group. This will slow things down, but that's how standards work sometimes.

But, SDP is only a part of the spec. Meanwhile, Microsoft's proposal retains
essentially none of the current WebRTC spec. _That_ was the real issue with
their proposal, coming relatively late in the game, and why it's misleading to
put the disagreement in terms of only SDP. Microsoft's reps have issues with
how the connections are bootstrapped, but took the opportunity to rewrite
everything else while they were at it. That's certainly their prerogative, and
is again how standards are sometimes produced, but the issue is more
complicated than "SDP is bad, but the W3C is clinging to it" as Peter tells
the tale.

I agree that Microsoft is moving in good faith, however. As a good parallel,
see Firefox's incompatible Audio Data API, produced just as the Webkit-born
Web Audio API was picking up steam. When specs are early and still being
worked on, sometimes the best thing is to produce a working implementation, to
show others that your proposal really is as good as you say it is. That isn't
_necessarily_ undermining the standards process, nor is it a sign of the
process not working. It can be, but at this stage, Microsoft is still engaged,
even if they are just repeating why they think their proposal is better.

It _will_ slow things down, but standards work is sometimes really slow,
especially when people disagree, and growing pains are inevitable. You can
only hope this gets sorted out fast enough that the spec is still relevant by
the time it comes out.

~~~
ricardobeat
Is their rewrite of everything else better? WebRTC itself is so young that a
complete rewrite shouldn't be out of consideration if needed. Nobody wants to
carry bad decisions over the years anymore.

~~~
thefreeman
I think that perspective is shortsighted. It isn't that people want to carry
over bad decisions. It's that everybody needs to follow the _same_ standard,
and it takes a while to get consensus among the many parties involved.

When Microsoft goes and pulls a Microsoft and completely ignores the W3C to
implement their own standards, we are heading in the __wrong __direction. Only
recently (IE 9+) did Microsoft start adhering to web standards and its been a
relief.

This feels like they are abandoning that, and it's going to give me
nightmares.

~~~
ricardobeat
We're on the same side. But just having a 'standard' is not enough; it needs
to fulfill it's purpose in the most useful way.

I'm by no means pro-MS, but they are not abandoning standards, they just
proposed one. Google and Mozilla have implemented things their own way for the
past half decade before _any_ discussion had started, that doesn't preclude
moving to a standard later on.

------
jan_g
>The problem is SDP. SDP wasn't originally designed for browser-to-browser
communications, and some of the things that WebRTC uses it for go above and
beyond the specification.

But SDP is just session description. In a way just metadata, so to speak.
Hardly a big part of webRTC specification. Ok, there are some rules that
govern how to choose appropriate codec and similar, which may seem complicated
(but in my opinion aren't - I've worked with SIP for many years), but it seems
way overboard to submit your own specification just for SDP. I think it would
be many times better to try to influence webRTC specs than splitting the
effort and almost certainly prolonging adoption.

------
brudgers
[Linked from the article]

Microsoft's reasons in Microsoft's own words:

[http://blogs.msdn.com/b/interoperability/archive/2012/08/06/...](http://blogs.msdn.com/b/interoperability/archive/2012/08/06/customizable-
ubiquitous-real-time-communication-over-the-web-cu-rtc-web.aspx)

The Ars article sums this up as:

 _Even backers of the current WebRTC specification acknowledge that the SDP
problems have so far proven intractable. The WebRTC spec hinges on getting SDP
fit for purpose._

So the title of the article is a bit link baity.

~~~
beagle3
> Microsoft's reasons in Microsoft's own words:

Microsoft's PR official reasons in their own words.

The real reasons may or may not be related. Personally, I don't trust any
statement from Microsoft about improved functionality or specification. That
might be right in this case, but their past actions indicate that they care
about market dominance rather than any technical detail.

------
panabee
I'm very hopeful that MSFT will soon adopt a common standard, whether WebRTC
or an adjusted WebRTC. However, the business case does not support such a push
from Microsoft. They purchased Skype for $8B, and it's their every incentive
to ensure web telephony remains difficult and that Skype remains the best,
cheapest, and simplest way for people to communicate with video and voice.
They want Skype everywhere, but Skype becomes less compelling in a world where
any two engineers can effectively build Skype-level quality (or better) inside
a browser.

------
ttar
Wow, SDP and SIP that brings back nightmares about that stateful protocol. The
code to handle them was unimaginably complicated

------
davidjnelson
The interplay between open standards versus competition is fascinating. On one
hand, all browser makers sharing the same standards makes my life as a
software engineer easier. On the other hand, one standard to rule them all may
stifle innovation and progress. My initial reaction was, "what a shocker".
Then I thought a bit more deeply about it.

------
mtgx
Seriously, why? They are basically using the exact opposite of the HTML5 video
codec argument, when they and Apple said there should be only one codec. And
now they say are saying there should be multiple codecs for WebRTC - because
maybe now it may not completely suit them? (even though Skype uses VP8).

~~~
kenjackson
When did MS say there should be only one codec? MS actually said that they'll
support whatever codec you had on your computer -- they just weren't going to
ship <choose your favorite codec> in the box. It was Google that was saying
that they'd stop supporting H264 in Chrome, period.

------
Aardwolf
Digital video and audio is nothing new. At all. It's like decades old.

Getting images in browsers was never a problem.

Why is it STILL a problem to get audio and video in browsers?

~~~
wmf
<audio> and <video> pretty much work fine AFAIK. We're now talking about
putting a P2P/VoIP/videoconferencing stack into the browser which is a bit
more complex.

~~~
zanny
I still can't put <video src=blah></video> in a page and expect it to work in
every browser. I need at least webm + mp4, or ogv + mp4, so I double the space
utilization on my server for every video maintaining redundant copies, in
addition to the various resolutions you make video at because ISPs are
assholes and we are still in the dark ages of internet speeds.

------
DanBlake
This is the exact reason we (Tinychat) never took WebRTC seriously. Its not a
unified standard by any manner of speaking. Even firefox and chrome have
different implementations. If we were to even attempt to get it working, we
would have to have encoding and decoding since the codecs differ as well (no
speex in webrtc). At least flash has the same experience across browsers.

~~~
beagle3
It's work in progress. No one is expected to take it seriously in production.
Yet.

------
gst
And in a few years from now they will be complaining again that Google is
"blocking" their browsers, by not supporting their standards.

~~~
nivla
Ohh yes good ol' 302 redirect was invented and only supported by Microsoft. I
suggest you re-read the article than throw in the M$ bash at the hint of
Microsoft. They have legitimate reasons for proposing the alternate. I rather
have all the companies heard and come to a common ground to set the standards
than one company leading the others.

------
phren0logy
Thee was a time when Microsoft could do this and get away with it. It's sad
that they seem to be the last ones to know that those days are behind them.

~~~
HelloMcFly
Did you read the article? This doesn't seem like the old "Microsoft bullying
others into following" story, this seems like legitimate reasoning for the
moment.

~~~
beagle3
They are not in a position to bully anyone, just like they were when IE3 came
out. So they made IE4 which mopped the floor with NS4. And it still took a lot
of time until the momentum changed and IE became popular.

And then they bullied everyone with IE 5, IE 5.5 and IE 6 - like they did (and
still do) with Office (OpenXML), SMB, Kerberos and a variety of other
products.

Of course their statement is going to be about merit - they've never said "oh,
we're bullying here" even when they were. And their statement MIGHT even have
some merit - but just like in the OASIS OpenOffice document spec, instead of
working with the industry, they arrive late with their own underspecified and
alternative specification.

It's same old Microsoft.

------
tomjen3
Well it won't matter. By the time enough people have migrated from the old
versions of IE (which will most certainly not support this tech) tablets will
be the target market.

Microsoft should really realize it is a has-been and not enter new areas.

------
drivebyacct2
As long as there is a JS implementation that they're providing (FTA) then I
don't see whats worth a big fuss. I was worried from the headline that this
would pre-empt serverless p2p VoIP from Chrome<->IE, but that doesn't seem to
be the case.

