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 analyze the behavior 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
- 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. Analyze 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 firsthand 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 balk 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 organizations 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 center consolidations, and improved support for merger and acquisition (M&A) activity. These significant additional benefits make emulation technology an extremely lucrative investment for IT organizations seeking both to ensure the success of a VoIP project in the near term and to optimize their overall operational excellence in the long term.
About the author:
Amichai Lesser is a director of product marketing at Shunra. Shunra is the pioneer and market leader in predicting the behavior of services across today's complex networks. Shunra's VE solution lets users know exactly how their voice, video and business applications will perform in any network environment -- before they are rolled out into production.
Amichai is responsible for product marketing, market analysis, and field marketing programs, and has extensive experience in real-time engineering, performance management and security. He regularly presents at industry conferences, seminars and events. Amichai can be contacted at firstname.lastname@example.org. For more on Shunra and its solutions, visit the Shunra Web site.
This was first published in April 2006