No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Building Mayday with WebRTC	

Four months ago, Amazon introduced a one-way video interface for customer support on their high-end tablets, calling it the Mayday Button. Since then it has been part of nearly every conversation that I have had with customer service professionals. Some say that this capability has been available in the legacy environment for years. They may be right, but the key differentiators are ease-of-use and reduced customer effort.

More than 300 companies have embarked on efforts to build products with Web Real-Time Communications (WebRTC). Most have built replicas of legacy telecom solutions. Mayday could be considered one of these replicas, but it appears to have captured the imagination of many in the customer support community. What most of these professionals do not understand is that the tools to deliver support similarly to Mayday are widely available, and implementation in most cases is no more complicated than any legacy CTI integration. If audio communication is all that is necessary, then integration is delivered with a SIP trunk. Video requires CTI.

WebRTC Basics
Before discussing legacy integration, we need to review some basics for WebRTC. WebRTC is an open-source software project that uses the same audio codecs and media services found in most commercially available PBXs. Video uses the VP8 codec, not the widely used H.264 codec--although this particular factor is of no consequence in the Mayday configuration.

Google and Mozilla have built the media services and codecs into their respective browsers, so no downloads or plugins are necessary. At this time, these two browsers represent more than 1 billion enabled end-points. If Internet Explorer and Safari support is necessary for your Mayday implementation, then they can be supported by Flash; although, at a much higher price.

WebRTC uses web servers as directory/signaling servers, and content (audio/video) is supported by media services. (More about media services later.) What this means is that audio and video sessions do not traverse the Web server's backplane or network connection. Also, in this architecture, audio and video are IP-based and they do not traverse the public switched telephone network (PSTN). This makes the monthly recurring charges an order of magnitude less expensive than the PSTN.

WebRTC also supports native iOS and Android implementations without the need for a browser. Windows and OS X "clients" are also available. These interfaces can share the Mayday infrastructure, and security is supported by end-to-end encryption. Further, WebRTC signaling and transports are subject to Interactive Connectivity Establishment (ICE), so this is not your father's gateway. These topics will be covered in a subsequent post.

Legacy Integration
Legacy integration is achieved most easily by using the media services that are built into most commercially available session border controllers (SBC). Some manufacturers offer software-only upgrades, while some require software and hardware. If you have SIP trunks in your network, then you have an SBC somewhere. If your SBC manufacturer is not up to the task, then there are several cloud services available that can deliver WebRTC sessions to your contact center via a SIP trunk to your existing SBC

Whether you convert the WebRTC sessions to SIP trunks at your SBC or in the cloud, they arrive on your contact center platform the same way that PSTN calls do. What this means is that these calls can follow the same routing rules that are defined in the call center.

The added benefit is that calls which would usually receive IVR treatment in order to determine their route no longer need it. That is, of course, if you use logic on the website links that mimic the IVR routes. In other words, if the caller clicks the Mayday button on the mortgage page on the website, then they go to the mortgage queue. Further, if the customer authenticates on the website, then IVR authentication is not necessary because you only make Mayday available to already-authenticated users.

Now that the calls are connected to the correct agent, triggering the video is a simple exercise in CTI mapping. In other words, you now know the IP addresses of the customer and the agent's PC, so triggering the video is straightforward and logical. If all you need is audio, then you can forgo the CTI.

Effectively, implementation of Mayday, audio only, is little more complicated than plugging in a SIP trunk. Video is more complex, but no more than a simple screen pop. The added benefits are the ability to substantially reduce customer effort, decrease handle time, eliminate the need for IVR, and reduce PSTN recurring costs. Further, this opens the door to higher-level functions like micro-targeting, screen sharing, push-video and co-browsing without the need for a download or plugin.

The Society of Telecommunications Consultants is an international organization of independent information and communication technology (ICT) professionals serving clients in all business sectors and government worldwide.