WebRTC can bring valued functionality to your unified communications (UC) products. Doing so effectively, however, requires implementation of protocols that are defined across a range of IETF standards.
As a UC product developer, I’m sure you’re well-aware of how WebRTC could potentially enhance your contact center, PBX or videoconferencing suite. I’m sure your business customers are already asking you when your product will support it.
As you start to think about your next steps to implementing WebRTC, I’d like to flag up a few challenges that have to be solved so that you can cost-effectively deliver the benefits your customers are looking for.
Business benefits
The appeal of WebRTC to businesses is straightforward: fewer lost sales, better customer service and enhanced employee productivity.
For example, with WebRTC a company could offer a click-to-call option that makes it easy for a potential customer browsing its website and unable to find the right information to place a call into its call center. This could certainly help rescue sales that might otherwise be lost.
Using WebRTC in this way can also enhance customer service. This is because WebRTC allows calls to be connected with highly useful, contextual metadata – such as what page a caller was looking at when they called, or even who the caller is. Having this kind of information makes it that much easier for a business to provide a more joined-up – and therefore better – service to customers across its different channels.
And for businesses that regularly use audio and video conferencing products, letting people join a conference call from their browser, without wasting time downloading or updating plug-ins and applications, offers a simple boost to productivity.
Three challenges
When adding WebRTC functionality to your product, you’re likely to encounter three main challenges:
- Signaling. WebRTC doesn’t have a signaling protocol built in. This gives flexibility, but means that you’ll need to implement additional functionality to use your product’s signaling protocol with it.
- Media handling. The WebRTC media stack typically supports the G.711, Opus, VP8 and basic H.264 media codecs. If your product uses a different set, then you’ll need to support additional media handling and transcoding. Crucially, you’ll want to do so in a way that retains call metadata.
- Firewall/NAT traversal. To ensure that incoming WebRTC calls can connect through firewalls and traverse NAT you’ll need to implement protocols such as ICE, STUN and TURN.
Your options
WebRTC white paper coverAll this additional functionality is specified across a set of IETF RFCs (6455, 7118, 6347 and 5761). But implementing and testing this functionality is, as I’m sure you’re well aware, a far from trivial task.
Our white paper, Better customer service and easier business communications: Extending the reach of unified communications with WebRTC, outlines the different options available to you for adding support for WebRTC to your product. It also introduces a set of SDKs for WebRTC that Softil is offering specifically for developers of UC products who are looking to implement WebRTC cost-effectively.
