Posts

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 (http://online.audiocodes.com/voiperfect-for-ucaas-providers).

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

Secured Approach to Cloud Telephony Services

A Secured Approach to Cloud Telephony Services

Secured Approach to Cloud Telephony Services

Image credit: Flickr user opensourceway

One of the common dilemmas to most “mission critical” cloud service providers is whether an on-premise border gateway or tool should be part of their architecture for connecting on-premise software and HW appliances to their cloud services.

The purposes of such a border gateway or tool are various and depend on the cloud services provided. For example, a familiar tool is the AWS Storage Gateway. This gateway connects on-premise appliances to the Amazon Cloud storage services. Other cloud services such as big data analytics and network performance monitoring architecture may include on-premise tools for remote sniffing, data gathering, filtering, transforming, preliminary analysis and mass data transport.

When thinking of using a cloud service for enterprise telephony, a common decision point is whether to connect the enterprise IP Phones directly to the telephony service provider or to deploy an on-premise cloud appliance.

Actually, an enterprise cloud-based VoIP services architecture, dictates the need for an on-premise Session Border Controller for basic operation solving connectivity, (i.e. NAT traversal), security, resilience and quality issues.

Connecting the enterprise to the service provider cloud through VPN

Trying to reduce costs, VoIP service providers often bypass connectivity and security issues by connecting the Enterprise to the cloud using VPN over IPsec or MPLS-VPN service with or without standard End-to-End Service Level Agreements and performance reporting.

Both VPN-IPsec and VPN-MLPS connections simulate a L2/L3 LAN with the service provider. This architecture obviates the need for NAT traversal and on-premise VoIP security, as VoIP clients and IP phones share the same IP subnet with the service provider SBC.

Enterprise-Cloud-Over-VPN

VPN connection between the enterprise and the service provider

Adding Multitenancy

This approach may be satisfying for private or dedicated cloud architectures, although it doesn’t provide a solution for resiliency and voice quality monitoring. However, for cloud-based VoIP service providers who provide service to multiple enterprises, this approach is problematic.

Multi-tenant-SBC

Multiple tenants connected to the service provider through VPN

Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server or HW system, serving multiple client-organizations. Although multitenancy can be achieved by running multiple instances of the application, in most cases multi-tenancy is designed by virtually partitioning an SBC data and configuration. Each tenant works with a segregated non-bleeding virtual application instance.

Multi-tenant cloud-based VoIP services share a single application server instance (i.e. IP PBX, application servers) and network entities instance (i.e. access SBC, peering SBC) between several tenants.

Seemingly, multi-tenant shouldn’t present any security or other issue, but in reality, this tenant segregation is almost impossible since, after all, tenants may share network interfaces (same IP and port 5060), and a SIP trunk or MGW in the northbound, so the segregation is not complete. An attack on one of the tenants or a misconfiguration of one of the shared resources, compromises all of the tenants’ security. In such a case,  as the tenants are sharing the same L2/L3 with the service provider and relying on the service provider IDS (intrusion detection server) and IPS (intrusion prevention server), a simple intrusion can be destructive.

Cloud-Appliance

 An SBC as demarcation point between the enterprise and the service provider

Isolating the enterprise from other tenants’ security threats

Organizations that can’t afford compromising their security and can’t trust 3rd party security services, should deploy an enterprise SBC as a demarcation point.

An Enterprise SBC provides:

  • Support for back-to-back user agent (B2BUA) functionality
  • Security and privacy (personal information is not forwarded to the cloud)
  • Emergency calls and regulatory
  • Resiliency
  • Remote Agent termination
  • Registration throttling
  • Voice Quality Monitoring
  • Call Admission Control and Rate Limiting.
  • Registrations overload and avalanche protection
  • On-premise recording, the SBC forks the calls

Finally, cloud-based VoIP services can be connected to an Enterprise via VPN-IPsec or VPN-MLPS without the need for an Enterprise SBC. However in choosing this path, the enterprise loses much of the above mentioned functionality related to the SBC and puts the enterprise in a security risk as well.

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.