How to Ensure a Successful VoIP System Implementation

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 organisations 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.

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 behaviour, 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 behaviour 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: Analyse store-and-forward and queuing congestion

Analyse 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 use. 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 characterised by many short bursts of many packets is also important.