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:

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.

The IoT Chronicles Part 2: Three Big Security Threats—and How to Solve Them

With projected market revenue of $1.7 trillion by 2020, the Internet of Things (IoT) stands to forever change the world as we know it. In part 1 of this series, I demystified the IoT and explored how leaders can create a vertical-driven strategy that produces positive and proactive business outcomes. Your strategy won’t get you far, however, if it doesn’t explicitly address the unique security threats that are inherent to this level of connectivity.

These kinds of threats aren’t easy to identify or mitigate, which is exactly why nearly 60% of companies say they plan to eventually implement the IoT (i.e., once security no longer concerns them) and why nearly 30% have no plans to implement the IoT at all, but this is likely to change quickly.

With the number of connected “things” growing, it’s expected that more hackers will feed off the ever-growing possibilities to attack, threaten and compromise business. Consider the recent IoT-driven DDoS attack on Internet performance company Dyn, which disrupted websites like PayPal, Spotify and Twitter. Dyn’s Chief Strategy Officer admitted last month that some of the traffic that attacked the company came from compromised IoT devices.

As I continue this four-part IoT crash course, I’d be remiss in not discussing security. Having said that, here are three massive IoT security threats we’re seeing today (and how to expertly address them):

  1. Personally-owned devices:

    Research shows that about 40% of U.S. employees at large enterprises bring their own device(s) to work, and 75% of companies currently permit or plan to permit BYOD in the workplace. Today, there’s a clear need among businesses to securely connect these personally owned devices that simultaneously perform multiple functions and connect to public, private and hybrid clouds. It may be easy to secure enterprise IoT, but this gets a lot trickier when you factor in the devices employees are using on your network. Just consider the 10 million Android devices that were infected this summer with Chinese malware.

    My suggestion: implement some sort of malware detection mechanism and deliver some level of automation that can quickly detect abnormalities on employee devices and prevent them from spreading.

  2. Open APIs:

    An open API model is advantageous in that it allows developers outside of companies to easily access and use APIs to create breakthrough innovations. At the same time, however, publicly available APIs are also exposed ones. Promoting openness means anyone can write new APIs (which is a good thing), but that can cause some challenges in the market. If an organization has undocumented features of its API, for instance, or if someone is rolling out an API and doesn’t have it properly documented or controlled, hackers can potentially take advantage. At the end of the day, businesses must be cautious as to what is being exposed and documented when writing APIs.

  3. Influx of data:

    The amount of data being gathered from today’s ever-growing number of connected “things” is simply astounding. In fact, research shows that about 90% of all data in the world today was created in just the past few years (2.5 billion GB of data were being produced every day in 2012 alone!) While big data has the potential to transform internal processes and the customer experience, leaders must ensure they have the right infrastructure in place to securely distribute and store the massive amount of data that flows through their organizations daily.

    My suggestion: have a solid understanding of how much data your network can handle (never overestimate your network capabilities) and plan to scale accordingly. Also, know the origination of your data and what privacy regulations you might need to take depending on the industry in which you operate. Healthcare, for example, must abide by very strict regulations. Be sure to also keep in mind the legality of where you store your data, depending on where that data comes from. Countries like Germany, for instance, have strict privacy laws that others don’t.

The One Thing to Remember

Here’s the thing business leaders must keep top of mind: although the possibilities for data compromise are growing, they’ll never become realities with network security solutions offered from the right provider. This doesn’t mean your security concerns aren’t valid. It simply means that, with the right technology, there’s no longer a reason to let those concerns prevent you from tapping into the immeasurable growth brought about by the IoT.

So, what’s my final suggestion? Organizations should consider a layered approach:

  • Phase I: Analyze, monitor and inspect.
  • Phase II: When classifying a device as suspect, isolate it to a different segment and perform forensic analysis.
  • Phase III:
    • Quarantine the device if known malware is detected and identified.
    • If the cause is unknown/unidentified, maintain isolation in a honeypot—a quarantine zone to understand malware—and deploy counter measures as soon as possible once a fix becomes available.
  • Phase IV: Once malware is clearly identified, quarantine all devices potentially infected while informing the end users and LOBs impacted.

For Phases II and III, invoke an automated sophisticated workflow to notify the right team for just-in-time analysis.

To properly execute on these phases, you need an automated and more secure networking foundation. The legacy client-server is simply not suitable for this new IoT world. Whatever services your connected devices or systems provide, do whatever you can to ensure they are logically segmented on your infrastructure. This is something that can be achieved through end-to-end network segmentation.

An end-to-end network segmentation solution eliminates nodal configuration by leveraging end-to-end Virtual Services Networks (VSNs). This allows businesses to provision their networks only at specific points of service, where those services are being consumed by end users or devices. Ultimately, end-to-end segmentation transforms your network core into an automated and intelligent virtualized transport. Your network segments will be stealth to hackers, flexible for secure and authorized use, and truly isolated from one another. These core capabilities nearly guarantee network security no matter what devices your employees are using, how much data they are generating and sharing, or what APIs are being written.

Your network security strategy will never be effective if your underlying architecture isn’t what it needs to be. In my opinion, end-to-end network segmentation is the most effective way to minimize and control the inherent security risks of the IoT. And the best news is that there are end-to-end segmentation solutions proven to deliver next-generation IoT security—even for companies still leveraging aging infrastructure. The technology is possible, real and waiting to be utilized.

As we move forward with the IoT, we must ensure security is always top of mind. There are a set of best practices that organizations must implement to substantially reduce the risks associated with IoT deployment. Keep in mind, there are no immune systems, but understanding the risks and minimizing the potential business impact is key. In the end, status quo will likely be a disaster for organizations endorsing the IoT at a rapid pace—changes to legacy practices and infrastructure are a must! Thankfully, technology advancements can provide the connectivity, stability and security required to enable companies to take advantage of the opportunities provided by the IoT.