Posts

the whole is greater than the sum of its parts

WebRTC Connectivity Solution with Focus on Quality and Scale

The whole is greater than the sum of its parts

the whole is greater than the sum of its partsWe released a PR today about the AudioCodes WebRTC Connectivity Solution. In this post, I want to provide a technical insight into this solution, explaining why the whole is greater than the sum of its parts.

A typical approach to connecting WebRTC with an existing enterprise VoIP network would follow one of these two architectural concepts:

  • Browser using Opus with some kind of proprietary signaling-> WebRTC to SIP GW -> SBC -> Transcoding to G.7xx -> IP Phone on a SIP network
  • Browser using G.711 with some kind of proprietary signaling-> WebRTC to SIP GW -> SBC -> [Optional: Transcoding from G.711 to G.7xx]-> IP Phone on a SIP network

Both cases introduce some issues

The external WebRTC to SIP GW carries a price.

Transcoding from Opus to G.7xx is something you would want to avoid unless there is no other option. Opus requires hefty CPU resources (much more than most audio codecs) and introduces quality issues while increasing CAPEX.

The other alternative, using G.711 over the open internet, is not a good option as G.711 wasn’t built for sustaining quality over unmanaged networks.

Traffic traverses between networks and different network types (WiFi, Wireline Ethernet, public Internet and enterprise networks) while devices themselves can vary as well. Handling of network impairments should be done in the entity that connects between these networks as it is familiar with the requirements of each and has the per-session knowledge of source and destination of traffic. While the two links above use VoLTE as an example in the post, similar issues arise when traversing WebRTC to non-WebRTC networks and the algorithms described in these posts serve the need of this architecture as well.

Another missing piece in typical deployments is the ability to monitor the traffic, know what is happening on the network and impact SBC decisions for quality improvements.

Putting quality and scale at the front

The solution announced was designed with these two factors at the forefront and that is what makes it stick-out of the crowd.

Integrated solution

In our solution, WebRTC is supported in the SBC itself. This includes WebSockets, DTLS and other WebRTC “special” behavior. This architecture simplifies deployment and management as well as reduces delay, (or in other words, increases quality).

Minimal transcoding scenarios

By supporting Opus in the AudioCodes IP Phone, we hold the rope at both ends. On the one hand, voice over the open Internet is using the Opus codec which is purposely built for this task. On the other hand, transcoding is not required as the IP Phone also supports Opus. This significantly increases the number of calls supported while reducing CAPEX.

Signaling

For signaling we use SIP over WebSockets. We found this to be a good solution when the goal is to connect to existing networks.

Another advantage of the decision to use SIP for signaling is the connection to WebRTC API platforms. WebRTC API platforms typically use proprietary signaling. For connecting to existing networks they build an adaptor which is typically SIP. This basic SIP implementation can’t connect to any existing enterprise SIP network but going through the SBC allows it to do so. While this SIP adaptor varies and is not always pure WebRTC over WebSockets, eliminating the need for this adaptor to implement a full WebRTC to SIP GW, simplifies this interconnection making this task easier.

Voice quality enhancement

As mentioned, traffic traversing between networks typically suffer from call quality degradation. There are different implementations of media engines on the client side that are optimized for the network with which the client plans to work. When the client connects with another client on a network that it wasn’t built to connect with, voice call quality issues increase. Having the SBC as a demarcation point between the networks allows for the utilization of the AudioCodes voice enhancement algorithms for improving audio quality.

Detect & correct

The AudioCodes Session Experience Management (SEM) not only monitors and detects voice call quality issues, it also works in harmony with the SBC to allow for smart, quality based, routing and quality improvements.

Why is this important?

A WebRTC GW doesn’t stand by itself; it needs a multitude of capabilities and supporting elements to ensure effective and high quality service. This is why the whole is indeed greater than the sum of its parts when bringing all that is required for an end-to-end WebRTC Enterprise connectivity solution.

Active Passive Networks Monitoring

VoIP Networks 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 in order 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.

Breaking Loose from MPLS

Breaking Loose from MPLS? You Better Keep an Eye on Your Network

Breaking Loose from MPLSDid you ever hear this answer when complaining to IT about a bad call experience over a VoIP network?

Try to make that call again and if things go bad yet again please let me know

Enterprise telephony networks of the past were rather simple from a quality assurance perspective. The move to IP was gradual, typically starting within the enterprise via the move to IP PBXs in the branches, adding inter-branch connectivity over IP and later switching to full IP also on the access side. This was typically done using MPLS lines that provided quality assurance but at a high price.

Quality of Experience (QoE) is critical for enterprise communication networks. I spoke about this topic from a bit of a different perspective at the last Upperside WebRTC Conference and shared the presentation as well. The move to an all IP architecture introduced quality challenges as enterprise networks are complex with multiple sites and a need to connect efficiently between them. Challenges are magnified as enterprises break loose from MPLS chains and move to unmanaged IP networks. Issues that arise from such a change span all VoIP disciplines from call control through media routing to codecs. This makes effective troubleshooting of telephony problems and keeping a consistent good quality of experience, a hard nut to crack.

Driving blind through the network

If you would ask an IT manager at any given point in time the status of his VoIP network, he would be able to give basic statistical information about call activity, packet loss and bandwidth utilization. But now comes the tricky part – understanding what the user experience is like or why this experience was bad on a specific call. The typical answer to such a complaint about call quality is similar to the quote at the beginning of this post but the thing is that when making the call again, the problem usually wouldn’t happen.

By the time the problem does happen again, too much time has passed, context is lost and IT is back to square one trying to figure out what happened and what needs to be done to fix it. VoIP is an application that runs on top of the IP network. For monitoring and resolving VoIP problems, IT needs a proper “pair of glasses” built specifically for the nature of VoIP applications and networks.

Fundamental requirements for effective network monitoring

In order to improve user experience, it is required to understand the root cause of the problem and act upon such findings. A few fundamental capabilities are required in order for a monitoring system to provide this capability. Basically, it boils down to a holistic view of the network and aggregation of calls statistics of different interfaces. Monitoring a single call and acting upon that is not going to solve the root cause of the issues you have in your interface between office A and office B. But looking at the overall flow of calls between locations will enable you to identify network issues.

Take as an example QoS marking mis configuration – such an issue may result in sporadic quality issues and identifying the root cause of the issue will be possible only once the monitoring system has identified that this happens only on one specific media route in which a router is breaking the QoS marking.

It’s clear that regular network monitoring tools will not be helpful in diagnosing the problem and that a proper pair of “glasses” that can find network misconfigurations which result in bad quality of experience is required.

Based on this, the fundamental requirements from a monitoring system would include:

  • IT time saving – Help in finding the root cause of the problem in a few simple clicks
  • Real Time analysis – Showing what really happens in the VoIP network when the problem occurs. It is great to be able to just look at the screen and see what exactly is happening throughout the entire VoIP network.
  • Notifications – Getting alerts on real problems in the VoIP network before they are reported by a user, or worse, being escalated to higher management.
  • Trend statistics – This relates to that holistic network view that allows for identifying issues over time and keeps quality issues in context. Good examples of this are quality issues that happen repeatedly while another activity is taking place on the network. Such an “activity” can be a backup system running high network traffic or a user downloading large files.
  • Monitoring the call control – analysis of the media is not enough as many cases of bad user experience are related to call control issues such as dropped calls and incorrect routing of calls that result in call establishment failure.
  • Network probes – In order to monitor the network of a distributed enterprise you need to have a probe in each location that will collect and report network statistics and quality information.
  • Demarcation point in each branch – The demarcation point located at the edge of the local network will allow for the isolation of problems and assist in understanding if the root cause of an issue is on the enterprise network or related to the provider of the access or telephony service.
  • Remote access & visibility to all sites – Once problems are identified, you need to be able to act upon the findings and make changes in remote locations.

 

In conclusion, enterprise real-time communications solutions comprise multiple parties, from the access providers through telephony service providers to server and end user equipment. Monitoring the network, understanding the root cause of issues and changing what is required to be changed in order to avoid further quality issues, is a difficult task. The road to achieving this goal runs through both minimizing the number of vendors involved and using a monitoring solution that has a holistic view of the entire network and of each branch.

At AudioCodes, we have been working with such cases for many years. As a company that started from the voice codec level and grew to become a complete one-stop-shop for VoIP communication, we understand the concerns and issues enterprises are experiencing when moving to an all IP environment. For that reason, we have developed a Session Experience Manager solution (SEM) that is part of our One Voice offering.

Feel free to relate your stories about quality issues and conclusions from these cases in comments to this post.