Internet Core Protocols: the Definitive Guide

October 1, 1998

Voice-over-IP Across the Enterprise Network

Voice-over-IP technology first created a buzz with the arrival of Internet telephony. Consumers got excited by the prospect of using a PC and an Internet connection to dial up friends anywhere in the world and talk for hours without ringing up long distance charges. Never mind that the products were proprietary or that the quality had more in common with tin cans and string than a digital dialogue--the possibility of long-distance calls at local rates was enough to heat up the market. Companies of all sizes have since unleashed a flood of products, from PC software for end users to VoIP-PSTN gateways for carriers.

This sudden expansion of the market has resulted in substantially improved quality, raised the level of audio fidelity and strengthened support for industry-standard protocols, such as the ITU-T's Recommendation H.323. Thus fortified, VoIP technology is beginning to carve a niche in corporate networks. The question is, is it really ready to make this leap?

Figure 1

After giving VoIP technology a tryout across Network Computing's own distributed network, we're convinced that it's a bit premature to roll it out across an entire corporatewide enterprise network. Concerns about interoperability, security and bandwidth management are creating static on the line between VoIP and widescale deployment.

For example, while we managed to coax equipment from several vendors to interoperate at a very basic level, we could do so only by using the G.711 codec. But this generated tremendous utilization across our frame relay and ISDN networks, resulting in periodic signal loss, particularly when other traffic was introduced to the network. On top of that, our attempts to use features such as "hold" or "transfer" across vendors' product lines forced calls to drop. Although H.323 specifies that these features should be implemented, vendors are not yet doing so consistently.

There's good reason to believe these hang-ups will disappear over the next year or so. Vendors in this area will incorporate support for additional low-bandwidth codecs, and feature-implementation issues also are expected to be resolved.

Figure 2

But that doesn't necessarily mean you should wait until next year to dip your toes in the VoIP waters. While the technology clearly is not in shape for enterprisewide deployment today, it is eminently suitable for interoffice, long-distance, toll-bypass service, and even for isolated LANs that have the right infrastructure.

Segmenting the Technology

Every enterprisewide corporate telephone network has the same basic components, including end-user equipment (telephones, premises wiring) and back-end gear (PBXs, trunk lines). VoIP devices generally fall into these same two camps, with IP-centric equipment replacing analog handsets and wiring, and IP-based equivalents filling in for PBX and/or interconnect wiring.

Although most VoIP equipment today employs proprietary protocols, many vendors are beginning to support the ITU-T's Recommendation H.323 standard. This highly modular version of the H.320 multimedia-over-ISDN specification is tailor-made for packet-based networks. H.323 defines a variety of node types, the most common of which are identical to those in today's typical voice networks: terminals for the desktop, gateways for bridging the packet network to a standard telephone network, and gatekeepers that set up calls and provide other administrative services to the various devices.

Figure 3

H.323's modularity makes it extremely flexible, particularly for joining an existing voice network to VoIP equipment. This concept is illustrated in diagrams throughout this article. "Existing Voice Network" (top left) depicts a typical corporate telephone network composed of traditional analog technology; "Mixed Voice and Data Network" (bottom left) shows how you might replace some components of this network with H.323 components, while preserving other portions of your analog network. Finally, "Total VoIP Network" (below) illustrates the same network as it would appear with VoIP technology installed from end to end. Although products already are available that can bring this end-to-end VoIP network to life, they're not quite up to snuff. In fact, we strongly caution against trying to deploy VoIP end-to-end across your enterprise at this time.

VoIP at Headquarters

If the voice network at your company's headquarters is anything like most large companies' networks, odds are you don't have a prayer of running VoIP over your existing data network. The bandwidth and frame-forwarding requirements of a very large-scale VoIP deployment are likely too much for your data infrastructure.

Both bandwidth and frame-forwarding can foil even the most ambitious network design, mostly because of inconsistent codec (coder/decoder) implementations in first-generation products. Different vendors use different codecs for low-bandwidth VoIP, so there isn't much hope for anything other than G.711 across vendor lines. With G.711 generating 64 Kbps of continuous traffic at each end when there is any sound, you're forced to plan for 128 Kbps of constant utilization for every VoIP call.

The other side of the coin is the rate at which this traffic travels over your data network. Codecs sample audio, then send the samples in small IP packets. A key part of the utilization problem stems from the frequency of sample transmission. Some vendors sample every 60 milliseconds, resulting in lower frame rates (and overall quality), while others sample as often as every five milliseconds, which sends 300 packets per second over your network.

Even if your infrastructure can handle the data traffic, it may not keep up with the frame-forwarding rates. Taken together, these factors can easily become overwhelming. You also must consider that the cost of building a data network that can handle these levels of traffic for hundreds or thousands of users--including all the new Fast Ethernet switches, the gigabit core switches, the OC-12 backbone wiring, the maintenance agreements and so on--could easily exceed the cost of building an equivalent PBX-based infrastructure.

That's why we feel VoIP deployments should be limited to sites with only 100 or so users on contained networks. The largest working installations we know of are in the 500-seat range on networks designed to handle the traffic generated by VoIP. But even though you may not yet be able to deploy VoIP across your large-scale backbone, this does not preclude its use in smaller installations. If you have a floor, wing or isolated department with a couple hundred users and a state-of-the art infrastructure, you could easily deploy VoIP there, bringing those users into the corporate fold through an H.323 gateway to your existing PBX infrastructure. In fact, we recommend this sort of trial deployment to measure usage and other issues in your environment.

Instead, we recommend limiting your VoIP implementations to a few key areas. Thanks to H.323's modularity, you can replace only select components on your network. For example, you might provide users in a new facility with VoIP equipment at the desktop, yet retain your existing PBX network at your corporate headquarters. Conversely, you could replace an outdated PBX cluster with IP-centric systems, while maintaining existing user-side equipment at the desktop.

Don't be hasty in your decision about where to implement VoIP, however. Every area of your network will be governed by individual factors that motivate (or discourage) the adoption of VoIP technologies. Each portion of your enterprise network has its own considerations and you have to treat each piece differently when planning your implementation. For instance, the opportunities to cut costs in remote offices are not the same as they are for local users. Similarly, bandwidth and infrastructure requirements for a large office or campus differ radically from those for a small office or a telecommuter.

To provide voice services over a digital network, you need to convert analog waveforms into packets of digital signals that can traverse the network. That's a job for codecs (coder/decoders) residing within all VoIP nodes on the network, including every end-user device and any gateways you might use. Unfortunately, because vendors have not yet implemented a common set of codecs, you will face interoperability problems with large-scale deployments.

H.323 specifies mandatory support for the G.711 codec--also known as Pulse Code Modulation (PCM)--a widely available codec used in many forms of digital telephony. But G.711 requires 64 Kbps of continuous bandwidth for every network end point. On a full-duplex voice circuit, a single 64-Kbps feed suffices, but on a packet-switched network such as IP, 128 Kbps of cumulative data is required if two users are speaking simultaneously.

The H.323 standard also specifies a laundry list of more efficient codecs that may be used. The two most popular implementations are G.723.1, which can use 5.3 Kbps or 6.3 Kbps for each end of the connection, and G.729, which uses 8 Kbps at each end. To complicate matters, some first-generation products support G.723.1 while others support G.729. So, to guarantee interoperability among different vendors' products you must use G.711 everywhere--and this means you must expect every call to consume 128 Kbps of continuous network bandwidth, or else you have to implement products from only one vendor.

Security is another major consideration. In version 2 of H.323, encryption and authentication are optional, though most implementations include no security protections at all. As a result, an H.323-aware network analyzer becomes an effortless wiretap. If you're on a shared-media network, anyone can monitor any conversation without ever leaving his or her desk.

VoIP at the Branch Office

The branch office is probably the best place to begin implementing VoIP. Branch offices typically are small and do not generate overwhelming amounts of traffic. These sites are most likely to benefit from the toll-bypass capabilities of VoIP as a replacement for long-distance services. And, if these sites do not have a dedicated PBX, you can offer users some advanced call-management features in exchange for using them as guinea pigs.

However, these criteria may not reflect your branch-office environment(s). If you house several hundred users in a particularly large remote office, chances are good that you will experience infrastructure problems. Similarly, if the remote office already has a PBX, then there is little need to introduce new equipment, unless the existing gear is at the end of its life cycle. Or, if you route your long-distance calls over a fixed-cost dedicated circuit, you might not save much money on long-distance charges back to HQ.

This last issue is perhaps the most interesting, as it is frequently touted by vendors. Though you can place many more G.723 or G.729 calls over a T1 line than you can with voice, you cannot with G.711, which uses a full 64 Kbps of bandwidth in each direction. Furthermore, many voice-compression products grant you the benefits of G.723 and G.729 with your equipment.

The real cost benefit of using VoIP as a long-haul alternative comes in the ability to use the Internet for connectivity between offices, as opposed to paying per-minute usage rates on the PSTN or competing with a private WAN infrastructure. In this scenario, it is highly feasible to buy guaranteed services from an ISP, and then route VoIP calls over that connection, instead of paying long-distance toll charges or buying a dedicated network of your own. Providing VoIP services to a field office also affords you the option of integrating these users into your corporate dialing plan, voicemail system and other services, for less than the cost of a traditional PBX.

Another problem is network congestion, an inevitable result of the high-utilization levels engendered by widespread deployment of G.711. To deal effectively with the congestion, you need to implement prioritization services at the physical, data-link and network layers of your enterprise network. This means using switches instead of hubs, and incorporating 802.1Q and 802.1p within your Ethernet switching fabric. Alternatively, token ring and FDDI provide these services, so if you have those technologies at your desktop, you're one step ahead of the game. Meanwhile, IP can provide native prioritization services across your entire enterprise, regardless of the media in use, via the already-present IP TOS (type of service) byte.

Of course, you can prevent excess traffic from crushing your network in the first place. One option is to use a single vendor's offerings--or at least use consistent codecs--in your migration efforts. This is feasible for tightly focused installations, though it's probably not realistic if you want to replace your PBXs, desktop equipment and long-haul voice services all at once.

Another way to reduce bandwidth is to use sound suppression within the end-point equipment. Sound suppression sends traffic only when the volume exceeds a predefined decibel level. Keep in mind, though, that sounds are not limited to those emitted by the primary speakers. A passing truck, ringing telephones, background chatter and the beeps on your computer all can generate an audio signal of 64 Kbps. It is very difficult to eliminate these secondary noises entirely while preserving signal quality, though headgear with directional microphones can help.

If you can't reduce your traffic, you still can sidestep major bandwidth-utilization problems if you implement VoIP on a modest scale. It's highly unlikely that every user will be using the phone at once--realistically, usage is more likely to range between 10 percent and 50 percent during the workday. Furthermore, many calls will remain local within the floor or facility where they originate and not traverse the entire network. Your company may have statistics on usage patterns that can help you select the best areas for VoIP deployment.

VoIP at the Desktop

Bringing VoIP services to the desktop isn't easy, even without the bandwidth burdens mentioned above. And yet, integrating voice and data at the desktop has strategic advantages.

VoIP for the Telecommuter

Telecommuters are a tough group to support. They need data lines and separate voice circuits--both of which rack up huge costs. And there is little hope for seamlessly integrating them into a corporatewide call-management system because the most-advanced options usually are telco-provided Centrex services. But VoIP holds tremendous promise for telecommuters. By providing a single data circuit and H.323-compliant equipment, you can integrate them into your network easily, with access to the company operator (just by dialing "0"), the voicemail system and other telephony resources. You can even reduce toll charges by letting the telecommuter place H.323 calls to remote offices. Telecommuters can also forward calls to a regional office without sacrificing any features.

Unfortunately, there are many hurdles to overcome before implementing VoIP for telecommuters, mostly involving bandwidth and network management. Users will need enough bandwidth to move VoIP traffic while simultaneously prioritizing, fragmenting and queuing other data to protect voice quality. If VoIP traffic gets caught up in the middle of a big database query over a 56-Kbps circuit, all the little H.323 packets get beaten up, turning a smooth-flowing call into something that sounds like a transistor radio at the bottom of a gravel truck.

In addition, circuits for telecommuters must be "nailed-up" during business hours, or calls to the user's equipment may not be established. For example, some H.323 devices attempt to measure latency to a remote system before establishing the call. For some of these systems, even ISDN's short call-setup times are too long, and calls will be rejected. Even if you could disable this feature, the setup time could still cause problems: Callers may not hear any rings or just two or three rings before the recipient hears any; some callers will give up before the recipient ever knows he or she has a call.

H.323's firewall-hostile negotiation mechanisms mean remote users will need direct connections into the corporate network, bypassing the public firewalls. This may or may not be in accord with your security policies.

All of these issues--prioritization, full-time connectivity and inside connectivity--practically dictate the use of flat-rate ISDN or xDSL (Digital Subscriber Line). ISDN is better-suited to the task than xDSL, since it offers two distinct channels that allow you to implement ToS (type of service)-based routing at both ends of the connection. Voice traffic can go down one circuit, and everything else can be shunted down the other.

In our survey of network managers considering VoIP, telecommuter sites were the last locations they expected to get the service. Still, the superior integration that you can provide will make you an instant hero in the telecommuters' eyes, and if you can implement the infrastructure required, the payback can be immense.

One popular way to implement VoIP at the desktop is to use software such as Microsoft Corp.'s NetMeeting or VocalTec Communications' Internet Phone. We don't recommend this path, however, because at this stage of their development, PCs have generally proved to be subpar for use as telephones, and many components would have to be added to improve them. Also, codecs can't run efficiently on a general-purpose PC that also must process interrupts, run programs and manage the operating system overhead. We have not yet found a software-based system that processes audio fast enough to be truly useful.

Remember, too, that software-based telephony gets cut off when the computer crashes, which is something PCs are still prone to do. If you can't take an sales order because your PC locked up, is the solution really cost-effective? At least with separate handsets, you can fall back on paper-based order entry in the event of a computer crash.

There is a potential alternative to the pure-software solution: The new breed of sound cards with on-board codecs perform much faster processing and are of much higher quality. Two such offerings are PhoNet Communications' EtherPhone and Quicknet Technologies' Internet PhoneJACK, which are dedicated sound cards with RJ-11 ports for use with a standard analog telephone. These cards are still taking their baby steps, however: Neither was H.323-compliant at press time (though beta versions supporting the standard should be available by the time you read this), and the performance of Internet PhoneJACK's on-board codec was rather ho-hum, though this should improve when Quicknet finalizes its dedicated software. But both cards rely on the PC being operational, since both use the operating system's WinSock interface to communicate with the local network adapter. Consequently, they are no more reliable than software-only solutions.

Finally, you can bring VoIP to the desktop via high-end dedicated telephony equipment that off-loads all telephony services from the PC, such as Selsius Systems' H.323 telephones. Selsius' telephone units look and feel like regular multifunction handsets, but they have Ethernet jacks instead of RJ-11 ports. Using dedicated processors, firmware-based codecs and a local TCP/IP stack, these phones offer the highest level of quality and reliability of any H.323 terminal on the market.

Back-End Integration

We believe VoIP today is best-suited for use at the back end, where it can be used as a toll-bypass service. Most high-end vendors are working this angle, with first-generation products focusing on the H.323 gateway space.

H.323 gateways come in many flavors, as you can see in the "Mixed Voice and Data Network" and "Total VoIP Network" diagrams.

Toll-bypass gateways, for example, work as a VoIP bridge between voice networks, conceptually similar to the voice-over-frame-relay products we tested earlier this year. This kind of gateway lets you take voice traffic from one PBX and route it to another PBX (local or remote), using H.323 and IP as the interconnect technology instead of voice trunks. Unlike voice over frame relay, voice over IP works with any underlying network technology.

This type of implementation lets you use the Internet--or a private data network--for interoffice calls, greatly reducing long-distance toll charges, particularly for international calls. Let's say your company spends 9 cents a minute on calls between offices, paying $10,000 on such calls every month. If introducing VoIP trunks can trim those net charges to 5 cents, you'll save 45 percent on your monthly bill. That's a savings of $54,000 in annual usage costs alone.

H.323 and Alternatives

Of the dozens of VoIP products available now, only a handful support any standards-based implementation. The only standard with any notable presence is the ITU-T's Recommendation H.323, a version of the H.320 Multimedia-over-ISDN standard optimized for packet-based networks such as TCP/IP. Although H.323 is not specific to IP (it could also be used with IPX or AppleTalk), it relies on some IETF technologies--most notably RTP (Real Time Protocol) and RTCP (Real Time Control Protocol), which were developed within the IETF's Multimedia Working Group.

This ambivalence toward IP has created some sticky points of operation. For example, the call-setup negotiation routines in H.323 dictate that the end-point systems allocate random port numbers for the RTCP control channel and RTP data channel. While this allows for considerable portability across different kinds of packet-based networks, it makes implementing H.323 across an IP firewall very difficult. Rather than using a well-known port for all voice traffic, every H.323 node on the network must be able to listen for and send on any port number above 1,024. This is an impossible request for most corporate networks; no organization will open its entire corporate network to all UDP and TCP traffic.

You can work around this, of course. The easiest solution is to contain all H.323 traffic within a specific region of your network. If you filter traffic between your corporate backbone and your branch-office networks, you will need to keep the H.323 traffic contained within those sites and rely on voice trunks for any interconnection services. Another option is to use a firewall that is H.323-aware; such products are becoming widely available.

Another VoIP standard in the works is SIP (Session Initialization Protocol). It is currently under development within the IETF's Multimedia Working Group, with a particular focus on IP implementation. SIP offers many of the same architectural features of H.323, but relies on IP-specific technologies, such as DNS, as well. It also incorporates the concept of fixed port numbers for all devices and allows the use of proxy servers, both of which ease firewall implementation concerns.

Another standard making the rounds at the IETF is SGCP (Simple Gateway Control Protocol), which was developed by Bellcore. SGCP introduces a new call-management tier known as the Call Agent, which off-loads much of the signaling intelligence from the end node. This makes it a good fit for traditional telephone handsets. SGCP also promises to reduce the delays associated with H.323's use of signaling translators and TCP/IP.

Finally, at press time, IPDC (Internet Protocol Device Control) was announced. Developed by Level 3 and friends, IPDC is intended for use between centralized switches and IP-based gateways, providing integration and management on a very large scale.

SIP, SGCP and IPDC are in draft form and a long way from implementation. Until then, limit your purchases to products that support H.323. Although only a small percentage of vendors support H.323, it's your only guarantee of interoperability. No matter what else a vendor tells you, if a product doesn't support H.323, tell the rep to come back when it does.

Another class of H.323 gateways consists of those that flip the coin, bridging H.323-based desktop systems with an existing voice network, as shown in the "Mixed Voice and Data Network" diagram.

These gateways essentially act as PBX systems in their own right, routing calls between H.323 clients on one side of the gateway and trunk lines on the other. Assuming you have sufficient bandwidth, you can deploy islands of H.323 that you join using analog or digital circuits.

Finally, we come to the H.323 gatekeepers. These are similar to the H.323 gateways described above except they use H.323 on both the desktop and back-end segments of the network (as shown in the "Total VoIP Network" diagram), eliminating any need for voice trunks. H.323 gatekeepers provide lookup and routing services for the downstream devices under their control, allowing different gateways to be deployed across a network while preserving local extension management and access services.

Calling VoIP as We See It

Most products available today fall into one of the first two categories, either supplying VoIP bridging services for the toll-bypass market or providing PBX/PSTN integration services to H.323 desktop users; there has been little product development to date in the H.323 gatekeeper category. Vendors in the first camp include big-name data networking companies such as Ascend Communications and 3Com Corp., as well as newcomers such as RADVision and VocalTec.

As might be expected, traditional PBX vendors, such as Northern Telecom and Lucent Technologies, are working on H.323-based gateways that plug directly into their existing product lines. Given their familiarity with voice networks, expect their solutions to carry more voice-specific features, though these features may have to be used with these vendors' PBXs as well.

Typically, these VoIP systems include an Ethernet/H.323 interface, as well as POTS, T1 or ISDN PRI interfaces to the voice network. Dialing patterns route calls to specific destinations according to predefined masks (dialing "8-XXX" might route a call to an H.323 gateway at a New York facility, for example, while "9" might route the call to a PSTN gateway).

Some of you are already taking advantage of VoIP's promise, according to a recent Network Computing survey of 200 IT managers: Roughly half of the respondents stated that they were either already rolling out VoIP technologies or planning to do so soon. The two primary reasons for their decision: to enhance CTI (computer-telephony integration) services, and to reduce long-distance charges.

But are these valid reasons for adopting VoIP? Our informal testing of VoIP technologies indicates that bypassing the long-distance network can certainly bring you tremendous savings on your corporate phone bill--as long as your network meets certain conditions. As for enhancing CTI's capabilities, we don't believe the performance and reliability of PC-based telephony is up to par for widescale business usage. One silver lining: Call management using IP-based telephony equipment should be easier than it now is with traditional gear.

Worse, premature deployment of VoIP can have an explosive impact on your infrastructure. Of the survey respondents who said they have no current plans to roll out VoIP, most blamed the state of their network as the critical stumbling block. This is a telling statistic, and one borne out in our own testing. Simply put, VoIP traffic can crush your network if you haven't designed your infrastructure to support the technology.

But at the same time, we are confident that many of these drawbacks will be resolved as the market for enterprise VoIP matures. In fact, we enthusiastically await next year's offerings, which are sure to show considerable improvement over the current crop. Watch for VoIP technology to take root in many enterprise voice networks over the next two years, particularly as investments in traditional telephony equipment reach the end of their amortization schedules. VoIP will likely appear in smaller implementations even sooner, so there's little reason to wait much longer to examine this technology for ways you can incorporate it into your network on a limited basis.

Written by Eric A. Hall.
Copyright © 1998 CMP Media, Inc. Used with permission.