If you’re a heavy user of social media, chances are good that you’ve already experienced the WebRTC (“Real Time Communications”) standard. The technology allows for easy browser-to-browser voice and video communications that users can engage in without the necessity of downloading any application or codec first…they simply click on the “chat” button. It you’ve ever used Google Hangouts, the Amazon Mayday button or Facebook Messenger for video chat, you’ve used WebRTC. You’ve probably noticed that the quality was pretty good. But then…you’ve got the power of three huge and successful companies behind you to make sure the quality was good.
WebRTC has great promise for sales and customer support. For individuals using a browser that supports WebRTC, it adds another real-time communications channel that is fast and easy, and very personalized. Many companies that have considered offering it, however, remain wary of quality. So they probably should: chance are, your organization doesn’t have the IT resources of Google, Amazon or Facebook.
In a recent blog post for The New Dial Tone, Amir Zmora points out that things get more complex when a call needs to exist the “WebRTC protected island.” When you’re using a media channel to enable customers to contact you, it’s critical that voice quality is good enough…otherwise the representative and the customer waste their time shouting to be heard and repeating their information. That’s hardly likely to keep a shine on the customer experience. For starters, according to Zmora, you need to ensure the quality of your network and be sure it’s rigorous enough to support WebRTC.
“There are some things an enterprise or hosted UC provider can do about the network,” he wrote. “It boils down to things around SD-WAN, DIA (Dedicated Internet Access) and MPLS…one can’t assume all users are calling from within a managed network so all these options are irrelevant for this discussion.”
Zmora discusses how the voice codec OPUS can help ensure the best quality for any given bitrate.
“Opus has a few important benefits,” he writes. “[These are] support for a wide bitrate and varying sample rates all the way up to fullband (48KHz); supports both constant and variable bit rate; support for a wide frame size range (how much ‘audio time’ is contained in a frame); on-the-fly decisions about bitrate, bandwidth used and frame size; good resiliency for packet loss and packet loss concealment.”
Contact centers may be less well prepared to handle WebRTC calls because of the nature of their legacy technology. They were built to accommodate landline or cell phone calls, not calls originating from a Web site. Zmora recommends that contact centers consider moving agents to a Web browser instead of phone, or changing agents’ phones to ones that support Opus. To reduce complexity and expense, he notes that it’s recommended that contact centers move Opus from the browser to the contact center, then transcode.
“In this case, the critical part of the communication over the Internet is done using Opus,” he wrote. “Then, when voice enters the contact center it is transcoded to G.711/G.729. With this, there needs to be no real change on the contact center part.”
Other options may be more or less complicated and some may be better suited depending on the contact center’s needs. (The blog goes into greater depth regarding options available.) One thing remains certain: if the method of WebRTC you plan to use doesn’t support the kind of video quality your customers expect, you will need to take extra steps, unless you can find a contact center platform vendor who fully embraces WebRTC and has already engaged in the troubleshooting for you.