Just some basic stuff> 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.
|
