As much as vendors would like you to believe, employing voice applications over your existing TCP/IP data network is certainly not as simple as plugging in VoIP-enabled phones and installing software to make them work. Combining voice and data networks into one seamless operation can be tricky.

Before you attempt to run voice communication over your TCP/IP network, familiarize yourself with the following key issues in order to avoid any unpleasant surprises.

Voice vs Data

VoIP enables the human voice to be sent over networks as data “packets”. These packets are then reorganized into the human voice upon reaching their final destination. One would think that non-voice traffic travels over the network in the same manner as data traffic. After all, data is data, right?

Wrong. The reasons are that TCP/IP networks do not generally deliver “packets” of data in the same order, along the same route, or even within the same time frame. This is not a problem for normal data downloads or data transfer, but for voice conversations it is critical that “packet” information is transferred without packet loss or latency.

Bandwidth

It goes without saying that in order to run voice over a TCP/IP network, sufficient bandwidth is required. Most network services customers are familiar with the raw bandwidth of each of their connections. The key issue here is not to confuse “available” bandwidth with “total” bandwidth. For example, a T-1 devoted to data networking may have 1.5 Mb of raw bandwidth. That does not mean, however, that the entire 1.5 MB of bandwidth will be available for voice applications.

Packet Loss

Inherent in any network is the inevitability of “packet loss”. Packet loss refers to the percentage of data packets that travel the network then fail to reach their final destination. Packet loss can be tested and measured using network analysis tools. If you test and determine a packet loss of 3% or more, your existing network will not successfully handle voice traffic.

Keep in mind that packet loss increases dramatically when a network is overloaded with traffic. In fact, a network may even become unusable for voice applications when approaching their maximum bandwidth capabilities.

Jitter

Packets of voice information traveling across a network take varying amounts of time to go from one end to the other. This variation is referred to as “jitter”. The receiving end of a VoIP voice call “buffers” packet information so it can be played as a smooth and unbroken stream of voice audio. The depth of jitter (measured in milliseconds) can and should be measured. Always be sure that jitter settings match the behavior of the network. Dropouts may occur if the setting is too low, and delays in the audio will occur if the setting is too high.

Latency

The total amount of time it takes for a packet of voice information to get from one end of the network to the other is called latency. Latency is also measured in milliseconds. A latency of 200 or more milliseconds can result in echo, especially if the connections at the receiving end are not all digital. A latency of more than 400 milliseconds results in both parties of the call constantly “interrupting” each other, then waiting for the other person to finish. This situation is simply not acceptable for even the most patient of callers.

Codecs

A codec is responsible for converting the analog voice signal of a phone call to digital packets of information - then converting them back to analog voice audio. There are many types of codecs available depending on available bandwidth and the quality of the audio that is desired. First determine the amount of voice data traffic you anticipate having, then choose the appropriate codec. The G.711 codec is widely used throughout North America and although it consumes up to 83 kB per second of bandwidth it provides toll-quality voice connections.

Configuration for Quality of Service (QOS)

The most complicated and difficult issue you will encounter will be how to successfully configure the network to handle both data and voice packets simultaneously. File downloads and other data transfers that occur at the same time as voice calls can easily interfere and even interrupt these voice conversations if the network is not configured properly.

It is the job of the routers to treat voice packet information in a special way. Without routers giving voice packets special treatment, they will almost always lose the battle when in direct competition with data packets. The configuration of routers to do this properly is called “Quality of Service”, or QOS. There are four types of configurations of QOS. Each provide different levels of efficiency for handling voice and data traffic simultaneously.

1) Best-Effort QOS
This configuration is the most inefficient and one that most network routers are configured by default. Voice traffic may sound fine with this configuration, although any large data downloads will easily interrupt voice conversations.

2) Differentiated Service
One way to solve the problem of competition between voice and data packets is to configure routers to simply determine the difference between the two types of information, then handle them accordingly. Differentiated service allows for routers to use different schemes for handling the two types of traffic.

3) Dedicated Service
Routers can be configured to ensure that sufficient bandwidth is always available for voice traffic. This configuration tells the router to never use the dedicated bandwidth for data transmission. Although it can be complicated to configure routers with dedicated service, it does a good job of eliminating the problem of data traffic interfering with voice communications. One major disadvantage, however, is that the “dedicated” portion of the network will go unused when there is no voice traffic.

4) Guaranteed Service
The most complex and expensive option to packet competition is guaranteed service. This configuration allows routers to set up dedicated but temporary bandwidth for each individual call. When a call has ended, the bandwidth then becomes available for other voice calls or data traffic.

The ability to use data networks for voice applications is an attractive one although not always simple and straightforward. Proper planning and testing will help you avoid the inevitable pitfalls of configuring voice applications over data networks.

Submitted by: TelCon Associates, Inc.