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.
> 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.
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.
WebRTC is being develop by IETF and W3C both of whom have very strong preferences for royalty-free (and otherwise RAND-Z/RF) standards. Why would you imagine they would pick an MPEG codec?
Maybe the low-delay wideband voice and audio codec also developed by IETF under the same requirements (both technical and royalty-wise) would fit better?
And, on the topic at hand, have Microsoft made any public statement about their support for that codec, despite the fact that it was co-developed by their Skype purchase? Only vague murmurings that the alternative standard discussed here shouldn't be "tied to a single codec". Note the masterful misdirection that would make you thing that WebRTC was "tied to a single codec" when in fact you can use any codec you like, you just have to support Opus (best in class, yet RF) and G.711 (old and busted for legacy interop) to help ensure interoperability.
The fact that the simple logic of this seems somehow underhand to you is a testament to the great political job that Microsoft, Apple, Nokia and others have done in the web codec arena where a codec, which could never be adopted under W3C rules, has come to seem like the obvious choice when really it was a bold attempt to subvert the W3C into not specifying a royalty-free codec so that a royalty-encumbered de-facto standard of their choice would fill the gap that was left.
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.