VoIP performance testing fundamentals

VoIP network performance testing can mean the difference between a VoIP system working at a high level QoS and a weak system that runs so poorly customers could take their business elsewhere. This guide discusses why it is important to run regular performance testing and some of the ways it can be done.

How can virtual network test beds ensure VoIP performance?

Voice over IP (VoIP) technology offers a wide range of benefits -- including reduction of telecom costs, management of one network instead of two, simplified provisioning of services to remote locations, and the ability to deploy a new generation of converged applications. But no business can afford to have its voice services compromised. Revenue, relationships and reputation all depend on people being able to speak to each other on the phone with five 9's reliability.

Thus, every company pursuing the benefits of VoIP must take steps to ensure that their converged network delivers acceptable call quality and non-stop availability.

A virtual network test bed is particularly useful for taking risk out of both initial VoIP deployment and long-term VoIP ownership. Essentially, such a test bed enables application developers, QA specialists, network managers and other IT staff to observe and analyse the behaviour of network applications in a lab environment that accurately emulates conditions on the current and/or planned production network. This emulation should encompass all relevant attributes of the network, including:

• All network links and their impairments, such as: physical distance and associated latency, bandwidth, jitter, packet loss, CIR, QoS, MPLS classification schemes, etc.,
• the number and distribution of end users at each remote location and
• application traffic loads.

This kind of test bed is indispensable for modeling the performance of VoIP in the production environment, validating vendor claims, comparing alternative solutions, experimenting with proposed network enhancements, and actually experiencing the call quality that the planned VoIP implementation will deliver.

Following are seven best practices for applying virtual network test bed technology to both initial VoIP deployment and ongoing VoIP management challenges:

1. Capture conditions on the network to define best-case, average-case and worst-case scenarios
   Conditions in a test lab won't reflect conditions in the real-world environment if they are not based on empirical input. That's why successful VoIP adopters record conditions on the production network over an extended period of time and then play back those conditions in the lab to define best-, average-, and worst-case scenarios. By assessing VoIP performance under these various scenarios, project teams can readily discover any problems that threaten call quality.
2. Use the virtual network to run VoIP services in the testing lab under those real-world scenarios
   Once the network's best-, average-, and worst-case scenarios have been replicated in the test environment, the project team can begin the process of VoIP testing by running voice traffic between every set of endpoints. This can be done by actually connecting phones to the test bed. Call generation tools can also be used to emulate projected call volumes.
3. Analyse call quality with technical metrics
   Once VoIP traffic is running in an accurately emulated virtual environment, the team can apply metrics such as mean opinion score (MOS) to pinpoint any specific places or times where voice quality is unacceptable. Typically, these trouble spots will be associated with observable network impairments -- such as delay, jitter and packet loss -- which can then be addressed with appropriate remedies.
4. Validate call quality by listening to live calls
   Technical metrics alone can be misleading, since the perception of call quality by actual end users is the ultimate test of VoIP success. So the virtual environment should be used to enable the team to validate first-hand the audio quality on calls between any two points on the network under all projected network conditions. Again, a call generator can be used so that testers can act as the "nth" caller at any location.
5. Repeat as necessary to validate quality remedies
   A major advantage of a virtual environment is that various fixes can be tried and tested without disrupting the production network. Testing in the virtual environment should therefore be an iterative process, so that all bugs can be fully addressed and the rollout of VoIP in the production environment can be performed with a very high degree of certainty.
6. Bring in end users for pre-deployment acceptance testing
   Since voice quality is ultimately a highly subjective attribute, many VoIP implementation teams have found that it is worthwhile to bring in end users for acceptance testing prior to production rollout. This greatly reduces the chance of the dreaded VoIP mutiny syndrome, where end users baulk at call quality despite the best efforts of IT and the fact that call quality meets common industry standards.
7. Continue applying the above best practices over time as part of an established change management process
   To maintain VoIP quality over time, IT organisations must incorporate the above best practices into their change management practices. This is essential for ensuring that changes in the enterprise environment -- the addition of new locations, the introduction of a new application onto the network, a planned relocation of staff -- will not adversely impact end-to-end VoIP service levels.

It's important to note that while a virtual network test bed will pay for itself by virtue of its support for VoIP and convergence alone, this technology has many other uses that deliver substantial ROI. These uses include the development of more network-friendly applications, better planning of server moves and data centre consolidations, and improved support for merger and acquisition (Mon your goal.

If you have two sites linked together with PBX tie lines and you want to try using VoIP so that calls will be routed over your internal network rather than costly tie lines, you can test using a SIP to PSTN gateway (such as the MX25.)

This configuration could look like this:

Existing PBX ? T1 PRI ? MX25 ? SIP over WAN network ? MX25 ? T1 PRI ? Existing PBX

Perhaps you have a single site and you want to keep your existing PBX and connect long distance calls through an Internet telephony service provider that provides superior rates. In this case, you could use a SIP to PSTN gateway and connect in this fashion:

Existing PBX ? T1 PRI ? MX25 ? SIP over Internet ? ITSP ?

Perhaps you are planning on replacing your legacy PBX and putting in an IP PBX (such as the MX250) to test the functionality before cutting over service. In this case, the configuration could look like this:

Existing PBX ? T1 PRI ? MX250 ? T1 PRI ? PSTN

Using this approach, the existing PBX continues to function as it always has and only dial plan entries are required to route calls between systems. This allows for certain employees to learn the new VoIP system and understand its features before migrating over service.

When should a VoIP system be analysed and with what tools?

We have recently implemented a VoIP network with separate VLANs and QoS. It all seemed to be working fine when it first went in, but recently, certain people have been complaining about sound breakup whilst talking to customers on the phone. I have also had similar problems, but thought it was due to the amount of diagnostics software that I was running on my PC.

To check, I moved my phone into its own port and the breakup is still there. Any ideas how we can check to make sure that the network is doing alright? Also are there any software utilities that would help us with day to day analysing?

First and foremost -- I would suggest that you have someone come and test your cabling channels. That will be the least expensive and could be the most worrisome component. Even if the channels tested fine when first installed, they can degrade over time with moves, adds and changes.

The other thing you didn't mention was if this occurs only on the intra-office calls or only on outside calls. If it is only on outside calls, you may want to get your carrier to check your circuits.

If these things test out okay, then you will want a RMON tool that can track performance. Check your switch SNMP data for errors. These will also give you a good idea of what the culprit may be. If this is happening to everyone in the building -- start looking for common denominators such as network interface cards in the switch.