Brought to you by Adobe
- Adobe® Acrobat® 9 Pro Extended - a complete PDF solution
- Create interactive presentations
- Bring people & ideas together
- Communicate with impact
Featured White Papers
- Technology-based learning: Extending reach & ensuring Leadership Development effectiveness (SkillSoft)
- Hosted CRM comparison guide (Inside CRM)
- 5 Strategies for Making Sales the Engine for Growth (AchieveGlobal)
Technology Industry
Industry: Email Alert RSS FeedThe five key questions you should ask before deploying VoIP
Communications News, March, 2004 by Tony van Kessel
Are you considering implementing a voice over IP (VoIP) network in your enterprise? Or have you already implemented VoIP and are not happy with the quality you are experiencing? Estimates indicate that as many as 85% or more of today's router based enterprise data networks are not ready to support VoIP without modification. As a result, an enterprise's voice and data applications can experience unacceptable degradations in quality.
How can you ensure that your network is up to snuff, both before and after deploying VoIP services? Below are five questions to ask yourself before deploying VoIP in your network, or when you want to improve the quality of your network after deployment.
1 WHAT KIND OF ASSESSMENT TOOLS SHOULD I USE?
Whether selecting a vendor partner or testing and deploying the VoIP network yourself, make sure your tools deliver granular diagnostics and reporting capabilities that allow you to effectively troubleshoot all potential VoIP issues. Your tools should be usable throughout the entire VoIP deployment lifecycle, for both assessment and troubleshooting, meaning that one tool can be used to both identify the problem and fix it.
Software-based tools offer a potential advantage because they allow faster network assessment than hardware-based measurement tools. Using a software tool, users can assess and monitor networks from one central location, rather than having to plug hardware into different network locations for accurate testing results. The software should also support advanced simulation capabilities, allowing users to test actual data application traffic (e.g., HTTP, FTP and SQL) to determine the maximum acceptable-quality VoIP capacity an enterprise can handle in the presence of a controlled amount of real application traffic.
If relying on a vendor, make sure you investigate what kinds of tools it is using and what parameters it will test on your network prior to deployment. It could mean the difference between a fast, smooth VoIP implementation and a long, painful one.
2 HOW MANY VOIP CALLS CAN MY NETWORK SUPPORT?
Network quality parameters like delay, jitter and loss, which affect the number of calls a network can support, are dependent on network design issues that range from what kind of network equipment you are using to whether your communications network reaches across the street or across the country. The best way to determine your VoIP call capacity is by simulating VoIP calls on the network, which will help you determine how many calls you can support and still maintain acceptable voice quality.
3 ARE ALL ASPECTS OF MY NETWORK ARCHITECTURE WORKING PROPERLY, AND, IF NOT, ROW DO I FIX THEM?
Figuring out how many calls your network can support is only the beginning, particularly if you get an unexpectedly low mean opinion score (MOS) reading when supporting a small number of VoIP calls. For example, when a Canadian financial institution was deploying VoIP, it found that most of its locations were able to support as many as 24 VoIP calls--but one link was showing signs of deterioration at just six calls. While this location had the same 10-Mbps WAN link as the other locations, it was not providing 10-Mbps throughput. A call to the WAN service provider fixed the problem.
Even a good MOS reading could be hiding some problems, and that is why using tools that have the ability to inspect the network at a granular level is important. Understanding what parameters are affecting the network--for instance, being able to "see through" the network to identify specific points of delay and/or loss along a particular network path--can be critical to fixing problems when they occur.
Even experienced network managers often are unfamiliar with the dramatic impact that network problems--such as delay, jitter and packet loss can have on real-time applications, such as voice and video. Unfortunately, such network problems can make these applications unusable. While IP data applications are designed to compensate for such problems, real-time applications such as voice are not. Although each network differs, here are some benchmarks that can be used as guidelines when evaluating such parameters in VoIP networks:
* delay should be under 150 milliseconds;
* loss should be below 1%, although degradation can occur with loss as low as .25%, depending on the burstiness of that loss; and
* the buffer should account for a jitter of 40 milliseconds, but, in some cases, degradation can start with jitter at 20 milliseconds or lower.
4 HOW WILL VOIP AFFECT MY OTHER BUSINESS-CRITICAL APPLICATIONS?
When deploying a VoIP network, enterprises also should avoid testing only the quality of the VoIP application. Because the various applications running on an IP network impact each other, VoIP may negatively impact other applications that are currently running on the network. Effective VoIP testing should examine the full range of services running across the enterprise.
Again, simulation is critical. Test how VoIP affects network performance when other applications, such as ERP transactions, start flooding the network, or when the financial department starts running its Oracle applications at the end of the month. Using the proper assessment tools, network engineers can add a measured amount of traffic to the network to see how it holds up under stress, thus uncovering potential problems and fixing them before they occur. In order to fully test VoIP prior to deployment, network engineers should test the network across an entire business cycle to make sure voice quality continues no matter what applications are in use.
