Avaya Makes WebRTC as Simple as Point and Click
The Avaya WebRTC Snap-in offering is an end-to-end solution that turns WebRTC into a scalable, secure, and practical tool to Web-enable your communications. Or said in a different way, it turns hype into reality.
I've been in this industry long enough to be wary of hype and irrational exuberance. How many of you are old enough to remember analog mobile phones or when ATM meant asynchronous transfer mode and not the ubiquitous cash-dispensing machine? I am, and I remember how they were slated to revolutionize communications. Well, they didn't.
The same can be said for video. Although I still hold out hope for a much broader penetration, it has yet to become as important as dial tone. Clearly, seemingly good ideas don't always translate into user acceptance and marketplace success.
WebRTC is one of those technologies that will either be wildly successful or take its place in the "nice attempts" graveyard. Personally, I would love for it to achieve the former, but a number of factors are working against it.
Here are the WebRTC challenges as I see them:
- The WebRTC standard has yet to be solidified.
- Neither Apple nor Microsoft has embraced WebRTC.
- The WebRTC operating environment isn't fully defined. For example, there's no standard way to implement signaling.
- WebRTC applications are difficult to write.
- Different Web browsers support WebRTC functionality in their own ways.
Enter Avaya and its WebRTC Snap-in. Actually, it would be more accurate to say, "Enter Avaya and its impressive solution for enabling a simplified, easy to use, and more feature-rich approach to WebRTC – which happens to be built around its WebRTC Snap-in."
Before I go too much further, allow me to define a few general terms:
- WebRTC Client - This is a WebRTC-compliant Web browser such as Chrome, Firefox, or Opera.
- Web Server - A WebRTC application is stored on a Web server and is downloaded to a client when the user navigates to the appropriate URL.
- WebRTC Signaling Server - A signaling server is used to allow one WebRTC client to communicate with another WebRTC client. The server relays information between clients (IP addresses, ports, codecs, commands, etc). The WebRTC specification states that such a server must exist, but it does not define what that server is or provide guidelines as to how it should be written.
Putting a Wrapper on Complexity
When I first wanted to understand how WebRTC worked, I did what any good geek would do: I wrote my own application. Granted, it wasn't incredibly sophisticated, but I could make a video call from one Web browser to another, and that was good enough for me.
Besides having a communications application to demonstrate to my friends and coworkers, I walked away from that experience with something even more valuable than bragging rights. I learned just how complicated it is to write a WebRTC application -- I had to pay too much attention to too many different things, and all the while I kept saying to myself, "There has to be an easier way to do this."
When I wrote my application, I built a bare-bones signaling server from open source that I found on the Internet. It did what I wanted it to do, but it wasn't scalable or secure, and it was limited to browser-to-browser communication. While that's fine for a demonstration, the real power in WebRTC lies in calling from a Web browser to an actual telephone. That's how you would implement WebRTC in a contact center, and my simple application was worthless in that realm.
The next big thing that comes from Avaya is the signaling server that it calls the WebRTC Snap-in. This Snap-in is a service that runs on an Avaya Collaboration Environment server. It allows a WebRTC application to call an Avaya endpoint or use the Avaya system to call out to the PSTN.
In addition to being a signaling server, the Snap-in acts like a gateway that converts HTTP from the WebRTC application into SIP. This essentially makes the Snap-in look like a SIP trunk to an Avaya Session Manager, and ultimately, a Communication Manager. This enables a Web browser to call an Avaya endpoint, or in some cases, invoke the services of an outbound trunk. This is where the power and money in WebRTC lies.
The WebRTC specification defines aspects of security in terms of signaling and media, but no authentication mechanism has been provided. By this, I mean that there are no processes to validate who or what a WebRTC application can call.
Avaya rectifies this problem with something it calls a security token. The Web server generates this token in conjunction with the WebRTC Snap-in and uses it to limit what a WebRTC user can do. For example, the token might allow calls to contact center agents, but prohibit trunk calls to outside numbers. Without such a mechanism, an enterprise would open itself up to toll fraud and denial-of-service attacks.
The Avaya solution fills yet another hole in the WebRTC specification. It uses the Avaya Context Store Snap-in to attach caller data to the WebRTC call. With the Context Store Snap-in, a contact center agent can know who is calling and from what particular page the caller invoked WebRTC. This allows the agent to know the difference between a general information call and one about a specific product – e.g., men's bootcut jeans.
I've spared you the architectural details of the Avaya approach, but unless you're tasked with installing the servers and connecting them to one another, those details aren't necessary. The point of this article is to introduce you to the moving parts as seen by the application developer and the end user.
If you walk away with anything from my missive, I want it to be these two thoughts: First, the Avaya WebRTC solution greatly simplifies the process of developing and rolling out a WebRTC application. Instead of dwelling on SDP and WebSocket, the developer stays focused on the business logic of the application.
Second, the Avaya solution creates a business-ready platform by addressing many of the gaps and shortcomings in WebRTC. Using the WebRTC Snap-in, wrapper API, and Context Store Snap-in, developers can create practical applications that deliver quantifiable results today.
If you're serious about WebRTC, you need to be serious about your platform. The Avaya offering is an end-to-end solution that turns WebRTC into a scalable, secure, and practical tool to Web-enable your communications. Or said in a different way, it turns hype into reality.
Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.