Deployment, Tuning, and Testing
Presumably you have planned your VoIP deployment well, understood your user requirements, and understood the existing data network. You have put together a shopping list of upgrades and new equipment, and have completed their evaluation and purchase. You have made the upgrades necessary in the network, and are sure everything is working well without VoIP.
Now it is a matter of making the VoIP deployment work as you planned.
Deploy the new components one at a time, starting in the places in the network where the new components are most likely to work well the first time. Most breakage in a network occurs when changes are made. If possible, make one change at a time and be ready to withdraw the change if something breaks.
Be sure to plan for service provider changes that may be required. There will probably be a phased migration for your PSTN access and you may need more bandwidth for your current WAN links. You may be moving from separate voice and data links to integrated connections. These kinds of changes that are outside of your control need to be scheduled well in advance.
It is unlikely everything will work as desired without some tuning. Chapter 5, describes the many techniques available for tuning network traffic.
Testing is an absolutely vital part of the deployment phase. Testing helps you to get unequivocal answers to questions like these: Does the deployment work as you planned? Do all the features work? Can everyone be reached? Does the deployment behave well under stress? To answer these questions, you need to construct a test plan; your team should be able to confirm that every aspect of the project is working as desired. An outline for constructing a VoIP test plan is described in this section.
Assembling a Test Plan
Getting your VoIP deployment deployed well means making sure it is working as designed. Deployment teams put together test plans to verify that the specifications have been met. Here are some of the key elements of a VoIP deployment test plan:
Is the deployment operational and functionally complete? Does the end-user equipment work right (microphones, handsets, headphones, sound cards, dialing interfaces)? Does each of the VoIP functions work? For every user? At every interface?
If you have PSTN failover, does a break in the VoIP system cause the PSTN failover to occur quickly?
Is the deployment easy to use? You want the system to be easy to use for each of your end users, to avoid a long series of help desk calls. Put together a list of representative tasks that each user should be able to accomplish. Observe some controlled user interface testing to ensure that they can do all the tasks, quickly and without errors.
You want your IT team to be able to do their jobs easily and without errors. Can they add, modify, and remove users easily? Can they quickly and correctly find and isolate faults when they occur?
Is network performance good for the networked applications? Do telephone conversations sound good? With VoIP, network performance is synonymous with call quality. This chapter places great importance on the need for adequate bandwidth, low delay, and low jitter. The proof is in the measurement of these variables on the deployed network.
Do the transaction-oriented applications on the network perform well? The quality of the experience using traditional applications is measured by response time or throughput. For each critical application on the network, is the response time or throughput still meeting expectations?
This second set of measurements requires you to do benchmarking. Treat it like a high school chemistry experiment. Collect a representative set of timing samples before making any changes, make the changes, and then rerun the exact same set of measurements.
Do the settings interact well with other equipment and applications? Setting up VoIP involves many changes to your existing data-network equipment. Are the routers still routing correctly? Are the firewalls still permitting and constraining the right traffic? Does IP multicast traffic still get routed correctly?
Is the deployment stable under stress? You designed the VoIP system to support a given number of calls simultaneously, along with all your other network traffic. When that limit is reached, is the call quality still good? Are you using call admission, so that the number of calls can't be exceeded? What happens as the volume of background data-network traffic increases, or if a new video-streaming application is added?
Is there extraneous traffic? You have asked the question of whether the system is doing what you want it to do. Now ask whether it is doing anything you don't expect. Are there excess or redundant network flows, possibly caused by configuration options you did not understand? You may need a network protocol analyzer to help in this assessmenttake some snapshots of the network before and after VoIP, and see if there are any unexpected flows.
Does the deployment report on problems well? Activate the VoIP management system and make sure that it is operating correctly. Baseline its operation for a few days, then purposely cause faults in the system. Are the faults diagnosed promptly and correctly? Are the faulty components isolated? Do the alerts go to the right network management console? Are any automatic recovery operations performed right?