Focus: VoIP
VoIP still a work in progress

VoIP 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 Roux

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

Click on images for larger view

Enterprise speed bumps
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.

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

Clients 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 gatekeeper—the 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.

WAN don'ts
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 network.

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

Voice protocols
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 H.323 too.

The 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 marketplace.
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 graemel@moresdawn.com.au. This article first appeared in Network Computing Asia.