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.

Image: AudioCodes SBC Configuration Wizard

Making SBC Configuration Human

When I visited a 777 cockpit for the first time, what struck me most was all the buttons. I thought to myself, how on earth do the pilots know what to do with them all?

Looking at an SBC configuration reminds me of that same experience and over the years I played aroundwith quite a few SBCs of the SBCs out on the market.

Putting things into perspective, a typical SBC user manual is a few hundred pages long. A typical vendor’s beginner SBC course would run three days or more.

In light of this reality, one of the first questions an experienced customer would ask when considering an SBC would be, “just how complex is the SBC to configure?”

The perception of complexity is well rooted in reality and for good reason. It is not that SBC vendors lack UX (User Experience) knowledge or capabilities. The complexity is derived from the flexibility of the different VoIP standards, which means that every vendor can implement the standards in a different way. An advanced SBC is expected to deal with all of this complexity and interwork between different parts of the network on multiple layers, including SIP, media and IP. The SBC needs to be able to classify groups of users according to multiple attributes, to maintain access lists, manage security, routing and more.

Complexity has its price

The implications of SBC complexity are serious. For one, such complexity raises the cost of installation as technicians need to spend more time on site; it increases the chance of misconfiguration resulting in communication errors and increased support costs. Overall, the complexity of an SBC constitutes a hurdle in the transition to SIP trunking.

But does it have to be that complex?

Consider the following:

  • As it does elsewhere, the 80/20 rule holds true for SBCs as well. 80 percent of SBC customers only use 20 percent of the SBC’s configuration options.
  • The variance between similar deployments of different customers is relatively small. By ‘similar deployments’ I refer to a setup which involves certain kinds of PBX (and software releases), a SBC, and a service provider’s SIP trunk service.

The bottom line is that when looking at two different customers that have similar setups, each customer’s configuration will only differ marginally. The difference would usually include IP addresses and other layer 3 to 4 settings, number manipulation rules, authentication passwords and several additional parameters.

Taking the wizard route

A configuration wizard is a well-known user interface concept common in desktops and web applications. The wizard is used to get the user up and running quickly in just a few steps, leaving the advanced application configuration to a later stage using a parameter centric GUI.Image: AudioCodes SBC Configuration Wizard

The 80/20 rule and the typical similarity between deployments makes the wizard approach a perfect fit for an SBC configuration.

At AudioCodes, we adopted this approach and have developed an SBC configuration wizard application.

Starting with the deployment similarities, we defined “interoperability templates” which in practice is a configuration set which relates to a certain kind of PBX and a service provider’s SIP trunk service. (It can also relate to hosted services and PBX to PBX setups.)

The user configuring the SBC is asked to insert the PBX model, service provider and SBC types into the wizard. After that, all that’s left to do is to provision a few more parameters.

AudioCodes routinely updates its interoperability templates database, which currently comprises over 60 different templates! Every time the SBC wizard is used, it connects to the AudioCodes cloud database and downloads the latest interoperability templates.

After filling in the wizard screens, an SBC configuration file is created. The file can be sent directly to the SBC from the wizard.

In some cases, the configuration will now be complete, leaving the SBC in an operational mode. In other cases, the user would already be able to send calls through the SBC, but would still need to complete the installation by configuring a few additional parameters on the device web GUI.

The end result achieved through using the SBC configuration wizard is a substantial reduction in time and complexity in configuring an AudioCodes SBC. In most cases, it takes no more than five minutes to get initial calls going.

If you, too, have felt “lost in configuration”, where finding the right knob to turn is like finding a needle in a haystack, we would like to hear about your experience and how you navigated through.

Image: Collaborating with Lync and AudioCodes One Voice for Lync

Lync Rocks for Collaboration

[This is the first post in our Lync Migration series of posts]

I come from the video communications market, video is my bread and butter, my default for any business or personal communication. Sometimes I forget that not everyone sees the world of communication as I do. To many, communication is a phone call.

In my previous life working for a video company (Radvision), meetings using video were conducted using our own dog food. Lync was installed and used mainly on PCs for IM, and when we wanted to get “real”, we switched to our personal video VC-240 computer screens, a product we developed with Samsung in a partnership I led back in 2009.

Coming over to AudioCodes exposed me to a new world of Lync and integration of Lync with other enterprise telephony systems. It’s not that I didn’t experience Lync collaboration and dual ringing in the past, it is that at this company, this integration is at its best, bringing collaboration to new heights.

AudioCodes puts significant focus on products for Lync deployments through its One Voice for Lync solution offering. The solution includes products that make migration to Lync easy and at the pace the customer choses – gradual user, branch and systems migration, etc. At AudioCodes, we eat our own dog food and use Lync and AudioCodes systems regularly.

This full integration means that I can see, on my AudioCodes HW IP Phone, the Lync status of my colleagues, I can pick-up a call on the IP Phone or on the Lync application and perform different actions from both systems (phone or application). Additionally, I can connect PSTN and SIP Trunks traffic to the Lync network. Naturally I can IM, video call, collaborate and share documents on Lync as well.

Collaborating to Launch This Blog

Image: Collaborating with Lync and AudioCodes One Voice for Lync

As part of the work for launching this blog I had to speak with many people, some not located in our offices in Israel. Video calling via Lync and collaboration were key tools for keeping the work going and being

productive. As a user, it seems natural that you can now see the presence status of people directly from the email they sent you and start a collaboration session in one click. To the user, the platform the remote user is using (Lync, Enterprise PBX, Mobile, PSTN) is completely transparent.

The reality behind the scenes is not so simple on both the technical and business sides of things. Companies don’t tend to go for a forklift migration but rather a gradual one that also preserves previous investments as much as possible. As such, there needs to be a choice between hosted and on-premise deployment, or maybe a hybrid type of deployment with resiliency achieved by deploying an on-premise cloud appliance. This is just a short and non-exhaustive list of things to consider.  On this blog we will start a series of posts that cover topics related to migration to Lync. You can view it as a kind of a guide to the perplexed.

Don’t miss out, make sure you subscribe to receive updates when we share new posts.