The path to replacing MPLS with broadband

Sustaining High Voice Quality Over Broadband

The path to replacing MPLS with broadband


The path to replacing MPLS with broadband

Hosted enterprise communication offers a good solution for enterprises looking to move their communication to the cloud and by doing so, reduce their CAPEX investment as well as benefit from a cloud managed solution that is regularly updated for supporting new technologies and features.

These benefits typically come with a caveat, however, a requirement to connect through MPLS to the communications service provider in order to reduce network impairments issues that impact voice quality.

MPLS cost TeleGeography

Source: TeleGeography


MPLS comes with a high price tag. The chart above shows typical costs of MPLS in key countries in comparison to broadband. For example, in the US, monthly costs for 10 Mbps of MPLA would be approximately $1,250 while broadband would be slightly over $100.

This represents a significant difference that calls for realizing the cost reduction opportunity. However, the risk of not being able to ensure high voice quality keeps many communications service providers away from recommending this option to their enterprise customers.

Voice QoS is a combination of codecs and other algorithms

Voice quality is determined by network characteristics such as delay, packet loss and jitter combined with the tools used to mitigate network impairments once they happen.

Many of the communications services are using technologies (phones and network servers) that are built for LAN environments or dedicated networks, are not built for the open Internet.

IP-Phones and applications are using codecs such as G.711 or G.729. These codecs are not built for the open Internet both from the resilience and voice quality perspectives.

Voice algorithms such as Jitter buffer need to be tuned for the network and additional algorithms such as Forward Error Correction (FEQ) and packet loss concealment should be implemented.

The end result is that many deployments today are not built for working over broadband and therefore the common practice is to default to MPLS, thus increasing OPEX and delaying customer acquisition (as setting up MPLS may take a few months).

Perfecting voice over unmanaged networks

Yet communications service providers can allow their enterprise customers to benefit from lower cost broadband without replacing their network elements or customer’s phones.

To realize this, however, a few things are required:

  • Real-time monitoring of the voice running over the network
  • Transcoding to codecs built for unmanaged networks such as OPUS. OPUS has resiliency built into it by design and supports a wide bitrate range going up to ultra-wideband.
  • Implementation and tuning of algorithms such as adaptive jitter buffer, FEC and packet loss concealment
  • Smart routing and balancing of traffic between several broadband links if more than one link is available

AudioCodes’ VoIPerfect offers all these capabilities and allows communications service providers a route for easy adoption of this technology by deploying SW or HW elements at their access and customer premises while not replacing the existing deployed elements.

To learn more about the VoIPerfect and experience a real demo click here (

Managing Heterogeneous VoIP Networks

The Nightmare of Managing Heterogeneous VoIP Networks in Medium to Large Enterprises

There is an Answer

Managing Heterogeneous VoIP Networks

Managing heterogeneous VoIP networks in medium to large enterprises can be a nightmare. Due to the large number of vendors participating in providing the solution, there can be problems at every stage of the implementation and maintenance issues can arise in a variety of aspects including:

  • Network design and configuration
  • Device discovery
  • Distributed routing & policy enforcement
  • Distributed PSTN breakouts
  • Multiple VoIP network elements configuration: SBC and MGW
  • Multiple dial plans: SfB, IP-PBX, SBC and MGW
  • SIP interworking between IP-PBXs A large number of end user policies

Distributed networks present numerous challenges and when it comes to heterogeneous networks where the devices and applications are provided by different vendors, the situation is even worse. Unified Communication systems (e.g. Skype for Business) and the various components in the network such as IP-PBX, SBC and MGW, each have their own static routing, manipulation and dial plan tables. In actuality, we are talking about a distributed system whose elements don’t communicate with each other.  As for troubleshooting, there is no single throat-to-choke and each vendor puts the blame on the other.

AudioCodes’ new White Paper entitled, “Call Routing and Policy Management in Heterogeneous VoIP Networks” presents the challenges of heterogeneous VoIP networks and related applications currently existing in the market. The paper describes a new solution – the “Centralized Dynamic Routing and Policy Manager” – a holistic dynamic routing manager whose design is based on Software-defined Networking principles.

The Centralized Dynamic Routing and Policy Manager decouples the device layer from the network routing and policy layer, automatically creates complex VoIP networks, and simplifies routing rules, monitoring and management configuration. The Centralized Dynamic Routing and Policy Manager does not enforce modifying the network to a star formation and rather manages the network as is.

For more information, click here to download the “Call Routing and Policy Management in Heterogeneous VoIP Networks” White Paper.

VoIP Quality Jitter Delay and Packet Loss

Is VoIP Jitter, Delay and Packet Loss the Best Measure of Voice Quality?

VoIP Quality Jitter Delay and Packet Loss

“One of the values that I think men in particular have to pass on is the value of empathy. Not sympathy, empathy. And what that means is standing in somebody else’s shoes, being able to look through their eyes.” Barack Obama

Empathy – being able to feel sorry for someone else’s troubles – is a basic ingredient for good mental health. However, sometimes, when irony is involved, empathy might turn to ambivalence. For example, you will naturally feel empathy when you see or hear about a building going up in flames, but you might even crack a smile if the building in question is the fire department. (Of course that would happen only if no one was injured, right?)

We recently had voice quality issues in our corporate telephony system. Now that might happen in any organization, but when it happens in AudioCodes, the company which has become the hallmark of HD VoIP, that’s ironic.

Our IT guys brought their usual armour to battle and started taking on the packet loss with Wireshark (network protocol analyser), upgrading this and downgrading that. Then they started looking at the AudioCodes products on the VoIP network; scrutinizing the latest IP phone firmware, restarting the SBCs, disconnecting the MGW.  And still, they couldn’t find anything to help pinpoint the problem.

After a week or so, one of my colleagues placed a call and couldn’t stand the noise on the line.  Naturally, he cut short the call as cellular SP has “trained” us to do over the past two decades. And since he is the Product Manager for AudioCodes Management Solutions, he decided to try troubleshooting the problem on his own (15 years in R&D can come handy sometimes), using the AudioCodes Session Experience Manager.

Now I have to apologize up front since at this stage the story gets a little corny.  He found that a substantial amount of the off-net calls originated by the UC system were faulty with a poor quality score.  After conducting a short analysis with our IT department, he found a misconfiguration of the VMware machine running one of the IPPBX servers.  He wondered why our own IT guys weren’t using the AudioCodes Session Experience Manager. Could it be as a famous man once said, “familiarity breeds contempt”?

I am not relating this story to point shortcomings on the part of our IT department (God forbid!) or alternatively to glorify an AudioCodes product.  A vendor who speaks about his own products is almost as bad as a mother who talks about her own children.  My point, rather, is to elaborate on the concept of VoIP quality monitoring.

It is human nature to reach a conclusion by reviewing the consequences of actions. The human brain is constantly on an endless quest to solve riddles and reach conclusions (Gestalt psychology or Gestaltism).  Therefore, it’s perfectly normal for an IT engineer to analyse the VoIP network, search for the causes of poor quality such as packet loss, jitter and delay and based on the analysis, evaluate the call quality.

From my perspective, this analysis method is problematic.  It’s like commenting on the taste of a casserole by evaluating its ingredients – before even cooking the dish. Voice quality can’t be accurately evaluated by reviewing only the relevant network impairments (jitter, delay and packet loss). An accurate measure of voice quality needs to be taken at the VoIP edges (MGWs, SBCs, IP phones, soft clients) while taking into account the vocoder, jitter buffer type and depth (static, adaptive), packet loss metric (Network Packet Loss Rate, Jitter Buffer Discard Rate) and more. This information can’t be obtained by only analysing the traffic.


There is a mistaken belief in the industry that VoIP Quality Monitoring applications are like insurance policies -you buy them hoping not to use them. This belief is due to decades of trusted legacy telephony and basic trust in the organizational network, devices and solutions. In Reality, VoIP Quality Monitoring should be considered for ongoing use for the following:

  • Day-to-day, end-to-end quality monitoring and assurance operations with the ability to perform proactive actions to prevent quality issues
  • Root cause analysis for diagnostics when VQ issues arise

So if you are having VoIP quality issues, I empathize, even though after reading this, you might smile at the irony.

VoLTE Deployments

LTE Voice Summit Not Only About Voice

My takeaways from the LTE Voice Summit

Earlier this month I spoke at the LTE Voice Summit. As promised, slides are now available on SlideShare.

A few important notes from the event.

VoLTE – 11 service providers and counting

LTE was launched by 331 service providers worldwide. Once LTE has been launched, adding VoLTE to the mix makes sense to the service provider as it reduces their OPEX, saves spectrum and improves user experience by allowing for better voice quality, longer battery life and other benefits.

To date, VoLTE has been launched by 11 service providers.

60 others are in trials and planning.

VoLTE Deployments


Voice quality

Speaking with service providers that already launched VoLTE and have field experience and feedback, I heard there are issues when connecting calls between VoLTE and non-VoLTE networks.

Doing a one-size-fits-all transcoding to G.711 when exiting the VoLTE network is not a good solution.

There was a great presentation by Michael Thelander from Signals Research Group that compared quality over VoLTE vs. Skype. No surprise here, quality over VoLTE was better; they could have saved the dollars spent on the research. As VoLTE was built for real-time communication while Skype and other OTTs run over the data network, it is only expected that these would be the results.

The same applies to battery life. Since VoLTE is pre-integrated with the phone, things are better optimized. This includes video codecs that can be HW accelerated in native clients and other algorithms such as acoustic echo cancellation (AEC) that can run on the chip level. These yield better quality and lower battery consumption.

The more interesting question would be to test VoLTE to a VoIP client over a WiFi network and compare that to an OTT like Viber. In such a case, VoLTE has problems such as those I presented in my earlier post and in my presentation at the conference.

For these problems , AudioCodes presents a pretty compelling solution that comprises a smart entity (SBC) that resides in the core of the network and makes decisions with regards to transcoding, transrating, call routing and call properties negotiation (bit rate, codec, resiliency…). It uses network monitoring information and communicates with other network elements to apply its policy. Feel free to contact me for detailed information.

Services are based on RCS

Even though this was a conference about voice, services were mainly related to RCS. Service providers are continuing the RCS path and believe that once RCS will be fully integrated with the phone as default, users will use it.

I believe that service providers should manage a mix of “service provider OTT” with RCS in order to remain relevant. Offering only standard RCS capabilities will make differentiation hard as all service providers will offer the same thing with pretty much the same user interface as defined by the GSMA.

To that end, I presented this issue to David Hutton from the GSMA on a panel discussion. I believe that the decision of the GSMA to standardize everything in RCS right up to the user experience is a dreadful mistake, it is one of the reasons for the failure of RCS and imposes unnecessary limitations on the service providers. To my surprise, he agreed.

In conclusion:

  • VoLTE is happening.
  • Service providers that have already launched VoLTE services are starting to experience the complexity of connecting VoLTE to other networks.
  • Service providers understand that VoLTE by itself will not provide the required added value services and are looking for those services in RCS. They should combine these with their own OTT services in order to differentiate.
Managing Voice Quality

3 Things Required for Managing Cross Network Voice Quality

So you’ve built your VoLTE network for high quality. You are providing high bandwidth to your customers so browsing and watching video is great. You also managed to get delay, jitter and packet loss down so voice calls are using WB-AMR giving your customers top quality.

Managing Voice QualityBut even though VoLTE is set to succeed, it will not happen overnight and it can’t be an island, there are other networks it needs to connect with. You need to allow for calls to GSM, PSTN and wireline VoIP.

To allow for this, you engineered your network in a way that if a call needs to exit the VoLTE network to any of the other networks you simply transcoded it to G.711. With that, it connects “without any issue” to any network out there.

So you connected your VoLTE network to other networks but that’s exactly when problems started to come up. Users started calling your contact center complaining about voice quality issues, they felt as if a mouse has cut the wire. Analyzing the complaints showed that there are problems not only when calling between the different types of networks but even when calling between VoLTE networks of different service providers.

Different type of networks perform differently


Think of a VoLTE network. It prioritizes voice over other data types. It will not retransmit voice packets even if there is packet loss (different from its handling of data) and it dynamically tunes rate, stuffing multiple voice samples into a single packet and add redundancy when needed.

In a VoLTE to VoLTE case, this results in great quality but when the destination is on a different network, that network handles things differently, resulting in quality issues.


On the GSM network, data will be retransmitted in case of packet loss, VoIP traffic included. This results in increased delay. Moreover, the 3G network works in burst mode sending a large amount of data to the core of the network in bursts, resulting in delay and jitter.

In case of voice TDM calls, NB-AMR is used which is, of course, different from what is used on the other networks.

Wireline VoIP

In the enterprise and consumer environments, VoIP provided by service providers typically uses G.729. The network itself is typically designed for wireline access but in reality many access it over WiFi. Needless to say that network behaviour is different in each case.


Well, I guess there is no need to say too much about this subject. It is robust and voice quality is constant but at PSTN quality.

The brain and the tools that solve the problem

We have seen that different networks have different characteristics. That’s no news I guess. The conclusion though, is. Because this simple fact means that it is not efficient to decide on call setup properties and mid-call changes without knowing exactly the characteristics of the caller and callee networks.

Solving the quality issues when calling between networks requires three things:

  • Knowledge of all networks’ characteristics
  • Real-time monitoring information
  • Voice enhancement tools that will be managed dynamically based on actual call and network information

The entity that answers these requirements would be an SBC or a transcoding GW that resides in the core of the network. It would manipulate voice using various voice enhancement tools, decide on the best codec and rate for a call between the networks and use monitoring information for its decisions

On October 8th, I’ll be speaking on this topic at the LTE Voice Summit in London. If you happen to be there, drop by and say hello.

I will also be posting more information about voice call quality enhancement tools as well as a link to my presentation on SlideShare so stay tuned and be sure to follow: @AudioCodes and @AmirZmora

Here is a sneak peek to one of my presentation slides.

Voice Quality in Wireless Networks


A Mouse has cut the Wire: I can’t hear you…..

 [Post is better viewed on the blog Website]


When I was a kid, I loved reading the Dr. Seuss books with the fun and educational rhymes. As an adult, I loved reading them to my own children when they were young. Some things never grow old.

It seems that it is the same with the quality of a phone call. From the early days of the switchboard to calls over the cellular network, the phrase “can you repeat that? I couldn’t hear you” has been commonly heard over the years. And so has the emphasis on improving voice quality accompanied the advances made in telephony communications.


Source: One Fish Two Fish Red Fish Blue Fish, by Dr. Seuss

This is no less true today with Voice over IP (VoIP) networks. Perhaps the greatest enemies of a quality call over VoIP networks are delay, jitter and packet loss. Network experts invest great efforts in fine tuning their networks so as to minimize the negative effects of these factors. In a recent post on this blog entitled “Voice is Coming to LTE”, Amir Zmora pointed out that in his experience in speaking with service providers that are already invested in VoLTE and interconnecting with other networks, it was clear that voice quality and QoE are their main concerns.

VoIP traffic may traverse wireline, WAN, cellular or wireless networks. Wireless traffic in particular is inherently inconsistent and the effects of delay, jitter and packet loss, if not handled, can seriously impair the quality of a call. Wireless networks were designed first and foremost for data applications. But in data focused applications, the most important thing is for the payload to arrive complete, how fast it gets there is less important. Thus, compensating measures can be implemented to guarantee that requirement. However, while these capabilities ensure the arrival of the packets, they also increase delay and jitter. And while delay for data applications is acceptable, in the case of VoIP the delay may be intolerable resulting in someone saying “I didn’t catch that, come again?” or just dropping the call altogether.

As most VoIP entities in the network (session border controllers, gateways, ATAs, IP Phones, mobile clients, etc.) were designed to handle wireline, and not wireless impairments, they have a hard time handling (without help) traffic emanating from wireless networks. To get around the problem, AudioCodes has implemented special built-in tools inside its Session Border Controllers. By placing the SBC with these tools between the wireless network and any other network (wireless, wireline, cellular, etc.), the impairments from the wireless network traffic can be managed and reduced dramatically to allow for an end-to-end quality call and prevent someone from saying, “I cannot hear your call. I cannot hear your call at all!”

Want more information?

Click here to download a White Paper in which you will learn how built-in SBC tools such as an adaptive jitter buffer, transcoding, redundancy, trans rating and quality-based routing can each play a major role in significantly enhancing QoE. Furthermore, when taken together and given the ability to fine tune and balance between the variables, they can be truly powerful.

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.

One Voice Operations Center

The VoIP Network Management Jigsaw Puzzle

Have you ever felt that your VoIP network management system is like a jigsaw puzzle requiring you to jump from one application to the other in order to complete a full cycle of handing an issue? Well, you are not alone. Meet Alice. Alice works in the IT department of a mid-size company with 3 offices in the US, 2 in Europe and 2 in APAC. This is what happened to her last week.

8:45am, Los Angeles

Alice gets a notification on her browser-based alarm system that there is a high call drop rate in the Boston branch office. She turns to the voice quality monitoring system to zoom-in on the problem.

She waits for the monitoring system to start, it’s a different GUI so it takes her a minute to find the information on that specific branch.

Since it looks like a problem that happened repeatedly over the last 2 hours, she runs a report to get the details of all calls dropped.

She flips back for just a minute to the alarm system to make sure these are really the calls for which the problem was reported. Alice then realizes that the problem has to do with one specific SIP Trunk that is dropping calls.

She must act fast. The Boston site executive was in touch with her from his mobile several times already. He and his team are about to go into a conference call with a customer and he is worried the call will fail.

Calling the service provider support line doesn’t look like something that will solve the problem for the call about to begin at the top of the hour. It is 8:53am and there is no time for support IVR and a call queue.

Alice decides to work around the problem and bypass this SIP trunk by configuring the branch SBC to route the calls through the Chicago branch over an MPLS link. She is still on the monitoring system so Alice now needs to switch to enter system with a different GUI, for the SBC configuration system.

OK. So I made up the story and invented my character Alice. But scenarios such as this one do play out every day for IT managers.

The multitude of independent management and configuration tools, each dealing with a specific task, is a major drawback in VoIP network management. You may think that this jigsaw puzzle is inevitable as each system comes from a different vendor or simply because each product has its related system even if they all come from the same vendor. But it doesn’t have to be that way.

But Gentleman, We Can Rebuild It

One Voice Operations CenterWhat if there was an all in one unified VoIP management suite? What if call quality monitoring, alerts and management of your network servers were all managed from one system? Well…that is exactly what AudioCodes One Voice Operations Center is all about.

The AudioCodes One Voice Operations Center is a suite of management tools providing full coverage of the entire set of actions required to manage a voice network in a Unified Communication environment.

It uniformly manages, monitors and operates the entire AudioCodes One Voice portfolio, including SBCs and Media GatewaysMicrosoft SBAs and IP Phones.

For example, in case of an enterprise using a Lync server, the One Voice Operation Center provides a complete view of the network voice quality, including Lync client to Lync client calls and Lync to PSTN calls. All in real-time. And if you need to fix a configuration, there is no need to go far. The same suite provides a provisioning interface to manage all your SBAs, SBCs and gateways.

Want to learn more? Come visit our booth #625 at the ‘Lync Conference’ to watch a live demo of our ‘One Voice Operations Center’.

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.