WebRTC Browser Interoperability: Heroic. Important. And...ExpectedWebRTC Browser Interoperability: Heroic. Important. And...Expected

Chrome and Firefox achieved interoperability in a WebRTC call.

Two days ago, the small microcosm of what WebRTC is today went bananas--even more than it did when Google came out with a Chrome version that had a flag enabling it to run PeerConnection video calls.

What was the big deal? Chrome and Firefox achieved interoperability in a WebRTC call.

I think it is a great feat. An important one. But somehow, I wasn't that impressed. Why? Because it was expected, and it is what makes WebRTC so magical.

You see, I did my share of interoperability testing. Something like 13 years of testing when working at RADVISION. You get used to it in time--1-4 events a year, multiple products, large number of vendors to test with. It takes time and effort, but then again, anything in software development requires time and effort.

The difference with WebRTC is the amount of participants in such an "event". Taken to the extreme, there should be 5 companies participating:

* Google (Chrome)
* Mozilla (Firefox)
* Opera
* Microsoft (IE)
* Apple (Safari)

That's like...trivial. Taking all possible pairings, you get to 10 pairs of test sessions between each 2 vendors.

Compare that to the number of companies in the last SIPit event, where 17 companies attended, and you see the stark difference in the required level of interoperability amongst vendors you need to reach with it.

And there's no real need for vendors who use WebRTC to test against each other in most cases, as they are developing their own silo'ed service anyway.

WebRTC is opening up a new strategy for VoIP companies that I call Interoperability 2.0:

* Rely on the interoperability WebRTC provides, courtesy of the browser vendors

* Build a proprietary/open service on top

So yes, clap your hands for the achievement of Google and Mozilla on this one – they deserve it. But let's move on to some more interesting issues, please.