An Introduction to the Avaya WebRTC Snap-In

Over the last several months, I’ve written a number of articles about WebRTC. I discussed encryption, network address translation, signaling, and–over the course of four articles–I even wrote about how to go about creating your very own WebRTC application.


In case you missed any of them, here are all my WebRTC articles to date:

WebRTC for Beginners

A WebRTC Security Primer

An Introduction to WebRTC Signaling

Understanding WebRTC Media Connections – ICE, STUN, and TURN

Writing Your First WebRTC Application Part One

Writing Your First WebRTC Application Part Two

Writing Your First WebRTC Application Part Three

Writing Your First WebRTC Application Part Four


Now that I’ve shared just about everything that I know about WebRTC, I am going to let you in on a little secret. You don’t need to know any of it. All that stuff about ICE candidates? You can forget it. Did you finally figure out how to use the RTCPeerConnection object? You don’t need to know that, either.

Okay, that’s not really true. Understanding ICE candidates and the native HTML 5 WebRTC objects and their methods isn’t a bad thing. It’s just that that bare metal WebRTC programming is pretty sophisticated stuff and a number of people recognized that the interfaces, function calls, and call flows are far more complicated than most people want to deal with – including me.

That’s why companies like Avaya are creating wrapper APIs (application programming interfaces) that hide the complexities of WebRTC. This allows applications to be written faster and with little understanding of the nitty-gritty that happens underneath the covers.

In addition to simplifying the call flows and objects, these wrappers can also add functionality not available in out-of-the-box WebRTC. That’s not to say that a good developer couldn’t write these extensions on his or her own. It’s just that they come “for free” and the programmer can concentrate on the application’s business logic and leave the nuts and bolts to someone else.

The Avaya WebRTC Solution

Today, I would like to introduce you to the WebRTC support offered by Avaya’s Collaboration Environment 3.0. If you are not familiar with Collaboration Environment, I highly recommend that you take a look at this article before proceeding.

An Introduction to Avaya Collaboration Environment 3.0

As you know, a WebRTC application can be divided into three parts. There is the application that runs in a web browser. This part will be written in HTML and JavaScript. There is the web server that delivers the application to the browser. Finally, there is the signaling server that relays information between WebRTC clients.

None of that changes with the Avaya approach. You still need a web server, WebRTC application, and a signaling server. However, unlike a traditional WebRTC application, an Avaya-based application will not call directly into the HTML 5 extensions. Instead, it will use a collection of Avaya objects that invoke those extensions on your behalf. This abstraction greatly simplifies what a programmer needs to know and do.

For instance, the Avaya API handles the work involved in finding and attaching to a STUN or TURN server. It also eliminates the need to create and manage WebSocket connections. This allows the programmer to focus on the business aspects of the application and leave the plumbing to Avaya. It also leads to fewer bugs, since the hard stuff has already been done by really smart people who live and breathe WebRTC.

In addition to making the programmer’s job a lot easier, the Avaya approach adds a layer of security that does not exist in native WebRTC. Specifically, Avaya supports the concept of a security token that assures that only authenticated/authorized users can create and manage WebRTC calls into your communications system. This prevents hackers from perpetrating toll fraud or launching denial of service attacks.

So, how does it work? Let’s start by looking at a diagram of the architecture:

Avaya WebRTC Snapp-In

There are a number of things that should look familiar. First, there is the client. This is a WebRTC-compliant web browser such as Chrome or Firefox. There is also the WebRTC application, which is retrieved from a web server. This application consists of HTML and JavaScript and is sent to the web browser via HTTP. The last familiar piece might be the reverse proxy. A reverse proxy sits between a web browser and a web server and assists in tasks such as firewall traversal, content acceleration, and data aggregation.

If you are an Avaya guy like me, you will also recognize standard Aura components such as Session Manager, Avaya Media Server, Communication Manager, Session Border Controller, and station endpoints.

Less familiar will be the Collaboration Environment server(s) and specifically the WebRTC Snap-in. Think of the Snap-in as the WebRTC signaling server. It accepts HTTP formatted commands from the application and converts them to SIP. These SIP messages will then use Communication Manager to establish and manage voice calls.

The Avaya Session Border Controller provides a secure conduit for the WebRTC application into the enterprise. It relays HTTP from the application to the WebRTC Snap-in and performs STUN and TURN functionality. If desired, an Avaya SBC can also act as a reverse proxy.

The Avaya Media Server terminates ICE, STUN, TURN, and DTLS. It also translates WebRTC media into a SIP media stream.

The Avaya WebRTC Library

Not shown in the above diagram is the Avaya WebRTC JavaScript library. This library contains the API objects that an application will invoke, as well as the code that interfaces with the underlying HTML 5 WebRTC layer. This library can be a part of the application itself, or better yet, it can be downloaded dynamically from the web server when the page is loaded. Downloading assures that the latest and greatest version of the API is always used.

The Avaya WebRTC library is what the developer will see when he or she builds an application. It consists of four sections:

  • Data declarations. An Avaya WebRTC application will use two variables: client and theCall. The client variable is used to describe the client and its connection data and theCall is the WebRTC call.
  • Callbacks are used to communicate between the Avaya API and the WebRTC application. Most of the real work will occur in these callbacks.
  • Configuration code. The client object is configured to describe the client endpoint.
  • The code that connects the application to the WebRTC Snap-in.

For example, the following is an application initiation sequence:

var client;

var theCall;

client = new avayaWebRTC.Client();

client.onConnectedCB = connectedCB;

client.onDisconnectedCB = disconnectedCB;

client.onNotificationCB = notificationCB;

client.onCallConnectedCB = callConnectedCB;

client.onCallInitiatedCB = callInitiatedCB;

client.onCallRingingCB = callRingingCB;

client.onCallRemoteDisconnectedCB = callRemoteDisconnectedCB;

client.onCallErrorCB = callErrorCB;

client.onRemoteMediaConnectedCB = remoteMediaConnectedCB;

client.webRTCHTTPAddress = serverURL; /* Collaboration Environment Server */

client.securityToken = token;

client.username = <caller’s phone number>;

client.username = <caller’s domain>;

client.connect();

Once onConnectedCB has been invoked by the API, the client can now make a call. Code to perform that will look like this:

theCall = new avayaWebRTC.Call(client);

theCall.ringingFileUrl = <optional wav file played after call is launched>;

theCall.destinationAddress = <called number>; /* called number can be restricted */

theCall.ContextID = <Context ID from context store>; /* think of this as caller attached data */

theCall.initiate();

At this point, a call has been launched and the application will receive a series of callbacks as the call progresses. For example, onCallRingingCB will be invoked when the far end is ringing and onCallConnectedCB will be invoked when the call has been answered. The callback, onCallMediaConnectedCB, is invoked when media is received from the far end.

There are additional methods on the theCall object to manage and eventually release the call.

The WebRTC application can call any station type on the Avaya system. This includes H.233, SIP, analog, or digital telephones. These telephones can be standard endpoints or contact center agents. Additionally, the WebRTC application can use the Avaya system to make outbound calls on any trunk type.

The security token supplied by the web server can be used to restrict the types of endpoints that the application can call. For example, it may allow calls to contact center agents, but not outbound trunk calls.

Pay attention to the ContextID variable. When the WebRTC Snap-in is used with the Avaya Context Store Snap-in, caller and web page information can be passed with the call. This allows a contact center agent to know who is calling and from what page — i.e. the context of the conversation. This extension to WebRTC would be invaluable to contact centers that web enable their inbound communications.

In terms of capacity, Avaya states that the Snap-in supports 1800 simultaneous calls at a rate of 28,000 BHCC (Busy Hour Call Completions). The maximum requires a Collaboration Environment server, one Avaya SBC, and eight Avaya Media Servers.

In future articles, I will expand on the Context Store Snap-in along with Avaya’s Real-Time Speech application. Prepare to be amazed.


At this point in time, the API and WebRTC Snap-in only supports G.711 audio. Additional codecs (e.g. Opus) and video will be added at a later date.


That’s all for now

This was meant to be an introduction, so I will stop here. I hope this helps you understand the Avaya WebRTC solution from a high level, as well as get a feel for how the API and Snap-In simplify the job of writing a WebRTC application. It’s important to realize that Avaya hasn’t changed the underlying HTML 5 code – they’ve simply made it easier to use. And for folks like me that can use all the help they can get, easy is a good thing.

Related Articles:

Meet Avaya Breeze—See How We Make Engagement App Development Easier

You may have heard about the Avaya Breeze™ platform, but don’t really know much about it. You may be an active developer using the platform but have questions. So let me introduce Avaya Breeze, explain its APIs and capabilities, and share some tricks for developing Breeze snap-ins (as the apps are called).

The goal of Avaya Breeze is, well, to make application development “a breeze.” As one person said, half the work of developing an app is provided by the platform. Here’s a picture of what Avaya Breeze brings to the application developer:
breeze-snap-in

All About Avaya Breeze Snap-ins

Snap-ins are currently developed in Java (we are looking at adding other languages down the road). The snap-ins run in an industry-standard Java Enterprise Edition (JEE) container. They communicate with the Avaya Breeze platform over an API, and with each other using a Collaboration Bus (the red box in the picture). What makes the platform so friendly to developers are the services provided in the black boxes: data management, serviceability, and security. When snap-ins work together you can build up pretty complex systems, such as:

Combination of snap-ins & end-users, with telephony, web, IM, and presence interfaces | Avaya Breeze

Here we have a combination of many snap-ins and end-users, with telephony, web, IM, and presence interfaces coming into the system. There are several different types of telephony protocols in use, all of which are hidden from the snap-in writer via the Breeze API (which is a nice aspect of the platform). Graphical and REST web interfaces are supported. Snap-ins can define their own interfaces and protocols as well as using the ones provided by Avaya Breeze.

Snap-ins don’t all come from Avaya. Build your own and make money! I look forward to many of you creating snap-ins, and Avaya can help you market them in in our Snapp Store—see what’s there now.

Snap-Ins Work Together

One of the things you will notice in the figure is something called a “cluster.” To support scalability, Avaya Breeze allows great flexibility to group together servers for horizontal scalability. Clusters are homogeneous, where the same snap-ins are loaded into a given cluster. Avaya Breeze load balances the incoming traffic so the snap-in writer can concentrate on the business logic rather than much of the surround. You can have multiple clusters, each with a different set of snap-ins, and the various clusters can send messages or events to each other. Avaya Breeze provides the APIs to make this easy.

Developing Snap-Ins

So what do you need to develop a snap-in? Eclipse is a great environment, and with the Breeze plug-in once you write your code you can easily deploy it. Need data that gets configured by the customer? Breeze attributes are there for you, with you specifying default values. You can have attributes that are read-only, and even some that are hidden from the admin to allow you to easily change things “under the covers.”

Up Next

Stay tuned—in my next post I’ll drill down into the Breeze APIs and development environment.

The IoT Chronicles Part 4: Predictions for 2017 and Beyond

2016 certainly didn’t come up short in terms of tech innovation. From genetically engineered immune cells that can control long-term HIV to plant gene editing that can help prevent diseases and droughts, we’ve seen incredible breakthrough technologies across practically every sector.

Indeed, the year was marked by groundbreaking innovation. However, I’d be remiss in not exploring the Internet of Things (IoT)—slated to bring the most organizational value industry-wide—and how it will significantly shape businesses as they digitally transform.

IoT is Bringing Big Savings

The question isn’t whether the IoT is here. It’s already changing business outcomes, lowering costs, and increasing visibility through workflows improving business processes. As we look ahead, sensors will only become more pervasive, machines more autonomous, and connected technology more capable of sharing knowledge than ever before. As a result, Gartner predicts that IoT will save businesses $1 trillion a year in maintenance and services by 2022.

Considering this, it’s not surprising that the global number of connected devices is expected to reach the trillions, driving 64% of companies to soon adopt IoT. It’s great to see such plans for investment; however, what really matters is how businesses invest in IoT to ensure maximum impact organization-wide and, more importantly, to drive the kinds of outcomes that end-users want and need.

IoT’s Predicted Impact

My intention with this blog series was to set the hype aside and objectively share what organizations need to know about IoT. In keeping with that goal, here are four predictions I have of where the market is heading (and how organizations can stay 10 steps ahead to ensure success):

  1. Companies will work to secure the newly un-defined perimeter—it’s everywhere.
    With the ability to connect millions of new devices, hardware endpoints, and lines of code, it’s not so much about whether companies are securing their networks, but how. In today’s world where virtually anything can be considered part of the IoT, the concept of a fixed network edge has essentially become obsolete. In its place is the concept of borderless networking, a world where a company’s network is neither here nor there, but everywhere.
  2. Looking ahead, I believe more companies will invest in end-to-end network segmentation to secure this everywhere perimeter. Such a solution inherently protects companies from the inside out with three core capabilities: hyper-segmentation, native stealth, and automated elasticity. If you’d like to read more on this, start reading my three-part blog series that breaks down each of these capabilities in detail. In my opinion, end-to-end network segmentation is the future of IoT security.

  3. M2M communications will fuel IoT demand.
    The evolution of communications over the last 50 years and the impact it’s had on traditional business processes is simply astounding. It only took a few short decades for manual processes driven by human-to-human communications to be replaced with smarter, automated processes driven by machine-to-machine (M2M) communications.
  4. Today, for example, utility companies can deploy remote sensors at oil drilling sites to communicate with on-premises machines about variables affecting equipment. When you drive to work every day, chances are sensors are being used to monitor such things as speed and traffic volume to maximize traffic flow. Cars today have so much computing and sensory power that they can now talk to artificial intelligence to troubleshoot themselves, requiring no human intervention. Just look at the work currently being done by Tesla, where a simple software update sent to 60,000 cars allowed drivers to sit back while their vehicles autonomously managed such things as speed, steering, parking and even lane changing.

    Overall, the M2M market is set to experience a 12% CAGR between 2015 and 2020. This massive communications shift will only further drive demand for the IoT and largely influence new capabilities in the future.

  5. The market will hone in on three POVs.
    I believe the market will soon come to realize that successful IoT deployment is not possible without rethinking the entire infrastructure from three critical points of view: security, regulation and provisioning. This means moving away from bimodal styles of working and embracing a holistic, 360-degree approach to the IoT.
  6. This is a sentiment also expressed by Gartner’s Managing VP Daryl Plummer. In his list of 2017 predictions, Plummer states that not only are bimodal exercises designed to “experiment and ‘fail fast,’ but “those that do receive approval for implementation involve a level of complexity, scale and business change ramifications that may not have been considered in the initial planning stage.”

    Businesses must look at the IoT as part of their existing ecosystem; therefore, they must find a way to seamlessly integrate the IoT into their organization as one of many moving parts. In today’s smart, digital world, all lines of business must move at the same pace of innovation to succeed.

  7. Companies will realign IoT with business outcomes.
    If you look at some of the prediction articles out there, you’ll see a lot of pundits saying that although the IoT is a hot buzzword right now, adoption at the business level will remain slow in the years to come. The way I see it, adoption doesn’t have to be slow if companies understand how to deploy and use it correctly, therefore accelerating the endorsement and alignment across the entire organization is critical to its success and impact.
  8. So, what needs to change? The IoT can no longer be seen as simply sensor-installation and heat mapping. It doesn’t matter if a car can self-detect its mileage consumption or if sensors can identify certain traffic volumes and speeds. The question is: how can this information be used to transform outcomes? In other words, how can IoT data be leveraged to actionably improve what’s valued most by those most affected? For instance, how can traffic volume data be used to ease early-morning congestion faced every day by thousands of drivers along a certain highway?

    First and foremost, IoT must be in perfect alignment with business outcomes, otherwise, the technology is being implemented just for the sake of being able to do so. I expect things to level out as IoT normalizes in the years to come.

IoT investment will undoubtedly propel companies forward in today’s smart, digital world. However, this requires time, funds and organization-wide commitment. Plummer, for instance, expects that by 2019, every $1 that enterprises invest in innovation will require an additional $7 in core execution. Remember: it’s not about whether you’re planning to implement IoT, but how you plan to do so.

The IoT Chronicles Part 3: Security Regulation

There’s no denying the transformative power of the IoT (whether or not you’ve read this IoT Chronicles blog series.) Practically every object imaginable today has a smart or connected equivalent: the smart home, connected car, smart city … the list goes on. As we move forward, the IoT will continue to have a powerful effect on the world as we know it, including a tangible return for businesses that are currently investing at a rapid pace. Gartner’s Chief of Research Daryl Plummer, for instance, predicts that the IoT will save consumers and businesses $1 trillion by 2020.

At the same time, however, we also can’t deny that there are certain areas of the IoT that require strengthening. If you read part 2 of this series, then you know where I’m going with this … security. As I mentioned in part 1, we here at Avaya define the IoT as simply having an open scope. In other words, virtually anything can be considered part of the IoT, and so anything is possible. So much uncharted territory, however, also becomes a new frontier for security threats and attacks. In fact, Gartner predicts that by 2020—the same year expected to top trillions in cost savings—more than 25% of identified attacks in enterprises will involve IoT devices.

A concept as groundbreaking as the IoT doesn’t come without certain legal and regulatory implications that must be properly addressed. This leaves us with two important questions: what IoT products should be regulated and, more importantly, who should be regulating them?

To Regulate or Not to Regulate, That is the Question

Let’s tackle the first of these two questions: which IoT products should be regulated to minimize security risks? The short answer is there’s no definitive answer. Instead, we must use our judgment based on the nature of the product or device in question. While every IoT product generates and shares data, we know that there are varying levels of sensitivity among these different sets of data.

For instance, consider Samsung’s “Family Hub” smart refrigerator. The product has a Wi-Fi-enabled touchscreen that lets families manage their groceries and sync up their schedules, as well as built-in cameras that snap and send photos of what’s in their fridges so they can see what’s running low. This product certainly generates and stores its fair share of data; however, should a family’s fridge be regulated? That is, should someone be controlling the data that the product generates, stores and shares? You may think not—however, just consider last year security researchers proved a way to hack the “Family Hub” fridge to steal users’ Gmail account information, despite the object implementing SSL. The successful man-in-the-middle attack proves that any connected object can be strategically used for criminal purposes.

It all comes down to what information could be exposed when we choose not to regulate (or implement the necessary level of security for) an IoT product. Do we really need to know that a family is running low on milk? No, but we do need to know if that family’s Gmail credentials are vulnerable to theft. Now, imagine if someone were to discover such a security loophole in the smart grid? It just goes to show that every IoT object must be regulated to some degree, and these degrees will vary. Even when it comes down to two IoT products that should be regulated—say, a smart grid and a smart vehicle—each product must be regulated differently. As I have mentioned throughout this series, following status quo protocols or implementing a one-size-fits-all strategy is not suitable. While I do believe the IoT must be regulated, applying the same regulatory policy nationwide would look a lot like trying to boil an ocean.

Ultimately, what it comes down to is this: we must define and implement regulatory best practices depending on the IoT product or device at hand. Each product will have a different set of security requirements, and so each will need to be regulated differently. Certain products will require higher or lower levels of encryption, for instance, while others complete segmentation. How a product is regulated—that is, if it’s even regulated at all—will depend on its unique security requirements.

Now for the second (and more debatable) question: who should be regulating IoT security? Specifically, should the government step in?

Self-Regulation vs. Government Regulation

If you follow the IoT in the news, then you’re likely aware of the massive debate going on as to whether the government should have a hand in security regulations. If not, allow me to provide a brief recap: In a November 16, 2016 hearing—prompted by the October 21, 2016 DDoS attack on Dyn—cyber security experts discussed the hard work that lies ahead for the IoT and debated the level of involvement that government entities should have in helping promote and create security standards.

Some experts advised the government to mandate IoT security measures before vulnerabilities cause unthinkable damage. Meanwhile, other experts believed that industries should have a chance to regulate themselves, saying that government should step in only if those efforts prove ineffective.

Overall, the experts claimed that the IoT poses “a real [catastrophic] risk to life and property.” This may be true (as there’s no piece of technology today that doesn’t pose some sort of risk), but does this mean the government should start standardizing security or applying industry pressures? Would these “standards” infringe on the privacy of users? Would these industry pressures adversely affect the vertical-specific nature of the IoT? I’d say so, and I’m not alone in my thinking.

Travis LeBlanc, the FCC’s chief of the Bureau of Enforcement, similarly agrees that prohibiting industries from self-regulation is a dangerous move. In fact, during a November 1, 2016 discussion on IoT security, he stressed that overregulation right now, at such an early stage, would “constrain the innovation of the future in ways that no legislator ever intended.”

When it comes to government regulation, what’s considered acceptable and unacceptable drastically differs based on the person being asked. I myself am of firm belief that standardizing IoT security will be nothing short of disastrous. Every industry’s relationship to the IoT—from opportunities for innovation to security requirements—is unique and must be tackled differently. As of right now, self-regulation remains a responsibility that industry leaders should take very seriously.

While there’s no one-size-fits-all approach to securing the IoT, there’s one thing organizations within virtually every industry should be doing: making sure the network traffic between their IoT devices is truly isolated so that unauthorized users can’t see or access it. Machine-to-machine IoT communications need to have session authentication. The way in which we communicate is changing. We used to start with human-to-human, but that’s been pushed down to third- and fourth-level communications. Now it looks like this: machine-to-machine, machine-to-AI, machine-to-human, followed by human-to-human. If this doesn’t call for something uniquely different to tackle security, what does?

Isolation of services is something that can be achieved with an end-to-end segmentation solution, which allows businesses to create stealth, extensible hyper-segments that span their entire network. If you’re not exactly sure what this is all about, you can check out a three-part blog series I recently wrote that breaks down everything for you.

We’re not done yet: In the upcoming final part of this series, I’ll explore the future of the IoT and share my top trends and predictions for 2017. Stay tuned.