First Quarter 1998

BY JOEL HUGHES

The quality of IP Telephony is an often discussed but largely misunderstood subject. Generalizations such as, "It's unacceptable over the public Internet, but okay over an intranet," seem to be typical. The reason for these characterizations is that it is very difficult to talk absolutely or quantitatively about anything related to the Internet, much less something as subjective as a voice conversation transported over it. In fact, the quality achieved by IP telephony can vary greatly and depends on a number of factors. Gateway equipment, phone systems, client software, telephone carrier(s), ISPs, and even time of day impact the performance of an IP telephony call.

Delay, or latency, between the two parties of a call is one of the most crucial factors in determining the subjective quality of any phone call. In IP telephony, minimization of latency is the primary goal of both gateway design engineer and network architect. The total end-to-end delay of an IP telephone phone-to-phone call is equal to the sum of the delays through the gateways and the delay in the IP network between the gateways. This paper will focus on the components of delay throughout an IP telephony call and detail methods to minimize its impact in the areas under control.

GATEWAY DELAY COMPONENTS
An IP telephony gateway can be viewed as a collection of three subsystems: a telephony interface, a compression engine, and an IP network interface. The delay through a gateway is the sum of the delays in each of these subsystems and the buffering required between them. Remember that in a phone-to-phone IP telephony call, two gateway delays will be encountered, one at the calling party's gateway and a second at the called party's gateway.

Telephony Subsystem Delay
There is generally very little delay in the PSTN or PBX interface to the gateway. An incoming analog signal is digitized to 64 Kbps PCM (pulse code modulation)-- it may already be a digital signal in the case of T1 or E1 -- and is passed on to the compression subsystem. Delay may be introduced in the buffering between the telephony subsystem and the compression subsystem, especially if the compression is not performed on a dedicated DSP processor already servicing the telephony interface. A DSP which is handling the incoming PCM samples can also perform the voice compression task without introducing buffering and data transfer latency. Beware of compression which is performed on processors located across a bus and running on a different operating system from that of the telephony interface. In this case, potential delays may show up in the data handling between the subsystems.

Compression Subsystem Delay
There can be significant delays in the compression subsystem due to the difficult task of implementing the voice coding (or vocoding) function. Latencies here are driven primarily by the vocoding algorithm being utilized. The G.723.1 algorithm, for example, is based on a 30 ms frame size and contains an additional algorithmic delay of 7.5 ms. This means that it takes a minimum of 37.5 ms for a PCM sample from the telephony interface to be encoded and passed out of the compression engine. Many gateways also perform echo cancellation, DTMF tone detection and regeneration, and fax detection in the compression subsystem. An optimized DSP software architecture is critical to support the operation of these functions while maintaining low latency.

IP Subsystem Delay
The IP subsystem is also a major contributor of delay in a gateway. The principle job of this subsystem is to packetize the compressed voice data received from the compression engine and send it out of the gateway onto the data network. Historically, such packet protocol engines are optimized for file transfer and work on relatively few, large data packets and do not interface directly with real-time data streams. To achieve high-quality IP telephony communications, a gateway must send a full duplex stream of many, small data packets in real time to satisfy the time division multiplexed telephony interface. This packet-to-circuit (or asynchronous to synchronous) translation is implemented by adding buffers between the subsystems. Again, minimization of delay in the gateway is driven by the implementation details of these system buffering issues. Key architectural features which allow high performance in the IP subsystem include use of a deterministic operating system, dedicated processor(s) running protocol stacks, and dedicated hardware interface(s) to the compression engine.

Gateway Architecture and Performance
In general, the more dedicated hardware the better, and the more tightly coupled the subsystems the better. A gateway built from the ground up based on real-time constructs and paradigms will have lower latency and will be immune to variable latency under load, a typical problem with gateways built on standard operating systems without dedicated hardware. It has been shown that most humans cannot distinguish delays below approximately 250 ms, or one-quarter of a second. This means that a good gateway implementation, leaving up to 150 ms for the IP network delays between gateways, should introduce under 100 ms of latency. A simple test can be performed to test a gateway's latency. First, take a single gateway and "loopback" the IP networking interface such that it sends packets to itself with essentially no IP network delay. Then, after establishing a full duplex call with two phones through the one gateway, play tones into one of the phones. Using an oscilloscope, measure the delay between the start of the transmitted tone at one phone and the beginning of the received tone at the other phone.

NETWORK DELAY COMPONENTS
After we have quantified the delay in our gateway, we need to understand the latencies in the IP network which will transport the compressed voice packets between our gateways. This is the wild card in IP telephony. The wonderful thing about IP is that it has become the nearly universal protocol for sending data among computers, enabling the Internet to spread like wildfire throughout the world. The down side is, in the case of IP telephony, that an infinite number of configurations and routing possibilities exist, making it impossible to predict delays between gateways arbitrarily connected to each other over the worldwide Internet. This is what has gestated the "Internet versus intranet" discussion. Using the Internet, we have limited information about, and virtually no control over, the path the voice packets might take between our two gateways. We could have long delays, high packet loss and variable packet jitter. We could have good performance. The performance may change over time. The point is that we don't know.

In an intranet configuration, we have very good information about, and significant control over, the path the voice packets take between our gateways. In this sense an "intranet" can be defined as a network of routers and switches which we have good information about and control over. It might be a corporation's private data network, or it could be a virtual private network ("VPN") service purchased from an ISP providing premium service. In either case, our knowledge and control of this IP transport allow the creation of a high-performance IP telephony network.

Packet Delay
Packets transported on an IP network are delayed passing through each router they traverse. The delay in a router will depend upon its configuration, performance, capacity, and load. A rule of thumb is that each router introduces about 10 ms of latency; each router encountered on a packet's path is typically referred to as a "hop." Many factors can negatively impact this number, most notably a high volume of large data packets which arrive simultaneously with our IP voice traffic at the router for service. However, in a managed network it is possible to prioritize IP telephony ports over generic data ports or to reroute this time sensitive traffic to minimize router latency.

Packet Loss
In the same way that packets are delayed through a router, the possibility exists that packets may be lost in a router. Routers are designed to transmit all incoming packets to the correct outgoing port, but an overloaded router can choose to drop entire queues of IP packets. The loss of packets is detrimental to the performance of an IP telephony call. Although most gateways employ vocoding algorithms and techniques to handle this possibility, packet loss of more than 5 percent has a significant, adverse effect on the quality of the conversation. Again, through network planning and management, packet loss can be minimized and often eliminated.

Packet Jitter
Packet jitter is related to delay and can best be described as the variation in packet delay. That is, in a packet switched network, not all packets experience uniform delay through the network. Packets may take different paths between the same gateway endpoints. Router algorithms may introduce variable delays based on congestion and loading.

IP Network Architecture and Performance
IP network performance over the Internet will always be highly variable and often unacceptable. As we have seen, performance over a managed network or intranet can be very good and relatively quantifiable. In the past, intranets have been implemented using expensive leased-line networks by large corporate entities and government agencies. But increasingly, ISPs and data communications providers are offering cost-effective virtual private networking services with guaranteed quality of service (QoS) and round-the-clock maintenance. The ability to co-locate a gateway in an ISP's point of presence has also become an inexpensive way to minimize IP network latency, eliminating a couple of router hops at each end of the IP telephony network.

Given the proliferation of IP networking service providers and product offerings, it is now possible to create an IP telephony backbone with relative ease. Costs are not prohibitive and packet delay, loss and jitter can be managed to provide excellent quality around the world. In such a managed network, delays can be kept below 100 ms, packet loss under 3 percent and jitter below 60 ms.

CONCLUSION
The deployment of IP telephony systems is accelerating rapidly, as the return on investment for these systems is a simple calculation and the results of the calculation easily justify the deployment of systems for many companies. To optimize the performance of their IP telephone systems, companies deploying such systems must pay attention to the architecture of the system they select and must take a proactive approach to managing their bandwidth availability and the priority of their IP voice traffic. These issues can be overcome most easily on a well-managed intranet or virtual private network, and ISPs are offering better and better services for resolving these issues on the public Internet as well. In either case, IT managers can deploy systems today with confidence that they can achieve the quality necessary to make this a viable technology.

Joel Hughes is director of IP Telephony at Natural MicroSystems Corporation. Hughes oversees the company's efforts in the Internet telephony market, including product development and new business development. Natural MicroSystems is a leader in open telecommunications, providing hardware and software technologies for developers of high-value telecommunications solutions. The company's state-of-the-art technology enables a growing international network of OEMs, VARs, systems integrators, and service providers to reduce time to market, leverage development resources, and offer truly global communications products. For more information, visit the company's Web site at www.nmss.com.

Several months ago, I had the chance to perform testing on a pair of IP telephony gateways between Tokyo and Sunnyvale, CA. Calls were originated by calling into a gateway in Tokyo (analog connection), then transported over IP via the Internet to a gateway in Sunnyvale where an outbound call (analog connection) was placed to Boston. Each gateway had an inherent, full duplex latency of 120 ms, employed a programmable jitter buffer, and utilized a 40 ms packet size. Initially, the quality varied widely depending on the time of day the calls were placed. This is what we found:

The testing commenced each night around 9 P.M. Tokyo time, just when our engineers were getting to work at 8 A.M. in Boston. Quality was found to be quite good the first couple of hours. We measured a one-way delay of approximately 180 ms between the gateways, which, when added to the 120 ms of latency in the gateways and an 80 ms jitter buffer gave us a talker to listener delay of around 380 ms. During this period we also measured the packet loss to be less than 3 percent and the packet jitter to average under 40 ms.

At 11 P.M. Tokyo time, however, things changed. We found out that local calling is not free in Japan until 11 P.M., at which time everybody hits the Internet to surf the Web. After 11 P.M., our gateway measured one way delays from 220 ms to 480 ms, packet loss of up to 30 percent and jitter in the 240 ms range. Clearly the Internet was getting jammed and our IP telephone calls were suffering badly. Is this a case of "unacceptable over the Internet?" Upon further investigation we found an interesting phenomenon. Our engineers in Boston continued to hear us quite well after 11 P.M.: It was the Boston to Tokyo leg of the call which had poor quality. The Boston group continued to see reasonable delay, packet loss and jitter measurements - it was the parameters in Tokyo that changed radically. Digging deeper, we were able to identify the router at our Tokyo ISP which was overworked, dropping packets and adding large delays.

Re-running the same test using a different ISP in Tokyo produced startling results. We consistently measured one-way delays of 150 ms, packet loss under 3 percent and jitter averaging under 40 ms. This did not change at 11 P.M. Tokyo time. We had simply found a better ISP. The lesson here is that the ISPs make the difference. Managing the IP telephony backbone, in this case the selection of the ISPs at both ends, makes a world of difference.