The purpose of a VRA is to determine precisely what impact the data network is going to have on voice. When we place voice on the existing IP network, what is going to happen? In other words, this is just proper planning—taking into account all the information we have at our disposal, and using it correctly. It starts with having the right information available in the first place.
The easiest and safest way to understand the impact of convergence is to test it. Put a sampling of voice sessions on the IP network and step back to see what happens. The industry has tools available to help with this process. NetlQ, for example, provides a platform to help assess the impact of voice on the network, and vice versa.
Many customers who deploy voice experience problems such as one-way audio, dropped calls, and static/clipped calls. Tools are available to help identify where (and why) these conditions might exist. Placing voice on the network, in a simulated environment, is a safe way to stress the network. The goal is to see if the network starts to degrade—and to see how well voice will be handled by the network—but it doesn't stop here.
It's one thing to place 10-15 voice sessions on the network and assess the impact. However, to fully understand how adding voice will impact the data network, you must understand the current traffic loads. The real question a company must answer is this: How is your existing voice traffic going to impact yowexisting IP network? This is the question that a white paper or a research report from an analyst is not going to adequately address. Both of these documents are important to help educate companies about this emerging environment, but neither identifies what happens to your own network when you deploy IPT.
This is where the competency of your partners comes into play. A partner who knows how to assess your current voice environment, assess your network, and use that knowledge to determine the impact of your voice on your network is a valuable asset in the convergence journey.
So, a true VRA doesn't start with the network, but with the original PBX. A voice traffic study can determine call volumes, durations, etc. What businesses need to do, therefore, is conduct a PBX traffic study to determine the existing voice requirements of the company, then take that information and superimpose it on top of the IP network.
In other words, if the traffic study shows that a company has an average 200 voice sessions going on at any one time, and the average duration for these sessions (i.e., phone calls) is 3 minutes, then that is the environment that, at a minimum, should be tested on the network.
If the traffic study shows that every Monday morning at 9 A.M., 35 people take part in a conference call that lasts generally 1 hour, then that scenario should also be tested on the network.
The VRA is an attempt to get a realistic look at what should happen when a company's voice traffic is deployed across their IP network.
The purpose of a VRA is to identify the peak periods, the average number of calls, and the call durations, and then use this data to determine the call load that will stress the network. A true VRA, therefore, gives a good prediction of how well a company's IP network will accommodate that company's typical voice traffic.
The result of such a stress test shows a company exactly where any problems are likely to occur by deploying voice onto their IP network, as is. Latency spots, configuration or design issues that might impact voice, faulty codecs—these types of scenarios come to light by stressing the network with real-voice parameters.
Was this article helpful?