7 ms·

Microsoft goes its own way with Web audio/video spec, despite W3C rebuff

82 points by coloneltcb 14y ago

phren0logy 14y ago
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.
- rednukleus 14y ago
  > "I'd shut it down and give the money back to the shareholders." It is far too early to say with certainty that Microsoft's ship has sailed. IBM turned themselves around. Apple turned themselves around. Microsoft is still in a far, far better position than either of those companies were at one point. EDIT: Parent edited their comment to tone it down. Leaving my comment as it is.
  - meaty 14y ago
    I'd argue they are in a far better position than Google, Facebook and Apple regarding privacy and honesty (shokcing thought that). I think this will be the next battleground so they may have a chance of winning.
    - mikelat 14y ago
      Why? Skype in china? Xbox live ads? Scroogled (and other anti-google campaigns)? WGA? They've done plenty of questionable things which are shady and violate privacy.
      - meaty 14y ago
        All the other guys are doing it worse - that's the thing. I'm not saying they are suddenly perfect, but they are less worse than the others.
        mikelat 14y ago
        The worst I can think of is facebooks changing of their TOS, and the companies are "scary" with the kind of data they're potentially compiling but they haven't actually done anything yet (and switching to microsoft products would simply make them the scary company). Some things that apple does like patent abuse is something that Microsoft has done as well, so its difficult to single out apple for something like that. Or facebook's lock in is similar to the Windows API lock in. You want to give me examples of things that make all 3 of those companies worse than microsoft?
- HelloMcFly 14y ago
  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.
  - taf2 14y ago
    It's the same old same old... Missing spec - to replace a working spec. Preserving their Skype IP - if WebRTC is widely adopted Skype is done.
  - beagle3 14y ago
    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.
mtgx 14y ago
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 14y ago
  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.
- masklinn 14y ago
  The issue at hand here is not alternate video codecs, it's the fundamental building blocks of the system (SDP for WebRTC, which Microsoft disagrees with) as well as the core use cases.
brudgers 14y ago
[Linked from the article] Microsoft's reasons in Microsoft's own words: http://blogs.msdn.com/b/interoperability/archive/2012/08/06/customizable-ubiquitous-real-time-communication-over-the-web-cu-rtc-web.aspx http://blogs.msdn.com/b/interoperability/archive/2012/08/06/... 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 14y ago
  > 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.
kenjackson 14y ago
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.
- jtanderson 14y ago
  I think it's good their taking the non-SDP route. Hopefully they will be able to help whatever the final standard becomes by deviating from the current WebRTC. Though I have my share of frustration with the consumer end of Microsoft, I love keeping up with all the research they provide. At least this isn't as drastic as some of their complaints about hardware standards; I think it has a good chance to contribute, and not hinder, what the W3C is doing.
- magicalist 14y ago
  > 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.
tomjen3 14y ago
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.
- Roybatty 14y ago
  Your problem is that you don't want to deal with reality or are just trolling. Office is still dominant whether you like it or not. SQL Server as well as Windows servers are still huge. Dotnet is still huge and probably growing as Java remains stagnant. You guys can keep on pretending, but the rest of us will deal with reality.
panabee 14y ago
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.
davidjnelson 14y ago
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.
drivebyacct2 14y ago
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.
jan_g 14y ago
>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.
ttar 14y ago
Wow, SDP and SIP that brings back nightmares about that stateful protocol. The code to handle them was unimaginably complicated
7rurl 14y ago
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 14y ago
  Small correction: Chrome and Firefox teams are using basically the same implementation of WebRTC; see http://mxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/README http://mxr.mozilla.org/mozilla-central/source/media/webrtc/t... - 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.
- shmerl 14y ago
  Another big problem is their attempt to prevent mandating any open codecs.
gst 14y ago
And in a few years from now they will be complaining again that Google is "blocking" their browsers, by not supporting their standards.
- nivla 14y ago
  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.
Aardwolf 14y ago
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?
- jan_g 14y ago
  A problem exists, because there's no standard way to access microphone and camera. And this access is absolutely essential in order to implement voip. Hence, we've got flash, which is becoming a big problem, because it's been discontinued on some platforms.
- wmf 14y ago
  <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 14y ago
    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.
beagle3 14y ago
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 14y ago
  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 14y ago
    > 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.
DanBlake 14y ago
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 14y ago
  It's work in progress. No one is expected to take it seriously in production. Yet.

82 points by coloneltcb 14y ago

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.

rednukleus 14y ago
> "I'd shut it down and give the money back to the shareholders." It is far too early to say with certainty that Microsoft's ship has sailed. IBM turned themselves around. Apple turned themselves around. Microsoft is still in a far, far better position than either of those companies were at one point. EDIT: Parent edited their comment to tone it down. Leaving my comment as it is.
- meaty 14y ago
  I'd argue they are in a far better position than Google, Facebook and Apple regarding privacy and honesty (shokcing thought that). I think this will be the next battleground so they may have a chance of winning.
  - mikelat 14y ago
    Why? Skype in china? Xbox live ads? Scroogled (and other anti-google campaigns)? WGA? They've done plenty of questionable things which are shady and violate privacy.
    - meaty 14y ago
      All the other guys are doing it worse - that's the thing. I'm not saying they are suddenly perfect, but they are less worse than the others.
      - mikelat 14y ago
        The worst I can think of is facebooks changing of their TOS, and the companies are "scary" with the kind of data they're potentially compiling but they haven't actually done anything yet (and switching to microsoft products would simply make them the scary company). Some things that apple does like patent abuse is something that Microsoft has done as well, so its difficult to single out apple for something like that. Or facebook's lock in is similar to the Windows API lock in. You want to give me examples of things that make all 3 of those companies worse than microsoft?
HelloMcFly 14y ago
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.
- taf2 14y ago
  It's the same old same old... Missing spec - to replace a working spec. Preserving their Skype IP - if WebRTC is widely adopted Skype is done.
- beagle3 14y ago
  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.

mtgx 14y ago

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 14y ago
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.
masklinn 14y ago
The issue at hand here is not alternate video codecs, it's the fundamental building blocks of the system (SDP for WebRTC, which Microsoft disagrees with) as well as the core use cases.

brudgers 14y ago

[Linked from the article] Microsoft's reasons in Microsoft's own words: http://blogs.msdn.com/b/interoperability/archive/2012/08/06/customizable-ubiquitous-real-time-communication-over-the-web-cu-rtc-web.aspx http://blogs.msdn.com/b/interoperability/archive/2012/08/06/... 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 14y ago
> 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.

kenjackson 14y ago

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.

jtanderson 14y ago
I think it's good their taking the non-SDP route. Hopefully they will be able to help whatever the final standard becomes by deviating from the current WebRTC. Though I have my share of frustration with the consumer end of Microsoft, I love keeping up with all the research they provide. At least this isn't as drastic as some of their complaints about hardware standards; I think it has a good chance to contribute, and not hinder, what the W3C is doing.
magicalist 14y ago
> 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.

tomjen3 14y ago

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.

Roybatty 14y ago
Your problem is that you don't want to deal with reality or are just trolling. Office is still dominant whether you like it or not. SQL Server as well as Windows servers are still huge. Dotnet is still huge and probably growing as Java remains stagnant. You guys can keep on pretending, but the rest of us will deal with reality.

panabee 14y ago

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.

davidjnelson 14y ago

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.

drivebyacct2 14y ago

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.

jan_g 14y ago

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

ttar 14y ago

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

7rurl 14y ago

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 14y ago
Small correction: Chrome and Firefox teams are using basically the same implementation of WebRTC; see http://mxr.mozilla.org/mozilla-central/source/media/webrtc/trunk/README http://mxr.mozilla.org/mozilla-central/source/media/webrtc/t... - 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.
shmerl 14y ago
Another big problem is their attempt to prevent mandating any open codecs.

gst 14y ago

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

nivla 14y ago
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.

Aardwolf 14y ago

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?

jan_g 14y ago
A problem exists, because there's no standard way to access microphone and camera. And this access is absolutely essential in order to implement voip. Hence, we've got flash, which is becoming a big problem, because it's been discontinued on some platforms.
wmf 14y ago
<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 14y ago
  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.

beagle3 14y ago

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 14y ago
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 14y ago
  > 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.

DanBlake 14y ago

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 14y ago
It's work in progress. No one is expected to take it seriously in production. Yet.