AudioCodes’ WebRTC gateway solution bridges the gap between current and new without compromising either side.
I stir up controversy every time I say this, but I will say it anyway. WebRTC does not define a signaling protocol. This means that developers are free to use whatever method or protocol they want when they create their solutions.
There are several reasons why the WebRTC designers chose this path, but they all essentially boil down to the same thing. Defining a signaling protocol limits WebRTC's flexibility in how it can be deployed. Having a prescribed protocol might preclude some devices and solution types.
Of course, we live in a communications world that is built on "sameness" and interconnectivity. For the first half of my career, I used nothing but analog and digital connections. While nearly every interface had its variations, I was confident that I could connect any PBX to any ISDN trunk and be assured of making and receiving calls.
For the last 10 to 15 years, IP has been slowly replacing those older technologies and most enterprises have either implemented SIP trunks or have them on their roadmap. Yes, there have been issues with SIP variants, but session border controllers understand the variations and just like those old TDM trunks, everybody can talk to everybody.
Now we have a new kid in town, and he isn't anxious to play by the old rules. WebRTC wants to shake things up and push people out of their comfort zones.
Of course, the "old guys" are not going to just roll over and play dead. Enterprises have invested a lot of money, resources, and mindshare into their existing communications infrastructures and are not about to replace them without first seeing a sound business case.
That's not to say that they don't recognize the compelling value statement around WebRTC. They simply want to strike the right balance between what works today and where they see the world headed.
AudioCodes recognized the need to bridge existing communications systems with web-based interfaces when it enhanced its line of session border controllers with WebRTC gateway functionality. For instance, this new feature allows an enterprise to add click-to-call functionality to their webpage while maintaining traditional telephone sets for its knowledge workers and contact center agents.
The AudioCodes solution is based on the fact that most enterprises have moved to SIP or have SIP-ready systems. This allows them to eliminate many of the servers and telephony adjuncts that would be required to convert Web-based communications to a traditional voice solution of call servers, TDM gateways, and physical endpoints.
Previous attempts to integrate WebRTC and a traditional PBX looked something like this:
Take note of all the moving parts required to support the many facets of WebRTC. You need to deal with signaling, media, security, and authentication -- and no one device does all four.
The AudioCodes integrated approach looks like this:
As you can see, one appliance performs the necessary gateway functionality for signaling as well as media. There is no need for a hodgepodge of disparate servers and services. If necessary, transcoding (e.g. Opus to G.729) is also available. This essentially makes every IP PBX WebRTC ready.
Speaking of signaling, AudioCodes chose SIP over WebSocket. This allows WebRTC developers to use JsSIP (an open source SIP implementation for Web developers) to establish calls between a webpage, the AudioCodes SBC, and ultimately, a traditional communications platform. JsSIP greatly simplifies SIP development and ultimately allows the webpage to take on the characteristics of a lightweight SIP endpoint (or user agent in SIP parlance).
Just the Facts Ma'am
Among the characteristics and features of the AudioCodes WebRTC gateway are:
- Support for the narrowband G.711 and wideband Opus audio codecs to and from the WebRTC client
- The ability to transcode Opus to legacy audio codecs (e.g. G.729, G.722, etc.)
- Support for ICE (Interactive Connectivity Establishment) and STUN (Session Traversal Utilities for NAT)
- Encrypted media channels with Datagram Transport Layer Security (DTLS) for Secure Real-Time Protocol (SRTP) key exchange
- SRTP for secure media transmission
- RTP multiplexing
- Secure Real-Time Control Protocol (SRTCP) with immediate feedback – i.e. support for SAVPF
If you are versed in WebRTC technology, you will see that this is a very complete solution. Developing to the AudioCodes platform takes nothing away from the overall solution.
A Day in the Life
Allow me to walk you through a typical AudioCodes WebRTC call flow.
- A user navigates to a company's website -- let's call her Claire.
- The webpage presents Claire with a click-to-call form. Optionally, it may ask Claire to login with her user name and password.
- Claire invokes click-to-call to speak to a live agent.
- A WebSocket connection is created between the webpage and the AudioCodes WebRTC gateway. This connection will be used to send and receive SIP signaling.
- Using standard ICE methodologies, a workable IP address is negotiated.
- A secure media stream is negotiated.
- A SIP call is established between Claire, the WebRTC gateway, and a contact center agent.
- Media flows between the WebRTC client and the agent.
Pretty straight forward, isn't it? Claire's call into the contact center is treated exactly the same as if she picked up a "real" telephone and dialed an actual telephone number. That's the beauty of the AudioCodes' solution -- WebRTC functionality that bridges the gap between current and new without compromising either side.
Before you get click-to-call too stuck in your head, AudioCodes goes well beyond point-to-point calls. For example, click-to-create-conference, click-to-join-conference, click-to-chat, click-to-initiate-callback, and nearly every other click-to scenario is possible. Like WebRTC itself, the AudioCodes gateway enables rich communication from any HTML5 capable container.
Bringing It All Back Home
It is important to know that none of what AudioCodes has done violates the spirit or technical aspects of HTML5 and WebRTC. Developers will create WebRTC applications exactly as they would for any other platform. They will, of course, use JsSIP for signaling, but since WebRTC doesn't define a signaling protocol, there is nothing wrong with choosing SIP to accomplish that.
Something tells me that that last sentence will once again stir up the hornet's nest. Oh well, bring it on!
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.
Hear more from Andrew this week at Enterprise Connect Orlando 2015, at the Thursday morning session, Interoperability: Has Anything Actually Worked?
Follow Andrew Prokop on Twitter and LinkedIn!
Andrew Prokop on LinkedIn