is functional, but it's still work-in-progress. Here
are the details about problems, security concerns, and
the standards that are being refined. by Graeme K. Le
technology has been well out of the 'interesting toy'
category for at least five years now. It can be, and
is being, successfully used in several ways in many
situations around the world, but it still has problems
and its associated standards are still being refined.
Most of VoIP's problems are related to the fact that
the majority of IP-based Internetworks currently in
service and those on the drawing board are not designed
to provide a stable, low round trip delay between an
arbitrary number of pairs of hosts for a given set of
protocols. Unfortunately, this is just the sort of QoS
you need to provide toll quality VoIP services.
Individuals and companies are using VoIP in three basic
ways--as a replacement for PSTN in countries like the
US where most calls are time charged, as a simple voice
trunk between PABXs at different company offices where
the cost of overlaying VoIP traffic on the company WAN
is lower than the traditional method of voice trunking,
and as a more cost-effective replacement for the office
PABX and phone system.
In this last case, the logic is that by using the office
network cable system and cheaper devices to replace
a standard PABX, capital costs are lower and the increase
in maintenance and running costs incurred in running
VoIP-based telephony over the corporate LAN is lower
than that of a traditional PABX.
Since the application of VoIP as a PABX replacement
in the corporate campus presents all the problems and
issues associated with using VoIP across the Internet,
we will focus on it in the rest of this article.
on images for larger view
The average company network is made up of several Ethernet
segments, and each segment is maintained by a simple
concentrator. Each concentrator is connected to a single,
large switch in the data center. Servers and firewalls
leading to the Internet, and routers managing leased
line links to the corporate WAN are also connected to
the data center switch. Each Ethernet segment hosts
roughly 20 users and/or one or more printers controlled
by a server(s) in the data center.
Vertical cable runs in buildings and/or between them
in a campus are fiber, while horizontal runs in buildings
and data center interconnections are Cat 5 UTP or better.
This simple layout is cost-effective, easy to manage
and scales very well. Unfortunately the round trip delay
will vary widely and unpredictably.
example, when a user with a laptop running Windows 2000
attaches his laptop to the network, Windows will immediately
try to synchronize all files which the user has made
available off-line. This will heavily load that particular
segment of the network for a minute or so.
Printing in Windows is highly efficient as far as sending
a file to be printed from a client PC to a print server,
but the size of the print job depends on the printer
used and the type of file being printed. It is easy
to generate print files of several hundred kilobytes
or even a megabyte, and this will load the network and
can dramatically increase round trip delays.
receiving e-mails or doing database queries can also
increase the load on a network long enough to have a
perceptible impact on a VoIP application. It doesn't
matter if you are doing some word processing and the
network's round trip delay suddenly increases from 10ms
to 70ms for 15 seconds or so; in fact you probably would
not know it had happened without looking at some management
statistics. However, if the same thing happened while
you were making a VoIP call, then you would certainly
notice the delay.
How to switch on QoS
In a single building, you get around problems of round
trip delay by replacing concentrators with switches
and implementing 802.1q and 802.1p. You may also have
to upgrade your links between switches. You can then
hang your VoIP gateway to the PSTN (only necessary when
your telco can't provide VoIP service trunk) off the
data center switch along with the VoIP system gatekeeperthe
core gateway device that handles signaling, call set
up, tear down, etc. Next, select either software (in
the form of a suitable application to go with a full
duplex sound card in a PC) or more often hardware (in
the form of an overpriced telephone handset with a pair
of Ethernet ports) for VoIP clients.
Unfortunately, when you try and connect several buildings
with VoIP phone systems in a campus or across a WAN,
things aren't so straightforward.
In a campus with several buildings, you can interconnect
these buildings with one of the fiber versions of Ethernet,
preferably Gigabit Ethernet. In most cases, campus links
between buildings are going to be run by routers with
at least two links each to other routers for redundancy,
and usually with the data center treated as a building
on its own.
This setup provides redundancy in case one of the links
is cut and isolates broadcast storms. These routers
will be running some form of routing information protocol,
but unless they support a protocol like RSVP (there
are several RFCs for this; see the IETF's Website under
Resources) or something like it, they may not be able
to provide a stable QoS. In any case, another reason
for using routers is that they can load balance on a
per packet basis. This means that one packet in a VoIP
session may go through two routers to get from one client
to another (or the gateway to the PSTN/ISDN) while the
next packet may go through a dozen routers.
Given Gigabit Ethernet links between routers this may
not prove to be a huge problem, but in a WAN where there
are very much lower bandwidths and higher latencies
than in a campus network things are not so simple. It
gets even more complicated when the WAN links are carried
on Frame Relay networks, which can throw packets over
and above the subscribers' CIRs.
In WAN environments, one of the more common mistakes
is setting up the VoIP system with the gatekeeper and/or
gateway on one side of a low speed-2 Mbps or less-WAN
link and clients on the other side. When a client makes
a call, it contacts the gatekeeper, which then contacts
the destination client or one of the gateways on the
Once contact has been made, the gatekeeper sets up the
VoIP "circuit" between the two. When the VoIP
call is finished, one or both clients contact the gatekeeper
and requests that the session be terminated. It's the
gatekeeper which provides engaged signals, diverts calls
to "switch boards", voice mail, etc., and
does all the things a PABX does, aside from shoving
calls out on an external phone line.
The problem is that what a gatekeeper does with, for
example, a call set up request depends on whether or
not it can talk to the destination client, which in
turn depends upon the round trip delay between the client
and the gatekeeper. Even if the round trip delay between
the clients and the gatekeeper in a VoIP conversation
is satisfactory, there is no guarantee that the round
trip delay between the two clients will be within tolerable
limits during call setup, or that it will remain so
for the duration of the VoIP session.
The usual solution to these problems is to engineer
the WAN or campus infrastructure with VoIP QoS in mind
and to install gatekeeper(s) such that they are local
(i.e. not across routers and/or WAN links) to their
In such cases, provided QoS issues are successfully
addressed, gateways need not be local to their clients.
For example, an ISP may install several gateways on
their backbone network and then install gatekeepers
at each of their corporate clients. This allows clients
to share PSTN access and cut call costs, but maintain
their own "phone" system. The one problem
with this scenario is the use of NAT and/or NA(P)T.
Then, the gatekeeper has to be either a component of
the company firewall or port forwarding, and specific
address mappings have to be used to accommodate VoIP
traffic. Whether or not this can be done depends on
your specific firewall/router/gatekeeper installation.
You may very well be stuck with either a gateway plus
gatekeeper at each site, or a very big (and presumably
unacceptable) hole in your network security.
Many of the "mature" VoIP solutions currently
on the market use H.323 and its associated protocols
and standards as their foundation. H.323 is a case of
the ITU-T reusing and extending older standards; it
works but it has several problems in an IP environment,
most of which center on how it interacts with such protocols
as DHCP, LDAP, and so on.
SIP (Session Initiation Protocol) is a more recent attempt
to build a reliable foundation for VoIP that is being
driven by the IETF. SIP products are beginning to appear
and may well replace H.323 in the future. SIP shows
a great deal of promise and many key vendors are looking
closely at using it, but a lot of them are still supporting
jokers in the pack are ISVs and telcos. If ISVs focus
on either H.323 or SIP solutions and/or telcos start
selling an IP trunk service to a shared VoIP gateway
into their PSTN networks that supports one protocol
or the other, then one protocol could well come out
top, or we could see some strenuous competition in the
From a user's point of view, the obvious choice will
be the cheapest system that works reliably. VoIP may
be functional, but it is still work-in-progress.
Graeme K. Le Roux is the director of Morsedawn (Australia),
a company which specialises in network design and consultancy.
He can be reached at firstname.lastname@example.org. This
article first appeared in Network Computing Asia.