|Managing Latency In IP
Telephony DeploymentsBY 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
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.
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.
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 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.
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.
|If At First You Don't
Succeed, Find Another ISP
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
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