VoIP in the Enterprise -- Voice over IP has
too many hang-ups for end-to-end
deployment, but answers the call in a few key
areas you can't imagine
October 8, 1998
NETWORK COMPUTING via NewsEdge Corporation : ** NOTE: TRUNCATED STORY
**
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?
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.
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 (see "H.323 and Alternatives" on page 55). 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.
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.
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.
For more specific pointers in implementing VoIP, see the sidebars "VoIP at HQ" (page
56), "VoIP at the Branch Office" (page 52) and "VoIP for the Telecommuter" (page 48).
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.
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 (see
"Bringing Prioritization Services to Ethernet,"
www.networkcomputing.com/914/914ws1.html). 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. (See "Implementing Prioritization on IP Networks," at
www.networkcomputing.com/915/ 915ws1.html, for more on IP TOS.)
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.
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.
Shuffling Sound Cards
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 (on pages 42 and 46). 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 (see "FRADs
Make Sound Sacrifices To Get the Data Through," at www.networkcomputing.
com/902/902r1.html). 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.
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 (on page 42). 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.
<<NETWORK COMPUTING -- 10-01-98, p. PG41>>
** NOTE: This story has been truncated from its original size in order to facilitate
transmission. If you need more information about this story, please contact NewsEdge
Corporation at 1-800-766-4224. **
|
