No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Avaya Makes WebRTC as Simple as Point and Click

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:

  1. The WebRTC standard has yet to be solidified.
  2. Neither Apple nor Microsoft has embraced WebRTC.
  3. The WebRTC operating environment isn't fully defined. For example, there's no standard way to implement signaling.
  4. WebRTC applications are difficult to write.
  5. Different Web browsers support WebRTC functionality in their own ways.

Those are a lot of negatives for something that is supposed to replace communications as we know it today. While the first two items are out of the hands of any one particular organization, the remaining three offer up plenty of opportunities for a clever company.

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."

I need to make it clear that Avaya hasn't redefined WebRTC. If you're familiar with WebRTC, you've probably heard about such things as STUN and TURN servers. You may have even heard of JavaScript Session Establishment Protocol (JSEP). The Avaya approach uses everything that the WebRTC specification says you're supposed to use. The trick is that the Avaya solution hides all the gory details from the application designer. Avaya is 100% compliant with WebRTC, and has taken complete responsibility for all the hard parts.

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.
  • WebRTC Application - This is a Web page that exposes communications functionality like call-me or click-to-call. A WebRTC application is written in HTML and a programming language called JavaScript. The application's JavaScript uses the embedded WebRTC functionality supplied by HTML5 to make voice, video, and data calls.
  • 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.
  • WebRTC Wrapper API - This is a collection of JavaScript objects that surround the standard WebRTC objects and abstracts them into a much simpler form. This item is not part of standard WebRTC.

In essence, the Avaya solution is a collection of libraries and services that implement the functionality of the signaling server as well as the wrapper API. It's completely standard WebRTC, while filling in the many gaps in the WebRTC specification.

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."

The Avaya wrapper API is the answer to my wish. It takes the somewhat convoluted processes of establishing a signaling connection, working with private IP addresses, and calling from one client to another, and turns them into a few simple lines of JavaScript. At the same time, it deals with all the idiosyncrasies that come from the fact that Chrome doesn't implement WebRTC in the same way that Firefox does. The Avaya wrapper allows me to write my application once and run it unchanged on any WebRTC-compliant browser.

Signaling
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.

Security
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.

Caller-Attached Data
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.

Mischief Managed
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.

  • WebRTC Application - This is a Web page that exposes communications functionality like call-me or click-to-call. A WebRTC application is written in HTML and a programming language called JavaScript. The application's JavaScript uses the embedded WebRTC functionality supplied by HTML5 to make voice, video, and data calls.
  • 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.
  • WebRTC Wrapper API - This is a collection of JavaScript objects that surround the standard WebRTC objects and abstracts them into a much simpler form. This item is not part of standard WebRTC. In essence, the Avaya solution is a collection of libraries and services that implement the functionality of the signaling server as well as the wrapper API. It's completely standard WebRTC, while filling in the many gaps in the WebRTC specification.

    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."

    The Avaya wrapper API is the answer to my wish. It takes the somewhat convoluted processes of establishing a signaling connection, working with private IP addresses, and calling from one client to another, and turns them into a few simple lines of JavaScript. At the same time, it deals with all the idiosyncrasies that come from the fact that Chrome doesn't implement WebRTC in the same way that Firefox does. The Avaya wrapper allows me to write my application once and run it unchanged on any WebRTC-compliant browser.

    Signaling
    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.

    Security
    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.

    Caller-Attached Data
    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.

    Mischief Managed
    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.

  • 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.
  • WebRTC Wrapper API - This is a collection of JavaScript objects that surround the standard WebRTC objects and abstracts them into a much simpler form. This item is not part of standard WebRTC. In essence, the Avaya solution is a collection of libraries and services that implement the functionality of the signaling server as well as the wrapper API. It's completely standard WebRTC, while filling in the many gaps in the WebRTC specification.

    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."

    The Avaya wrapper API is the answer to my wish. It takes the somewhat convoluted processes of establishing a signaling connection, working with private IP addresses, and calling from one client to another, and turns them into a few simple lines of JavaScript. At the same time, it deals with all the idiosyncrasies that come from the fact that Chrome doesn't implement WebRTC in the same way that Firefox does. The Avaya wrapper allows me to write my application once and run it unchanged on any WebRTC-compliant browser.

    Signaling
    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.

    Security
    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.

    Caller-Attached Data
    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.

    Mischief Managed
    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.

  • 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.
  • WebRTC Wrapper API - This is a collection of JavaScript objects that surround the standard WebRTC objects and abstracts them into a much simpler form. This item is not part of standard WebRTC. In essence, the Avaya solution is a collection of libraries and services that implement the functionality of the signaling server as well as the wrapper API. It's completely standard WebRTC, while filling in the many gaps in the WebRTC specification.

    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."

    The Avaya wrapper API is the answer to my wish. It takes the somewhat convoluted processes of establishing a signaling connection, working with private IP addresses, and calling from one client to another, and turns them into a few simple lines of JavaScript. At the same time, it deals with all the idiosyncrasies that come from the fact that Chrome doesn't implement WebRTC in the same way that Firefox does. The Avaya wrapper allows me to write my application once and run it unchanged on any WebRTC-compliant browser.

    Signaling
    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.

    Security
    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.

    Caller-Attached Data
    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.

    Mischief Managed
    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.

  • WebRTC Wrapper API - This is a collection of JavaScript objects that surround the standard WebRTC objects and abstracts them into a much simpler form. This item is not part of standard WebRTC. In essence, the Avaya solution is a collection of libraries and services that implement the functionality of the signaling server as well as the wrapper API. It's completely standard WebRTC, while filling in the many gaps in the WebRTC specification.

    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."

    The Avaya wrapper API is the answer to my wish. It takes the somewhat convoluted processes of establishing a signaling connection, working with private IP addresses, and calling from one client to another, and turns them into a few simple lines of JavaScript. At the same time, it deals with all the idiosyncrasies that come from the fact that Chrome doesn't implement WebRTC in the same way that Firefox does. The Avaya wrapper allows me to write my application once and run it unchanged on any WebRTC-compliant browser.

    Signaling
    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.

    Security
    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.

    Caller-Attached Data
    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.

    Mischief Managed
    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.