1 Answer to WebRTC Signaling

1 Answer to WebRTC Signaling

[Post is better viewed on the blog Website]

A lot of opinionated information has been written about the debated topic of WebRTC signaling. An example of a good and well-balanced technical post is WebRTC Hacks, written by Victor Pascual.

I am excited to be participating in a panel on this topic next week at WebRTC Global Summit in London and I thought it would be a good idea to provide some points about this topic beforehand. If you happen to be around please come and pay us a visit, we are at booth #6.

What is the debate about?

There are 2 fundamental items the industry is debating about:

  • Should WebRTC define signaling
  • When building a product/service should signaling be based on existing standard or proprietary protocols

The answer to the first question is easy. Since WebRTC was born to serve Web developers, not Telecom VoIP geeks, one would never be able to imagine what WebRTC could be used for. This fact requires taking the “less is more” approach and define only the minimal must, thus, leave signaling out of the WebRTC definition scope and put it in the hands of those building each specific solution.

The second question seems more complex as is testimony to the many opinions out there. Some think proprietary JSON-based signaling is the only answer. Others think standard signaling is the answer pitching to go for SIP or XMPP. Another opinion I enjoyed debating about at the WebRTC 2013 conference in Paris was that WebRTC was “born” for IMS (needless to say I didn’t support that point of view).

1 Answer to WebRTC Signaling

So what is the 1 answer for WebRTC signaling?

If it wasn’t clear to this point, the answer is simply – it depends.

The decision of what signaling to use when building a product or a service depends on its nature and the solution for which it was designed for.

The primary distinction required for deciding if a standard or proprietary approach fits best is whether the solution goes into a service island or if it needs to connect with an existing VoIP network.

In the case of a service island, proprietary signaling will typically be chosen because it is the easy approach, however, if advanced telephony functions, already well defined in standard protocols such as SIP are required, there is no point in reinventing the wheel. It is perfectly OK to pick and choose the functionalities of SIP needed in the implementation and ignore the rest.

On the other hand, if the solution is about allowing WebRTC service to connect with existing standard VoIP networks such as SIP the natural signaling choice would be SIP.

Last but not least, if you are providing an end-to-end solution that includes the WebRTC clients as well as the server, whatever signaling is hidden under the hood doesn’t really interest the developer building the application. What does interest the developer is how simple it is to use your APIs for integrating your client into his product.

It would be interesting to get your comments to this post detailing your view on this subject and how you decided to deal with this matter in your implementation.

Small Businesses - Big Opportunity

SMALL businesses, BIG opportunity

[Post is better viewed on the blog Website]

Small Businesses - Big OpportunityI recently read an article about the importance of small medium businesses (SMBs) and their benefits to countries’ local economies, and wondered how this is reflected in local communication services deployed in those countries.

There is no doubt that VoIP technologies have changed the communications world and the way that Communication Service Providers (CSPs) do business. Still, looking at the SMB segment (I refer here to companies with more than 4 and less than 250 employees), it seems that out of a total of 75 million worldwide SMBs, only 12 million are connected to VoIP services and the rest are still using legacy TDM lines.  Clearly, there is huge opportunity here for CSPs as well as for VoIP equipment providers.

According to an internal analysis we conducted in AudioCodes, based on market research reports we expect that by 2017 the number of SMBs connected to VoIP services will more than double to 25 million with an average annual growth of more than 3 million every year!!!

Worldwide SMBs connected to VoIP Services

In the past, the needs of SMBs were quite modest in comparison to those of the enterprise. But this is changing – and fast. The communications needs of SMBs have grown far beyond a managed PBX and an Internet connection. The increasing awareness of the need for data and cloud services, together with the availability of affordable platforms, encourages SMBs to acquire advanced communication services that will help their businesses grow.

Win the SMB market with QoE Ingredients

When facing SMB customers, CSPs need to take into consideration that these SMB customers are limited in their budgets and do not have the technical resources as do enterprises. At the same time, CSPs understand that in order to succeed in the SMB space, they must offer a compelling service bundle for the right price, and probably, the most important factor will be QoE.

We need to remember that even if in most cases the SMBs let the CSPs manage their communication services, they are fully aware of the importance of these services and the critical impact they can have on their business.  Accordingly, they carefully evaluate these services when interacting with CSPs. SMBs expect their businesses to be always available, with no less than excellent voice quality and fast Internet service. They expect a productive environment for their employees with suitable and accessible data tools and they are very concerned about security. And, of course, the solution must be affordable.

Business Communications Needs

Faced with this significant opportunity, CSPs are challenged to provide SMB customers with the expected QoE starting with the on-premise business routers. Using the right business routers with features such as business continuity and consistent performance, will allow CSPs to deploy data and voice services with high QoE that will help them to capitalize on these opportunities.

More information can be found in the “Big Solutions for Small Business” white paper and at AudioCodes Multi-Service Business Routers Page (http://www.audiocodes.com/msbr)


all you need is cloud

All You Need is Cloud

[Post is better viewed on the blog Website]

all you need is cloudI recently read the post from Software Advice called 3 Ways to Keep Your VoIP Service From Going Down With the Internet by Don Sadler. Overall it, was music to my ears, hence the title of this post.

Many people fall in love with the concept that going cloud with your enterprise telephony system means the end of all of your telephony worries.

The reality is more complicated, however.

Don’t get me wrong, putting your enterprise communications in the cloud is the right way to go. Yet life is a bit more complex than pure cloud vs. pure on-premise. The grey area between them is what complicates things.

The misconception of pure cloud

Starting to use an enterprise communications cloud service would basically require the following steps:

  • Register for the service and pay with your credit card
  • Upload an Excel file with all users and extensions
  • Start talking

This would pretty much be all that is required for a greenfield, a one location business with a few guys that are using an application on their mobile phones for their business telephony operations. But what if you are an enterprise, large or SMB, with multiple locations and an existing telephony system?

In such a case there will be a few requirements that will complicate things. A non-exhaustive list of these requirements include:

  • Gradual migration to the cloud
  • Call flow optimization (e.g. when 2 users are calling in the same premise)
  • Cost optimization when calling to PSTN
  • Resiliency

Gradual migration to the cloud

Typically, IT will not pull the plug on the current on-premise system and plug in the cloud service instead. They would run a test on one site, then expand to a multi-site pilot and only after a few months make the switch. What happens during this pilot phase and how are the 2 systems connected?

Moreover, in some deployments, IT may decide to maintain the old system for a longer period.  This may be due to technical or business reasons. Supporting this requirement will typically be achieved by deploying an on-premise SBC that will connect the 2 networks and make this integration transparent to the end user.

Call flow optimization

In the pure cloud approach, when all you have on-premise are IP Phones or an application on your smartphone, for example a phone call from John to his colleague next door, Alice, would see the signaling going through the cloud.

How about the media?

Would it go directly between John and Alice or would it need to go all the way to the cloud provider and back?

The answer is… it depends.

There are various factors that will determine the media flow in such a case. The key requirement for the cloud provider to technically be able to enable direct media is to know John and Alice are located on the same network. This can be achieved by simply having one “leg” of the cloud SBC in the enterprise network, something that introduces a security vulnerability or through an on-premise “component” that will figure this out. In real world deployments, all of these options exist.

Cost optimization when calling to PSTN

Do you want all calls to the PSTN to go out from the cloud provider’s network or perhaps you have better PSTN termination agreements in some areas where you also have a local branch? Would you want to route calls to the PSTN in that calling area through your local branch?

Achieving this will require some extra routing logic and an on-premise GW in the branch office.


This brings us back to Don Sadler’s post that talks about resiliency requirements for hosted communication services. Resiliency will keep communications alive even if the cloud provider’s service goes down or if there is a problem with the company’s connection to the provider. Having an on-premise cloud appliance will ensure continuity of communications between extensions in the branch, calls to the PSTN and routing of calls through a backup Internet connection (e.g. cellular).

Enterprise Hosted Services Architecture

A typical hosted enterprise communication services architecture


If you are in process of architecting your move to the cloud, it is important to remember that as VoIP cloud deployments move from MPLS to non-dedicated lines over the Internet, the level of control in the hands of your cloud provider is reduced. As such, having an on-premise demarcation point becomes essential. Solutions that enhance cloud communication services are available on the market. Audiocodes, as part of its One Voice for Hosted Services, offers such solutions specifically for Broadsoft deployments as well as for other hosted VoIP and UC deployments.

Featured image credit: Paula Izzo
Active Passive Networks Monitoring

VoIP Network Monitoring Approaches: Which Way to Go?

[Post is better viewed on the blog Website]

As voice networks evolve into all IP frameworks and with the understanding that the organization’s voice networks become dependent on many factors which are not directly correlated with the voice network itself, it becomes clear to any IT organization that proper monitoring tools are required to maintain the quality of experience of the end users. But what is the right approach for monitoring the voice network?

Active Monitoring

Active Passive Networks MonitoringIn the past, in order to properly conduct end-to-end quality monitoring, you had to incorporate testing equipment into your environment, inject VoIP traffic on top of the existing VoIP network, collect traffic statistics and then start troubleshooting the problem. This method was known as “Active Monitoring”. But this approach had some significant drawbacks. It could not, for example, track existing calls running in the network. If an end user complained about a problem, there was very little that could be done to manage this complaint effectively.  Another problem is that you had to install additional hardware in the locations in which you wanted to test the traffic. In large-scale deployments, this could render the costs of a monitoring solution unacceptable. Active call generators would have to be moved from one place to another which would clearly cause a delay in troubleshooting and resolving the problem. To illustrate, if there was a complaint in New Jersey but the call generator was currently placed in Boston, the call generator would need to be shipped to New Jersey before the troubleshooting process could begin. On top of that, the extra probe adds more traffic to the underlying network which tacks on another factor of uncertainty. Will the existing network traffic running the call generator be affected by this addition? Will it further worsen the existing problems?

Passive Monitoring

It was clear that an alternative means of monitoring was required and this led to the introduction of passive monitoring. “Passive Monitoring” is a method in which a network is configured to mirror ongoing traffic to a passive probe which then looks at the entire set of the packet stream and can provide statistics based on the collected information. This approach clearly solves the problem where there was a need to check a specific end user’s complaint. It also does not introduce additional traffic load to the network. However, there are still some problems with this approach. Hardware probes still have to be placed in each location that needs to be monitored. For large scale enterprises (and in the case of New Jersey vs. Boston example provided above) this remains a problem. Additionally, you still have to configure the IP elements in the network such as switches and routers to mirror the traffic to another location. What about a scenario in which the entire set of the physical ports on the switch is already exhausted. Another switch might be required just to do the monitoring!


Probeless Monitoring

In the last few years a new solution trend is catching on fast. The new solution is similar to the passive approach but takes it to the next step for better monitoring. The idea is that each of the active network elements provide statistics to a higher management layer which can then provide a service level view as well as statistics with very fast troubleshooting schemes. With this approach, there is no need to add additional hardware to the network. There is also no need to mirror the traffic from the existing switches and routers. You only need to be able to interface with existing provided interfaces of the network elements to receive an end-to-end view.


This would appear to be the ideal solution. But is this really the case? Well, it is no doubt a major improvement over past solutions but there are still some issues that remain. Firstly, there is the issue of how you can get a full end-to-end view with heterogeneous network components? Secondly, there are some situations where passive monitoring cannot help and Active Monitoring is preferable. For example, if no traffic exists on the network, how do you know if there is a problem? You want to be sure that once a call is placed on the network that it will work. By the time the end user complains, it is too late. Active Monitoring can validate that calls from specific locations will indeed work. Also, the active monitoring solution can validate capacity planning. The IT CIO planned for a certain network capacity, but how can he/she be sure that the traffic load will flow without problems? Here, Active Monitoring is a useful methodology.


The Combined Approach

What really is required here for an IT organization to effectively monitor the quality of the voice network is a combined approach of Active AND Passive monitoring. What is needed is a comprehensive quality monitoring tool (such as AudioCodes SEM) that passively integrates with all of the company’s voice network elements as well as with UC applications such as Microsoft Lync. Such a tool can provide a full end-to-end monitoring view of network elements (IP-Phones, gateways, SBCs, soft clients, etc). Additionally, active probes can be embedded in the network in order to generate synthetic VoIP traffic according to predefined capacity loads. In this way, administrators can make sure that the deployment meets the requirements of the planning. The comprehensive quality monitoring tool, which integrates with both the active network elements and the embedded probes, will be able to simultaneously capture both real time and synthetic traffic, allowing for quick root cause analyses of voice network problems and assuring that the voice network can manage the traffic for which it was designed.

Moving WebRTC Into Your Network Through the Front Door

Moving WebRTC Into Your Network Through the Front Door

As part of my work with WebRTC, I get a chance to speak to different types of companies about their WebRTC plans. When speaking with companies that have existing VoIP products and services, the conversation usually moves to how WebRTC should be added to their offering, what the additional service benefits are and how to architect the solution. The typical requirement is to leave the existing deployment untouched and bridge WebRTC into the existing network through some sort of a GW. Where should the logical function of the GW be located and what should the network architecture look like are usually the questions debated. To answer them, I decided to write this post.Moving WebRTC Into Your Network Through the Front Door

Image credit: Muhammad Mahdi Karim

To demonstrate the consideration points and options, I will use an example of a contact center. For the sake of this example, let’s take a contact center that has both PSTN lines as well as SIP Trunks from a service provider. All traffic inside the contact center is via SIP where some of the agents are working on premise and others are home agents who are “called in” for handling contact center peak traffic.


Architecture Options when Adding WebRTC

In my discussions with customers and partners who are looking to add WebRTC into their existing networks, the architecture alternatives considered were:

  • A dedicated GW
  • Adding a WebRTC interface to their current core server
  • Adding WebRTC through an SBC

Before and After WebRTC

BeforePre WebRTC Contact Center Connectivity

  • Traffic comes from a service provider over SIP trunks or PSTN
  • All traffic in the contact center is SIP
  • Home agents are connected over IP-SIP but this is done in a secured and controlled manner
  • The contact center core server is placed inside the contact center network. Security is handled by other elements so it is protected from denial of service attacks, call fraud and other security vulnerabilities
  • Calls are using G.729 or G.711. Transcoding, if required, is handled in the contact center network



Adding WebRTC into the game creates new requirements and a new type of traffic source. With WebRTC, users browsing the website of the company serviced by the contact center, can call in directly from the browser. Their traffic runs over the Internet directly to the contact center.

WebRTC includes 2 voice codecs: G.711 and Opus. These are the codecs that come within the browser. If the intention is to eliminate the need for download, calls must be initiated using one of these 2 codecs.

Since G.711 is not built for running over the open Internet as it doesn’t include resiliency, it is beneficial to initiate the calls with Opus. The optimal approach would be to run Opus end-to-end from the browser to the agent but in cases where this is not possible, it is best to keep Opus on the open Internet leg and transcode when getting into the contact center network.Alternatives for adding WebRTC to the Contact Center

  • The contact center is required to have a “leg” in the public Internet domain
  • Quality of service is not managed. Even though in many cases the quality is good, supporting SLA requires the capacity to manage and monitor quality of experience (QoE)
  • Supporting Opus requires either adding a new intensive computing transcoding function or adding Opus to the agent’s client


Alternatives Comparison for adding WebRTC to Contact CenterThe comparison above doesn’t relate to any vendor specific product but rather looks at common functionalities of such products. Given this, the following conclusion should be viewed in context of the actual functionality supported by the specific products considered.

The comparison shows that in the case of the contact center example in this post, adding WebRTC to the existing internal contact center server will yield high risk and therefore, it is not a recommended alternative.

The selection between a pure GW and an SBC would depend on priority focus. If security and QoS are of high priority, the comparison leans towards the SBC alternative.