Enterprise IT folk don't much care what the acronym is, be it WebRTC, IMS, ORTC, RCS, SIP, VoIP, or whatever else, as long as it equates to less headache and more profit/less expense. Anything that could potentially disrupt IT processes undergoes greater scrutiny by said IT stakeholders, no surprise there. The value proposition of something that causes work for the IT department needs to be significant, maybe a factor of 10:1 pleasure to pain.
The enterprise has reason to be cautious regarding WebRTC. In the standards bodies, we have not exactly been speedy in our delivery of WebRTC, as it seems to have taken much longer than we originally anticipated.
Back in Time
Let me start with a bit of history. Peering into my real-time communications wayback machine, I remember listening to dissertations during a "RTC on the WWW" BoF meeting at IETF 80, which took place in March 2011. That's when Cisco Fellow Cullen Jennings said he would be happy to take on a lead position in an RTCWeb Working Group, but added that the likelihood that the group's work would be done in less than five years would be underestimating the challenge that lay before us. We all chuckled, as did he. How could the work possibly take that long? Certainly he was joking!
No one is laughing now. Work had really begun in 2010 before the BoF of which I reminisced... and we quickly saw the remainder of 2011, 2012, 2013, 2014, and now 2015, passing us by.
So, what have we achieved in that time? To be sure, we've put in thousands upon thousands of man-hours in standards work. We are all invested, and we are all still here fighting for this to be done. Alas, five years is upon us.
Getting It Done, Sans Standardization
If we look at the majority of WebRTC apps built over the past few years, we see that most of the larger implementations are mobile even though more than half of the smartphone browsers out there do not support WebRTC -- i.e., Apple is not on the WebRTC party bus. So what kind of dark art is this that enables developers to take advantage of advanced technology still wending its way through the standards process?
I hear the snickers, and rightfully so, as this is not all that surprising. Developers will not look a gift horse in the mouth for long before they leverage valuable open source code -- just look at what happened when Google open sourced the GIPS media engine it gained in the acquisition of Global IP Solutions. Many took that code and built it into their apps and toolkits, present company -- Hookflash -- included. We did not wait on the IETF, W3C, or browser vendors to figure it out; we just used what was available and built what we needed, and for the most part it worked. Now we see several WebRTC development toolkits for iOS and Android built on this stack as well, albeit native only, no WebRTC browser support for Apple, across the board.
Let's get back to the original impetus for creating this WebRTC standard in the first place. WebRTC was created so we could get rid of nasty plugins, extensions, and the like when communicating with voice and video in a browser. That still has not happened, but does it matter?
Step into my RTC wayback machine and let's look fast-backward to 2004, when as an executive and co-founder at an early shop building SIP softphones and SDKs, I found myself on a "The Future of IP Communications" panel at the Voice On the Net show in Toronto. The SIP versus proprietary signaling battle was on, and one of my sorties was aimed straight at my co-panelist Niklas Zennstrom, co-founder and then CEO at Skype, about Skype's signaling choices. "Why not get involved and make SIP better in the standards bodies? Why build in a silo? How does that help the rest of the community?" His curt but polite response went something like, "...standards are too slow in this regard and the world should now just use Skype." Of course I'm paraphrasing a bit, but I think you get the gist.
Skype was on a meteoric growth path, so his comments had weight. But this is a typical retort of those in startups who want to move quick and where standards are not quite ripe enough for consumption. We can't really blame them for wanting to move fast; in fact, moving at "Internet speed" has become a fundamental cornerstone to developing software in general. Build often, fail fast, at least when it comes to code, is a religion for many dev shops.
The Standard Still Counts
Again, I must ask, "If developers can build mobile, desktop, and some browser voice/video messaging apps today, does this new WebRTC standard even matter? Does anyone care for it to matter, enough?"
Regardless of your pedigree, history, dev acumen, or Agile/MVP beliefs... the answer for the enterprise is "Yes, it does." Here's why:
It's OK to build your scrappy little startup in a silo, it is, but when it comes to interoperating with others and building economies of scale, standards are almost always the only way. If you are not prepared to wait, that's OK too -- others will step up and fight on your behalf. These patrons of standards will energetically battle each other in the standards bodies and when it comes time to build your next project, you will find many of your questions answered, thanks to the hard work done in communities like theW3C and IETF.
Continue to the next page for a look at what's what with ORTC
Continued from Page 1
Real Time With ORTC
Now that we have established standards are important, especially to the enterprise, you might wonder which standards should be included when researching your RTC solutions.
One company in particular rules the enterprise, and that's Microsoft. But Microsoft supports ORTC, not WebRTC.
OK, so what is ORTC, or as it's formally known, Object Real-Time Communications. Back in 2013, a small team from Hookflash, with Microsoft joining shortly thereafter, formed the W3C Community Group to work on a parallel effort to WebRTC with a focus on advanced functionality via object APIs. We first pitted ORTC as an alternative to WebRTC work happening at the WebRTC working group. But now ORTC and WebRTC are converging, and the WebRTC working group already has integrated some of the ORTC APIs into the WebRTC 1.0 spec. The ORTC Community Group (CG) now boasts more than 100 members, including Google.
When contemplating the future of WebRTC, the question now is not how much of the ORTC API will end up in the WebRTC spec but more how long browser vendors and other stakeholders will take to implement ORTC objects. Based on what we are seeing in Chrome and Firefox, it could be years.
Here's a quick look at who's doing what with ORTC:
So, when and where do you bite down? If WebRTC is to be the huge success in the enterprise we all want it to be, three things need to happen:
No matter where you land, 2016 is going to be a stellar year for enterprise real-time communications and Enterprise Connect 2016 in Orlando, Fla., is the place to be to learn more about it. Join us there as we open the WebRTC Conference Within a Conference on Monday, March 7, with the keynote address, "The State of WebRTC."
Editor's note: This version of the article reflects updated information on Mozilla.