April 1998
By Andrew Cray
Voice Over IP
Voice Over IP: Hear's How
Ready to make the call on IP telephony? Hold the phone—and hear all about it first
|
|
|
Start shipping voice traffic over the data network—and stop
paying phone bills. That's the unmistakable message of voice over IP,
and net managers who thought they couldn't do it until tomorrow may
want to think again. With 17 vendors now shipping VOIP gateways, they
could start reaping the rewards today. But can today's network take
the talk? Fact is, latency and low bandwidth will likely pose lethal
threats to call quality—and that deadly duo doesn't discriminate.
"I'd say 99.9 percent of IP networks aren't ready for voice," says
Debra Mielke, senior consultant at Telechoice Inc. (Verona, N.J.). So
where does that leave net managers who want to run everything over one
network? Listen up: Data Comm has devised a three-part plan that can
help them cash in on VOIP without crashing the network—or their
careers.
First, find out about those VOIP gateways, the tools that packetize
voice traffic for transmission over IP networks. They differ on
everything from calls handled and faxing to encoding schemes and
traffic priorities. And keep in mind there are no standards—so
products from different vendors won't work together.
Second, test the network to find out exactly how voice tr
affic will
fare. Data Comm is offering help in the form of traceroute and ping
commands that net managers can use when performing their checkups.
Third, pick a patch. If testing reveals a weakness, there could be
a way around it. Too many delays? Eliminate some hops. Peak loads too
high? Cut back on bursty traffic—and maybe hold off on those
batch file transfers until business hours are over.
Those are the steps to take before making the IP call. And there
could be a penalty for speaking too soon. "If it doesn't work well, I
hope you have another job lined up," warns Mielke.
Vox Operandi
Ask corporate networkers what VOIP is really all about and most
will say savings. George Emmett, systems manager at commodity trading
firm Kanematsu USA Inc. (New York), is no exception. Since ditching
leased lines in favor of IP telephony, he's pared bills from 50 cents
a minute to 17 cents a minute on calls to corporate HQ in Japan. What
about worrisome issues like quality? "The bottom
line is, it works,"
he shrugs.
|
Figure 1: Hear it Here
|
But how does it work? That's a question net managers should really
get the answer to before casting their lots with IP-routed calling.
Put simply, voice travels over the corporate intranet or Internet
rather than the circuit-switched public network. Most corporate-class
IP telephony apps use gateways that sit between the PBX and the
router, converting calls into IP packets and shunting them onto the
network. When the packets hit the destination gateway, the voice is
depacketized and sent out via local phone lines (see
Figure 1
).
|
BUILD YOUR OWN CUSTOM TABLE
Table 1: Vendors of Voice-Over-IP Gateways
|
How hot is VOIP? Many analysts say it is the future. Even some
providers have begun to offer VOIP services (see "Voice-Over-IP
Services: The Sound Decision," March 1998;
http://www.data.com/roundups/decision/html). And since Data Comm last
took a look in 1997, the number of vendors hawking VOIP gateways has
soared to 17—from just 6 (see "IP Telephony Gateways: Long
Distance With a Local Touch," June 1997;
http://www.data.com/roundups/ip_telephony.html
). A sure sign the
technology has grown from fad to must-have is the entry of some
big-name players into the market: Bay Networks Inc. (Santa Clara,
Calif.), Cisco Systems Inc. (San Jose, Calif.), and 3Com Corp. (Santa
Clara) all are integrating VOIP into their products. But all that
muscle isn't discouraging such hopefuls as Mico
m Communications (Simi
Valley, Calif.) (a Northern Telecom company), Netspeak Corp. (Boca
Raton, Fla.), Vienna Systems Corp. (Kanata, Ontario), and Vocaltec
Inc. (Herziliya, Israel), which have their eyes on the pie as well
(see
Table 1
). What's more, Bay recently bought a 9 percent stake in
Netspeak and has plans to integrate the vendor's gateways into its
Baystack router line.
|
|
But with that much action in the gateway arena, customers should
use extra caution in contemplating the gear. The devices come in two
forms: as a router or RAC (remote access concentrator) with VOIP cards
slotted in as extras, and as a standalone chassis or PC server that
takes voice cards.
As for whether one approach is better than another, that depends.
Router and concentrator vendors say their products move calls faster
than standalone gateways because they shunt packets right into the
router queue and out to the wide area via
the WAN interface. "It takes
out the first hop," says Mark Monday, product marketing manager at
Cisco, who estimates his gateway's direct connection shaves "a couple
of milliseconds" off delay time. Standalone chassis or PC gateways, in
contrast, send data through an Ethernet interface and force it to
travel across the LAN to get to the router. Direct access confers
another benefit: limited prioritization. Standalone devices can't bump
voice packets to the head of the router queue.
On the other hand, using such a gateway means using a single
vendor's routers or RACs throughout. VOIP gateways from different
vendors are not interoperable, so in multivendor networks standalone
devices might be the better choice.
Numbers, Please
After settling on the type of gateway, the next thing to consider
is size. The strategy here is simple: Find one that fits the phone
bill. If only a few calls are getting the IP treatment, a single voice
card slotted into a PC or standalone chassis will do. Prod
ucts from
Hypercom Inc. (Phoenix), Micom, Phonet Communications Ltd. (Herziliya,
Israel), and RADvision Ltd. (Tel Aviv, Israel) meet this description;
they handle four or eight calls per card. Net managers whose VOIP
needs are more demanding might want to choose a 24-port T1
(1.544-Mbits) card, which is available from three-fourths of the
gateway vendors. (Outside North America, such cards offer 30 ports,
since they need to connect to fatter E1 [2.048-Mbit/s] pipes.)
Scalability is something else to consider, and it depends on the
number of slots in the chassis or PC server. Netrix Corp. (Herndon,
Va.), for example, sells a chassis with seven slots, which means one
box can handle 168 simultaneous calls. But server-based gateways
typically top out at 96 calls (120 outside North America), since most
PCs have only four spare slots. Micom is an exception in that it
supplies a six-slot server, but don't be fooled: The vendor offers
only four ports per card, so the maximum number of calls it can handle
rema
ins 24.
|
NS Lookup
|
Companies whose call needs are higher can choose an access
concentrator. Right now the biggest of the big boxes is the IEN 6000
from Hypercom: It can scale to 1,024 voice ports. Still not satisfied?
Stick around: ACT Networks Inc. (Camarillo, Calif.) plans to launch a
product later this year that it says will handle 10,560 simultaneous
calls (such products are mainly designed for carrier networks).
But phone conversations aren't the only type of "voice" traffic
likely to be transmitted via IP. That's why most gateways now can
handle fax calls as well—and why some even can take on video and
dial-up modem communications.
How do gateways go about handling the various types of calls? They
monitor the line to see if an incoming call is fax or voice. If it's
f
rom a fax, they allocate an extra-large buffer, since such calls are
intolerant of dropped packets. They also encode the calls differently,
since voice can withstand the pressure of compression better than fax
and modem calls.
Spec and Squeeze
While it's important to remember that VOIP gateways are still
proprietary, interoperability could come later this year. A big step
toward standardization was taken in February, when the ITU
(International Telecommunication Union) ratified the latest version of
H.323, which specifies how voice and video gateways can communicate
with one another over IP.
Will H.323 solve all the problems? It's tough to say. Right now, it
doesn't address encoding schemes, prioritization, or security. And
even though vendors say they back the spec, few have conducted
interoperability tests. As a result, "No one can say exactly" when
products will be able to work together, according to Ilan Cohen, chief
technology officer of Vocaltec.
In the meantime, most v
endors are adopting a common ITU mechanism
for encoding voice, known as G.723.1. Aside from helping products work
together, it also can compress voice from 64 kbit/s all the way down
to 6.3 or 5.3 kbit/s, depending on configuration.
But many vendors also offer a choice of proprietary encoding
schemes with different levels of voice quality and compression. Lucent
Technologies Inc. (Murray Hill, N.J.), for instance, uses a technique
that can compress voice to 7.3 kbit/s; other vendors can compress to 8
kbit/s and 16 kbit/s.
But squeezing calls as much as possible isn't necessarily a good
thing. The general rule on compression? The lower the bandwidth, the
worse the reproduction. David Shaw, a software engineer for Elemedia
(Holmdel, N.J.), a Lucent research division, generally likens
compression to concentrating orange juice and then rehydrating it:
Some of the flavor is lost in the process. Squeeze things even more
and there's still less punch. John Young, vice president of product
development
at Hypercom, has noticed a different analogy being made.
"A lot of people say the quality of such calls is robotic," he
says.
Compression affects more than the quality of the voice. Some
algorithms, particularly G.723.1, wreak so much damage on the signal
that it loses the ability to carry DTMF (dual-tone multifrequency)
tones, those variously pitched notes that sound when punching the
keypad on a phone. Fortunately, almost every vendor has found a way to
address this problem: They typically encode DTMF tones separately and
regenerate them at the other end. And vendors backing the G.729 or
G.729(A) encoding schemes don't even need to do that, since these
schemes can carry voice and DTMF tones without a problem.
|
MORE INFO
On Top of The Hops
|
Something else
to keep in mind about compression: Those low rates
might not really be as low as they seem. That's because every packet
in a VOIP call carries a 40-byte TCP/IP header, which tells the router
where to send the signal. Such overhead can actually boost what's
described as a 6.3-kbit/s transmission to well over 10 kbit/s,
according to Shaw.
And it's just such overhead that the VOIP skeptics like to seize on
when they praise other technologies. Those 40-byte headers prompt many
vendors to compensate by cramming as much of the voice signal as they
can into a single packet. So instead of putting 30 ms of voice into
one packet, they might store 60. Doubling the payload doubles gateway
latency—and gateway latency reduces quality. Frame relay and ATM,
in contrast, use only 6-byte and 5-byte headers.
Delays Ahead
Still, when it comes right down to it, latency remains the prime
cause of quality problems. And encoding, decoding, and compression
delays make up around half the total latency us
ers are likely to see.
The G.723.1 scheme, for example, has built-in delay of 30 ms. That's
how long it takes for the signal to be converted to a frame of
digitized voice. That frame then has to be compressed, packetized, and
shunted onto the wide area, which adds at least 2 more ms. The result?
Encoding delays of at least 32 ms for most G.723.1 gateways, and a
similar latency at the other end (most vendors say their latencies are
actually higher) .
And if round-trip latency is too long, then call participants are
likely to talk over each other. Consequently, net managers who want to
get an accurate read on acceptable delays should use the round-trip
latency figure when deciding on a gateway.
There's more. Corporate networkers also should consider the jitter
buffer, a necessary part of the decoding sequence. Since IP packets
take different routes to their destinations, they usually arrive out
of sequence. A buffer of 50 to 100 ms is needed to store the packets
and resequence them before sendin
g them to the user. If the network
already is carrying a lot of bursty data apps, a bigger buffer would
be needed—adding to overall delay. The delay introduced by the
jitter buffer usually has to be set manually by an administrator, so
while RADvision, for example, sets a default 40-ms buffer, net
managers can adjust it up or down.
And down is probably the way they'll want to go, since a shorter
jitter buffer means less delay. But there's a trade-off: Set the
buffer too short, and some of the voice won't arrive in
time—which means dropped packets and clipped speech. Fortunately,
some vendors—including Cisco, Motorola Inc. (Schaumburg, Ill.),
Hypercom, and Netrix—offer intelligent dynamic buffers, which
continually change in size according to network variability. The one
sure way to cut down on the size of jitter buffers? "You want to have
plenty of bandwidth," says Dave Alcott, senior technical associate at
Lucent's integration division.
With all those caveats, is it any su
rprise that vendor measurements
for gateway latency are all over the map? "It's hard to get
measurements that you have any technical confidence in," admits Kathy
Meier, general manager for Internet communications at Lucent. Cisco,
for example, cites a delay of 65 ms; Hypercom, 128 ms; Lucent, 100 ms;
and RADvision, 150. And all of those are one-way measurements.
Further, Cisco's measurement incorporates the average delay added
by the variable jitter buffer. Other measurements may reflect the
number of frames carried in each IP packet, the encoding scheme being
used, and the time it takes to move the frame into the network's
router queue. The upshot? Get vendors to break down the
numbers—rather than taking latency claims at face value.
Table Troubles
Of course, it helps to know how gateways route the calls from one
phone to another. The secret lies in routing tables: When a call comes
from the PBX, the device captures the destination phone number and
matches it to the IP address
of the gateway nearest the termination
point.
And the routing table is also where the hassles lie, since net
managers have to configure each of them individually. But some
vendors—including E-Fusion Inc. (San Jose, Calif.), Inter-tel
Inc. (Chandler, Ariz.), and RADvision—try to take the pain out of
the process with server-based software known as a gatekeeper. The
gatekeeper contains a large routing table for all voice calls on the
network, which eases configuration. Gateways have to register their
presence with the gatekeeper, along with all the telephone numbers
they're terminating, before making use of the routing table. Then,
when a gateway wants to send a call out to another gateway, it needs
to consult the gatekeeper, which grants permission to route the call
and forwards the IP address of the destination gateway.
|
MORE INFO
It's a Ping Thing
|
There's more to gatekeepers than routing tables. The software also
can authenticate gateways as they join the VOIP network and grant them
permission to, say, route calls via some gateways but not others.
Load-balancing is another possibility, since they can intelligently
shift calls from congested parts of the network to less busy links.
Still, many of these capabilities are intended for service providers
that need to link their VOIP gateways and terminate one another's
calls.
Add It Up
But getting the goods on the gateways is just part of the VOIP
drill. Corporate networkers also need to know just how the products
will run when they're put on the net. What's the best way of
predicting performance? Go back to those latency measurements and add
up the figures to arrive at a best-case scenario.
Start by assuming a round-trip delay of 200 ms (32 ms at each
gateway, multiplied by two f
or travel time, plus the amount of delay
created when vendors pack two frames into an IP packet). Then figure
in the encoding, decoding, and compression latencies, which add
another 200 ms. Finally, count on a jitter buffer of at least 50 ms.
That all adds up to a total round-trip delay of 450 ms—or just
slightly better than a satellite phone link. Most callers notice delay
at 250 ms.
And remember, that's a best-case scenario—one that Shaw
characterizes as "incredibly optimistic." Most corporate networks, he
says, exhibit delays of 300 to 400 ms in the U.S.—before taking
into account gateway latencies—and higher on international calls.
He figures net managers shouldn't expect to see total delays of much
less than 600 ms. How bad is that? Joseph Daniel, regional sales
manager for RADvision, calls it "totally unusable. At that level, you
tell a joke and the guy is laughing after you've left the room."
Maybe so, although in the end it may be more a matter of what users
will to
lerate. Kanematsu's Internet connection has latencies of around
700 ms, according to the engineers at Lucent who installed it. And
Emmett has few complaints about it.
But if the best that net managers can expect is a noticeable delay,
will VOIP ever be a viable option for corporate customers? Not so
surprisingly, gateway vendors say yes—and they're doing their
best to make sure that it happens by reducing latency in their
products. Their work primarily involves the development of faster
encoding schemes (which remain proprietary for now). Lucent's SX7300
algorithm, for example, uses a 15-ms frame size instead of the 30-ms
frame stipulated by G.723.1.
Also, the speed of the DSPs (digital signal processors) most
vendors use in their boxes doubles every 18 months. That points to the
development of faster encoding schemes over the long haul.
Perhaps posing a bigger challenge are those delays imposed by the
network. That has vendors looking to deploy some sort of
prioritization scheme
to speed voice through routers ahead of data.
Trouble is, RSVP (resource reservation protocol) is the only standard
way of doing this at the moment—and Cisco is one of the only
vendors whose routers implement it. What's more, RSVP boasts only two
priority levels—high and low—while such protocols as ATM
reserve bandwidth at many levels. Finally, RSVP only makes the
reservation; it doesn't guarantee the path once packets get out onto
the network.
Still, gateway cards that slot into routers and RACs have direct
access to the router queue—allowing them to move outgoing voice
packets to the front of the line. Unfortunately, there's still no way
to guarantee them a reserved path through the backbone network (see
"RSVP: A Priority Problem," May 21, 1997;
http://www.data.com/roundups/rsvp.html).
A Thorough Physical
All right, now that net managers have come this far, how do they
actually know their networks will be able to deliver acceptable voice
quality? They don't
—and that's why they need to test performance
before they install VOIP gear. "You cannot take gateways out of a box,
plug them in, and expect them to work," warns Gordon Vanderbrug, vice
president of VIP Calling Inc. (Burlington, Mass.), an IP service
provider.
|
INTERACTIVE QUESTIONNAIRE
Work it Out
|
Aside from obvious pitfalls like insufficient capacity and
unacceptable latency, net managers also should be on the lookout for
dropped packets: Too many, and speech breaks up. Data Comm has
compiled a two-part worksheet to help identify the types of networks
that already are jammed with other traffic or are simply too slow (see
"
Work It Out"
).
As far as the actual test is concerned, users and vendors have the
same basic advice. "I w
ould encourage people to start out small," says
Lucent's Meier. Before running tests on the full network, pick two
sites to experiment on. Begin by checking the capacity between those
two sites. Voice eats up a lot of bandwidth, especially if a large
number of calls are made simultaneously. Then use monitoring software
to measure the data traffic traveling over the link—and make sure
to investigate peak loads.
Next, calculate the true spare capacity by subtracting the peak
load from the overall line speed. And be sure to take measurements on
the busiest router hop in the circuit, since congestion on one link
will slow things down on all the others. (Measuring peak loads on the
busiest link ensures all figures are worst-case scenarios—just
the information needed to know how the network will react when
critical calls are made during busy periods.)
After that, calculate the number of voice calls likely to travel
over that link at any one time. Unfortunately, there's no easy way to
get a
n exact read on needs. The best bet? Scrutinize old phone bills
and identify the calls to the other corporate site. Use a 60-minute
sample from the busiest part of the day. Next, repeat the procedure
for the other end (remember, the phone bill lists only those calls
initiated from one site). Then take several more 60-minute samples
from different days and times, just in case there's been a spike in
calls outside normal peak hours (imagine magazine editors on deadline
trying desperately to get in touch with their global correspondents).
Take the period in which the highest number of calls was made to get a
general sense of what the needs will be—then add a few more lines
just to be on the safe side.
The next test concerns latency. Here, measure the end-to-end
round-trip delay between the two sites before voice calls are added.
It's a fairly straightforward task: Configure a net management
platform, or write a simple routine to ping the line. "Spray out 10
pings every 15 seconds and see how long th
ey take to come back,"
suggests Lucent's Alcott. And it's important to take a full complement
of measurements so as to cover various times of the day. What kind of
round-trip delay is acceptable? "If you get less than 200 ms, you're
probably in pretty good shape," says Eric Larson, senior marketing
manager at Motorola.
Finally, peg packet loss. This is straightforward too: Just record
how many of those pings go AWOL. If even 10 percent to 25 percent are
dropped, watch out. "That level of packet loss does terrible things to
real-time audio," says Carl Steen, senior product manager for 3Com's
Hyper Access System gateway. He says packet loss should be under 10
percent.
Plan of Attack
|
MORE INFO
VOIP: The Patch Plan
|
Managers of networks that don't ma
ke the grade (and there will be
plenty of them) don't have to give up. There are ways to get the net
in shape. And the best advice comes from the early adopters.
Vanderbrug, who uses gateways from Vienna Systems for his voice IP
service, says the best way to start is to reduce the number of hops.
Network delays tend to form in router queues, so a maximum of three or
four hops would be ideal for top quality, according to Ido Ganor,
director of product management at Vocaltec. However, Ganor also
stresses that as many as eight could be acceptable.
Cutting the hops is fine for those in control of their own
networks, but what about net managers planning to use the Internet?
Follow the same basic principle, Vanderbrug recommends, and choose the
provider with the fewest hops. "We went to all the major backbone
providers on the Internet and said show me your route, show me your
capacity, show me your policy on congestion," he notes.
But not everyone thinks it's so easy. "If you take phone ca
lls out
through the 'Net, Lord only knows where they go," says Ron Reaman,
network communications manager at Copeland Corp. (Sidney, Ohio), a
manufacturer of air conditioning and refrigeration components. On
international links, he notes, finding out the exact number of hops is
next to impossible. That, he says, is why he's using frame relay to
carry calls to his Thailand subsidiary.
Again, companies with their own backbones have more options. They
could, for instance, push down the peak load by cutting back on bursty
traffic like router table broadcasts, acknowledgments, and chatty
protocols. "When your peak-time load reaches 65 percent you know it
includes broadcasts," Ganor says. And reducing peak loads also reduces
dependence on jitter buffers—which, remember, are prime
contributors to delay.
Another possible patch: Rejigger network utilization. If the work
day is prime time for voice calls, then delay those batch file
transfers until the graveyard shift. And net managers should keep
in
mind that time-zone differences could work to their advantage. "The
time difference with Japan is 14 hours," explains Kanematsu's Emmett.
"Most of our calls are made very late in the evening." That allows him
to send calls via the 'Net instead of private lines, since he doesn't
have to contend with the U.S. afternoon rush.
And if none of those workarounds do the trick? Resort to the old
standby: Add bandwidth. But this may not work with all networks. "The
wrong type of data traffic has the ability to absolutely destroy
voice," warns Motorola's Larson, who suggests that net managers look
at how their routers deal with large file transfers. "Someone could
open up an FTP, and nothing's going to get through the router until
that transfer is complete," he says. To avoid such sudden blockages,
router vendors furnish mechanisms for prioritizing traffic, but again,
this requires configuration.
There's one final thing net managers have to figure into the VOIP
equation: Price. And although gateways
make for a considerable upfront
outlay, the payback comes later in the form of lower phone bills.
Product prices scale all the way from $300 per port (defined as a DSP
handling one simultaneous voice call) to as much as $2,521 per port.
Actual rates depend on the number of voice calls deployed; per-port
prices listed are typically based on buying a single 24-port T1 card,
and always include the server or chassis into which it slots.
Net managers also should note that gatekeepers often cost an extra
$3,000 to $5,000, depending on the vendor. Franklin Telecommunications
Corp. (Westlake Village, Calif.) offers its gatekeeper without
charge.
|
CONTACT AUTHOR
acray@data.com
|
As for the differences in pricing, the more expensive gateways
often include functions that service providers
(especially
long-distance calling-card companies) might require. The Webphone
Gateway Exchange from Netspeak, for example, features its own IVR
(interactive voice response) unit, which answers dial-in calls with a
recorded voice and lets users input a calling-card number and PIN.
Once authenticated, users can make long-distance calls from the
gateway.
Andrew Cray is WAN equipment editor for Data Comm. He can be reached via e-mail at
acray@data.com
.
|
|
|
 |
|
|
