The answer is that ORTC is a little bit of everything.
I have been looking at ORTC from the sidelines for some time now. And I noticed how different people refer to it differently. So I decided to gouge the opinions of readers here on how they perceive ORTC.
I have published the results earlier this week as part of my monthly newsletter, and I’ll reiterate it here – because some of those participating might not be subscribed on it:
There are many stories of how ORTC started and I don’t know the details there, but to me, ORTC is about bringing Microsoft into the fold of WebRTC. It has a slightly different name, and a different set of APIs to it, which are considered of a lower level. It killed of SDP, which no one really likes anyway.
The first approach towards explaining ORTC to the uninformed that I’ve seen was to refer to it as WebRTC 2.0.
Another approach? During the Kranky Geek Show Google referred to ORTC as WebRTC 1.1.
Then there are those who see ORTC as a competing standard to WebRTC.
Too much is going on…
Let’s look at some interesting players around this new ORTC spec to decide where it is headed.
Microsoft
Microsoft is a part of the ORTC work. It seems the decisions at Microsoft have been to adopt RTC in the browser and the only question remaining is how.
As with any standardization bickering, it is a mix of two things that are related:
- Technology and NIH. With any spec, you will always find two architects that won’t agree on it. So the guys at Microsoft naturally won’t agree with all that is WebRTC – simply because they didn’t invent it. They have good reasons, but then again, the end result won’t be perfect either. It links also to the NIH syndrome of developers – what wasn’t invented here isn’t good enough.
- Business and competition. Google has a huge head-start with WebRTC on everyone else. They’re practically writing the code and testing it with hundreds of vendors already. What is a competitor to do besides slow down progress to get his act together? So you invent something similar but slightly different, just to make sure those ahead of you need to invest in house keeping as well.
Microsoft’s intentions here are probably about making ORTC different enough from WebRTC to break down everything developed with WebRTC. Even if just a bit. I’d do that if I were Microsoft – I have that vindictive nature in me.
Google? The thing they want most is for WebRTC to succeed as is. They have invested in it humongous amounts of work and money already. A lot more than all other players.
Getting Microsoft’s support is important, and from a technical standpoint, throwing SDP out the window has its merit. So joining forces with Microsoft on ORTC is the only possible move if you ask me.
What Google needs to make sure at every step of the way is that the end result of ORTC is backward compatible with WebRTC.
Best case scenario? Existing services continue working without any hiccups.
Reasonable scenario? Existing services will need to adopt a shim similar to the adapter.js (or have all necessary differences wrapped inside the adapter.js that Google offers already). It would also be nice if using this shim would enable the same service to run flawlessly on the future Microsoft IE version that will support ORTC once released.
Worst case scenario? Existing services will need to be modified to accommodate for the changes necessary.
Hookflash
Hookflash is interesting here. They are a small player – one of the startups working on an API platform. They are riding the wave of ORTC in order to gain enough publicity and marketing if you ask me.
Being an author of a draft of ORTC with Google and Microsoft definitely takes time and energy, but does it really necessitates a press release?
For a start up it most definitely does. I don’t think it matters much for its potential customers, but it might garner a higher valuation in a fund raising round from VCs. They are in it for the publicity more than anything else, and that’s valid.
Others
Apple is absent in this. The ORTC initiative has in it Google and Microsoft, additional vendors who play in the WebRTC space, individuals and consultants of different types.
Some are there as passive listeners while others are there to contribute.
The usual mix in standardization organizations.
Why is this important?
We still don’t know what ORTC really is.
Is it close enough to be considered WebRTC 1.1, so its effect on existing services is marginal?
Is it too far off to be considered WebRTC 2.0, breaking all backward compatibility and proving to be a royal headache for existing services?
Is it going to end up being competitive with WebRTC so that we have two separate RTC APIs to deal with in our browsers?
Only time will tell.
I believe that when it comes to large companies like Microsoft, Apple, Google, Oracle, etc. the desire to be “different” doesn’t as much stem from a NIH syndrome but from the fact that although standards may be in a consumer’s best interest, they are not in a vendor’s best interest. Vendor’s sell on the uniqueness of their product, not on the “sameness”. Despite what they say, vendors really don’t like standards and will only adopt them if pushed – and it isn’t always possible to push the big players since they are big enough to withstand the pressure.
For this reason I believe Microsoft will adopt WebRTC “on the wire” – in other words since Google has a head start, ORTC will be able to interact with a Chrome application using Google’s implementation. But the internal architecture they have proposed so far appears to be different (and slightly better than Google per our tech folks) and we can pretty much rest assured that the API will be different enough to require re-coding unless one uses an “over arching” API that bridges both. So my take is that Microsoft will claim “WebRTC” meaning compatible on the wire, but applications won’t be portable.
It isn’t about Google vs. Microsoft. It is about Chrome vs. IE. I think it is possible that if over time Google WebRTC or Microsoft ORTC dominates, then the one with the least market share will level the playing field and incorporate the other – just to prevent further erosion of market share. But there is a real possibility that will never happen. After all, Chrome and IE are still both out there and going strong and still trying to be different.
This vendor attitude toward standards has been around since standards began and even a major standard like SQL where one can at least argue that a better implementation is a unique that vendors can sell on isn’t standard across all vendors.
Ted,
Only time will tell. I have less of a bad impression of Microsoft; but I can easily see your point.
A few months ago I was rather astonished when a Microsoft representative speaking with my company asserted offhandedly that Microsoft had “invented WebRTC.” When pushed on this, he pointed us to the CURTC project, which was superseded by ORTC. I downloaded the latest Microsoft sample ORTC plugin and server code for analysis and testing.
What I found was a brittle, somewhat skeletal proof of concept. That is, the demo plugin would only allow one very limited AV pathway between two sides of a call. I didn’t have time to test its NAT traversal reliability in general, but even on the same network it often required 5-10 seconds to connect a call, which was sometimes difficult to distinguish from a call failure. As far as I could tell from looking at the approved discussion forum on this code, only the developers were using it.
Granted, your article is about the ORTC standard, rather than one particular implementation of it. My only point about the Microsoft demo implementation of their standard is that something so weak and limited looks more like a feint than anything else. To me, it seems that Microsoft has no significant interest in the standard it’s pushing. More likely, it wants to dilute or muddy the existing WebRTC standard.
And of course, in the unlikely event that Microsoft did act seriously in favor of ORTC (which would be a real change of heart for the closed-source, developer-unfriendly organization that MS is), it would almost certainly attempt to employ its time-honored “embrace and extend” policy to trap code development.
What’s Google’s real incentive for appeasing Microsoft? You yourself pointed out that commercially viable alternatives exist for using WebRTC as-is on Internet Explorer and Safari, such as the excellent Temasys WebRTC plugin. There is every expectation that numerous other WebRTC plugins will follow in the months and years to come.
Having a brittle proof of concept or demo is just fine in my book.
It took Google many months to stabilize their WebRTC implementation and I am sure there’s still much to be improved.
Microsoft are working in a different version release cycles than Google. They don’t throw a new version to the market every 6 weeks – rather a year or two. So it makes sense to see them as a slower player. I am sure that once they get to implement and launch ORTC/WebRTC officially in their browser, it will be a lot better than what you can find from them at the moment in this domain.
Interesting read here Tsahil. Thanks for the mention, here are my comments..
Regarding your sentiment “Microsoft is looking to mess with WebRTC”, from personal experience, that does not add up at all. They have been active in the ORTC CG, W3C WG and the IETF WG. From where I am sitting, ORTC aside, they are helping things in the WebRTC sphere, certainly not hurting things.
Re Hookflash – Having spent more than a year (and tremendous heaps of our own personal time) working on this spec and library. This announcement was us celebrating the milestone with our co-authors. Showing pride in what we have accomplished with the intent to drive some awareness around the ORTC API and Library, so that others might take a look and maybe even contribute to the ORTC LIbs as well. I see no shame in that.
Finally, ORTC should be viewed as an evolution to WebRTC, not a revolution. The name its given is less important in my mind, in the end it will all just be WebRTC anyways.
Erik,
To make things clear – you should have nothing but pride for what you are doing. As I stated, being in your position, I’d do the same 🙂
As for naming, it is important simply because the idea is to have more adoption for WebRTC, and having an additional name to explain is a hassle. Since WebRTC is all about reduction of barrier and friction (see my latest post) – then this is an issue.
From my recollection, the WebRTC 2.0 reference was used loosely to describe ORTC to those who were not familiar with the W3C ORTC work before an actual designation on the ORTC API was attributed.
The 1.1 designation came from the W3C ORTC CG back in April in a CG meeting: http://youtu.be/hVlfP-OYsQc?t=8m47s. In an effort to not create confusion we took a 1.1 designation instead of 1.0 for the initial API, considering the current WebRTC spec would be 1.0. I think it was Peter Thatcher from Google that proposed it, Justin seconded it, there was no opposition. From this point forward we referred to ORTC as 1.1
Since the goal here is to unify these 2 specs, the translation manifested itself as such: ORTC 1.1 = WebRTC 1.1
Hope this clears things up a bit.
I suspect that this will play further into the hands of Tokbox, Twilio, Temasys and co.
The platform players will probably be able to tell developers that they will handle any complexities in blending ORTC & WebRTC behind the scenes, exposing both through a single API that abstracts it away from web & app developers as much as possible.
Dean,
You are of course correct. The more complexity and ambiguity, the better the WebRTC API Platform vendors gain from it.
Dean is absolutely correct. Frozen Mountain already provides an SDK API for true portability that uses Google’s implementation for Chrome, FireFox and Opera, provides an ActiveX (for now) for IE until ORTC comes out in which case it will use that, as well as support for Safari. Additionally, there have been many requests for WebRTC without the Web – the ability to have native applications send “wire comparable” WebRTC requests so Frozen Mountain provides native Android, iOS, .NET, Java and Xamarin support. We are assuming this battle will go on for some time so the only way to achieve portability will be another API. Maybe sad in some ways, but the big guys are driven by what makes business for them, not acceptance of standards.
Hi,
When do you think WebRTC 1.1 will be released? Is Microsoft Edge going to support it?
Sojharo,
The better question is when WebRTC 1.0 will be released. Currently, best case is end of this year the spec gets completed, and the actual standard released sometime in the first half of 2016.
I assume the cold battle between Google WebRTC and Microsoft oRTC will be for some months or years to come, it’s just giving me more white hairs than I already have…
Google invested in WebRTC with thousands of codes and billions of dollars injected in the chrome browser, followed by Firefox and Opera… Then Microsoft came intruding with Abject-RTC ah pardon Object.
Will we have 2 APIs to deal with in real time communication ?
We keep developing the WebRTC-based applications and not to worry about oRTC.
Alain,
I guess you didn’t see the latest news. Microsoft have decided to embrace WebRTC and actively add WebRTC 1.0 support to Edge.