Getting Real on RTC in the Enterprise
A look at the state of WebRTC today, and how standards affect the enterprise
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:
- Enterprises depend on standards to interoperate with other companies, such as IT vendors, product suppliers, etc. If technology does not conform to designated standards, then enterprises will not seriously consider a vendor's product or service.
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