Oracle made some news last week by unveiling a WebRTC session controller (see Phil Edholm's previous NoJitter post for details). Oracle's announcement reflects the rapid transition of WebRTC from a promising technology at the high end of the hype curve, to one that will soon boast real-world deployments--with real-world problems.
As me and my Enterprise Connect WebRTC colleague Brent Kelly have previously discussed here on NoJitter, numerous technical challenges exist for those looking to get an early jump on delivering WebRTC applications: The lack of a standard video codec across all browsers; different WebRTC implementations in different browsers; the lack of compressed voice codecs; and the lack of any kind of WebRTC support from Apple, just to name a few. Products like the Oracle session controller help solve some of the challenges by enabling transcoding between various implementations of WebRTC, or between WebRTC and SIP-based communications services, but as these technical issues are overcome, the bigger obstacle for WebRTC to "cross the chasm" from hype to reality is to build a business case that will drive enterprise adoption.
In my conversations with those responsible for customer service, contact center, UC, and collaboration, several themes have emerged.
What will this do for me? Once we get beyond defining the concepts of WebRTC, enterprise LoB and IT folk are often struggling with the value proposition. "Why can't I just use "click for a callback" on my website? " "I don't want to share presence with customers because then I'll get interrupted all the time" "If it doesn't work on all browsers, why would I support it?" and "Customers won't want to use video" are some of the frequent concerns that I hear.
In response, I talk about the opportunity to shift calls to Internet to reduce 800 number and PSTN access costs, the ability to leverage WebRTC for specific use cases such as making account managers for high-value accounts available via video, and the ability to share meta-data during a click-to-call session to improve customer service.
We also talk about ways that companies can use WebRTC to extend UC and contact center applications to remote workers such as virtual at-home agents, outsourced agents, or employees working at customer sites, without the need for VPN or virtual desktop infrastructure. These potential use cases for WebRTC generally resonate well, but buyers want to see real solutions before they commit to spending money.
Will it work? Just about everyone these days has a Skype account, and often call quality isn't as good as the landline or enterprise IPT system running on a private network. So even "if" I could take calls via my website using WebRTC, would I want to, given the potential performance issues?
This is a tougher nut to crack, as so far there's aren't enough real-world deployments to test against. Furthermore, if WebRTC isn't ubiquitous, companies have to choose between offering it only for access via certain browsers--diverting say non-Chrome users to traditional call-in means--or they have to give customers the option to install a plug-in (or leverage one like Flash that may already be installed in the customer's browser).
Here again, the level of potential complexity often acts as a deterrent to aggressive implementation. And in any scenario, how do I manage call quality?
The bottom line is that we're starting to hit a bit of an inflection point with WebRTC. The promise/hype cycle remains off the charts, but achieving some of that promise requires addressing use and business cases, interoperability, ubiquity, and performance. It's time for real-world WebRTC solution providers to demonstrate that they can overcome these challenges and provide business value to their customers.
Follow Irwin Lazar on Twitter and Google+!
@imlazar
Irwin Lazar on Google+
