The Webification of UC

We used to speak of convergence. Initially, the context was physical, running voice and data over the same wires. That battle was won, and the term's popularity subsided, but we never stopped converging aspects of communications.

Over the past decade, convergence continued as the most powerful and predominant force in communications. We converged the networks, staff, departments, servers, management systems, and clients. But that wasn't enough. Now, with WebRTC, we are about to converge the domains of real time communications with the Web unlike anything before it. It is going to happen, possibly rapidly, and it threatens key established assumptions and models.

All modern enterprise communications systems leverage an architecture that includes a media server and a control server. The media server, for lack of a better term, supports the physical connection of audio and video calls, while the control server provides access to features and directory services. WebRTC is no different in this fundamental architecture. However, it is disruptive because the control server can be housed on a web server or integrated with a local directory.

WebRTC will impact the communications industry, but it didn't come from Bell or the ITU. It comes from the Web, and has no notion of PSTN, TDM, or dial plans. WebRTC is a clientless architecture, but not for the reasons that you might think. WebRTC is peer-to-peer, thus WebRTC can exist in the network without any "servers" or "switches" needed. WebRTC enables on-demand collaboration--not just within an organization but across the web. SIP is also peer-to-peer; however, it was architecturally co-opted to look and act like a client-server application. Because the PSTN carriers do not control Internet directory services, they cannot co-opt WebRTC.

Another shift in paradigm with WebRTC is the concept of identity. Rather than centrally managed dial plans, WebRTC maps identity to the website supporting the directory services. If you use multiple web sites, then you can have multiple identities. Facebook, LinkedIn and American Express can each offer different user identities and experiences on the same browser--much the way website user accounts are supported today.

The expected result is that WebRTC will let the telecom cat out of the bag. Instead of a contained master/slave relationship between telecom servers and telecom endpoints, WebRTC transforms virtually any website into a telecom server and utilizes the web itself to connect to virtually any web enabled endpoint. Not to mention it will add a slew of approximately 9 million additional developers that will begin building telephony applications. The WebRTC-enabled browser will effectively drop the cost of UC endpoints to zero, and offers a default, ubiquitous endpoint. No downloads, no clients--just rich audio and visual communications.

The vendors will still license various UC features, but they will be freed from the burden of creating or licensing UC clients--nor will enterprises need to distribute and maintain them. WebRTC-enabled browsers could potentially replace the need for separate UC clients. This will dramatically simplify the work required for the UC vendor to create unique clients, as well as for organizations to distribute and maintain them. Vendors that already have browser-based clients will find this to be a natural and smooth transition. Many that do have browser implementations are already implementing SRTP, iSAC, iLBC and VP8 (WebRTC software components) within their products so that the transition to WebRTC will be smooth.

Pre-standard WebRTC-enabled browsers are available now: Chrome R23 was released in November, Ericcson's Bowser browser was released in October, Opera Mobile last August, and Mozilla is expected next month. Today, browser-based applications generally require a downloadable plugin, an added step which seems trivial, but becomes problematic with larger implementations.

But the bigger opportunity lies in communications across organizational boundaries. There's no requirement to implement federation capabilities, meaning WebRTC enables rich communications with external users, particularly when enabling communications between web-enabled customers and call center agents.

A study by BIA Kelsey revealed that 97% of purchasers of new products or services first research their purchases online. There's no reason to go from a detailed web page to an IVR only to re-navigate with the same logic. A single click could engage a properly routed call that conveys contextual information.

Next page: Examples of WebRTC-based solutions

Here are a few examples of WebRTC-based solutions--all of which can be built with JavaScript and HTML code:

* A WebRTC gateway can deliver a secondary communications path to every desktop, tablet or wireless phone in an enterprise without having to do any reconfigurations on the existing communications infrastructure. Even in very large organizations, this could be accomplished in days or weeks. N+1 replication and failover are built into the architecture, so enhanced reliability is available. Further, home-based or traveling employees can become easier to reach.

* A new type of virtual carrier can support voice or video communications via WebRTC without actually owning or leasing a network. It could enable encrypted PC, tablet and smartphone communications by just setting up a WebRTC-enabled website.

* Big Data will change the way enterprises can route and process contact center interactions. The Obama campaign used 80 attributes to develop the best way to persuade each persuadable voter in their database. Enterprises are using these same techniques to develop marketing offers. If a user clicks-to-call from a social media site, profile information can be sent along with the call--much more information than ANI and DNIS. Routing, micro-targeted offers and talking points could be generated in milliseconds. Without an IVR, a firm could "know" considerable information about callers, enabling it to better address caller needs and suggest relevant offers.

* A large insurance enterprise could offer patients a collaboration interface. Though it could do this today, the licensing cost for 24 million users is usually out of reach. Its directory services can be customized to the patients' health care providers, case managers, insurance adjusters, family, ambulance service, clergy, etc... The patient can contact, via audio, video and/or screen sharing, anyone in this community to act or consult about everything from their next appointment to a bill that does not look right. The patient gets healthier.

By the way, the insurance company becomes the trusted adviser because they have more information than anyone else. A strange position for an insurance company, but they manage to make people healthier and also manage to bank the profits.

* Virtual enterprises that deliver products or services can involve multiple corporations. Think web retailing for this example. The legacy approach to communications between these corporations is via the PSTN, e-mail or federation. With WebRTC, the customer simply clicks the icon on their shipping notice to talk to the right support organization to solve their problem. No "you all have to be on the same carrier" issues, no dedicated trunking, no caching of ANI or DNIS to support CTI, no IVR--rich identity and context travel with the call.

The opportunity to have the interface built into a browser allows users to access these types of services without interruption. No failed downloads, no delay for updates, it just works from the browser on their PC, tablet or smartphone.

The fact that WebRTC is new doesn't mean it isn't proven. Avaya Aura, Cisco Webex and IBM Sametime are based on code that was developed by Global IP Solutions (GIPS). This is the company that Google bought in 2011 and thereupon offered its WebRTC code to the open source community in 2012. GIPS code has been used in some of these products for more than eight years. The fact that WebRTC uses the same object code that is found in products like Aura, Webex and Sametime should put most enterprise users at ease.

True enough, there is some disagreement about the video standards. Some, like Microsoft, believe that H.264 is a better video codec than the VP8 codec that WebRTC uses. Certainly, H.264 is more mature. The most often cited argument against VP8 is that most of the commercial products are already based on H.264. This seems to be less of an issue now since Vidtel implemented an MCU in the network that supports both.

Not all of the vendors were willing to share their plans, but we know Avaya, Cisco, Siemens Enterprise, and Mitel have commitments toward WebRTC-enabled products soon. Further, there will be a number of non-traditional vendors that will offer WebRTC media servers and gateways--think SBC or softswitch manufacturers. The vendors typically don't pre-announce products or solutions, but clearly WebRTC is significant enough that they are willing to at least share their philosophy about it. Expect lots of announcements in 2013 from traditional telecom manufacturers, telecom carriers and some dominant social networks in 2013.

It has the potential to completely eliminate the concept of separate voice and data networks and architectures.

Dave Michels is a Contributing Editor and Analyst at TalkingPointz. Chris Vitek is President, Enterprise Telemetry.

Follow Dave Michels on Twitter and Google+!
@DaveMichels
Dave Michels on Google+