eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Traditional telephone services have typically gained a reputation of providing excellent voice quality and superior reliability. Consequently, users take for granted that their phone systems will provide high quality with virtually no downtime. Yet many voice over IP (VOIP) installations fail to meet these expectations, primarily because organizations have not adequately evaluated their network infrastructure to determine whether it can adequately support applications that are very sensitive to latency, packet loss, jitter and other similar performance factors.
VOIP requires a steady, predictable packet delivery rate in order to maintain quality. Jitter, which is variation in packet delivery timing, is the most common culprit that reduces call quality in VOIP systems. Jitter causes the audio stream to become broken, uneven or irregular. As a result, the listener’s experience becomes unpleasant or intolerable.
The end results of packet loss are similar to those of jitter but are typically more severe when the rate of packet loss is high. Excessive latency can result in unnatural conversation flow where there is a delay between words that one speaks versus words that one hears. Latency can cause callers to talk over one another and can also result in echoes on the line. Hence, jitter, packet loss and latency can have dramatic consequences in maintaining normal and expected call quality.
Some VOIP systems are all but unusable from the time they are implemented because nobody took the time to properly profile the existing network. Before implementing VOIP, a thorough application impact study should be completed.
Steps to a Successful VOIP System Implementation
The following five steps are critical to a successful VOIP system implementation:
Step #1: Establish a thorough baseline
Establish a thorough baseline of current network activity on all segments that will host VOIP. Failing to understand the degree to which latency, jitter and packet loss affect your network before deploying VOIP is nothing less than negligent. You must understand current network load and behavior, including any areas where latency is elevated or highly variable.
Network segments that are prone to packet corruption and loss must be diagnosed and healed. In many networks, traffic loads may vary substantially over time. As loads increase, inconsistent packet delivery rates are probable. Thus, increasing loads form the foundation for excessive latency and jitter-which are two of the most prevalent inhibitors for consistent VOIP performance.
When collecting baseline metrics, remember that network behavior varies widely as various business activities occur. Be sure to create a baseline that reflects all major phases and facets of your network’s activities. There is no acceptable reason for enduring a poor VOIP implementation when a solid, proactive baseline could have predicted inferior performance.
Step #2: Analyze store-and-forward and queuing congestion
Analyze store-and-forward and queuing congestion in switches and routers. Congestion can lead to packets spacing unpredictably and thus resulting in jitter. Keep in mind that the more hops a packet has to travel, the worse the jitter. Try to reduce hops as much as possible. Latency due to distance is a fixed fact of physics; there is nothing that can be done to change the time needed for a packet to travel a given number of meters or miles. However, devices that segment networks impose latency that is often highly variable. Jitter is primarily caused by these device-related latency variations. As a device becomes busier, packets must be queued. If those packets happen to be VOIP audio data, jitter is introduced into the audio stream and audio quality declines.
While many switch and router vendors will advertise that their products can handle a certain level of throughput, few talk about the volume of packets that can be processed during periods of peak utilization. For example, even though a switch might be able to accommodate a full line rate traffic stream when all packets are nearly maximum size, it may not be able to manage the same aggregate throughput when the stream is composed of many more minimum-sized packets. Since most Real-Time Protocol (RTP) audio packets are relatively small (just over 200 bytes for G.711), a device’s ability to process packets of that size at full line rate must be assured. Understanding how a device reacts to traffic streams characterized by many short bursts of many packets is also important.
Accurately Estimate Network Resource Utilization
Step #3: Accurately estimate network resource utilization
Accurately estimate the network resource utilization for the proposed VOIP system. Unlike traditional land lines where users have the equivalent of dedicated switch ports, a VOIP system is usually placed on a shared medium. Converged networks are what everyone is trying to implement to save money. Be sure to consider the number of simultaneous calls that will occur. With that information in hand, you can easily calculate the aggregate bandwidth that will be needed to support all calls during peak calling periods.
By benchmarking the requirements for a single VOIP call, computing the aggregate call traffic and comparing these values with baselines of existing network activity, it will be simple to determine if VOIP will “fit” in your current network. If the numbers do not add up, you may need to consider architectural changes to your IT infrastructure.
Step #4: Select a codec with higher speech sampling rates
Select a codec with higher speech sampling rates. In general, the higher the speech sampling rate, the better the potential call quality (but at the expense of more bandwidth being consumed). Make tradeoffs carefully. For example, G.711 provides excellent quality. Data is delivered at 64K bps, and the codec imposes no compression delay.
Technically, G.711 delivers 8,000 bytes per second without compression so that full Nyquist-dictated samples are provided. However, if you are attempting to pack multiple phone calls over a narrow bandwidth circuit, you may need to accept slightly lower quality to use a codec that is less hungry for bandwidth.
Verify that Quality of Service is Supported
Step #5: Verify that quality of service (QOS) is supported
Verify that QOS is supported on all segments and devices over which the VOIP traffic will travel. If latency, jitter and packet loss are the most common ills that plague VOIP systems, QOS provisions are the most effective vaccine. You should never rely on the accidental fortuity of your network infrastructure to ensure timely and reliable delivery of media packets.
Configuring network devices to prioritize RTP packets is like taking out health insurance for your VOIP calls. To lay the groundwork for VOIP, you must confirm that each network device is capable of understanding and complying with QOS parameters in packet headers. Without QOS, your VOIP packets are just “part of the crowd” on the network. With QOS, they are given VIP transit authority from their source to their destination and audio quality is safeguarded.
Conclusion
Only when all of these topics are addressed can the feasibility of VOIP be assessed. The outcome of these analyses may indicate that VOIP can be supported. However, the results may point to aspects of the network that need to be modified before they will be truly ready for VOIP.
While all of these steps might seem like a lot of work, they are the only means to assure that your VOIP system will not be crippled by adverse network characteristics. Once VOIP is deployed, periodic network health checks should become a part of your routine. As the old saying goes, the only constant is change for most network environments. Consequently, you must constantly reassess your network’s ability to satisfactorily handle VOIP traffic and to successfully converge that traffic with traditional data network functions.
Tim graduated from the University of California, Berkeley with degrees in Mathematics, Computer Science and Psychology. Tim taught undergraduate Computer Science at U.C. Berkeley while obtaining a Master’s degree in Electrical Engineering and Computer Sciences. He can be reached at tim.mccreery@wildpackets.com.