If
you're going to support voice over IP on your LAN,
you need to know your VoIP basics. This isn't easy -
confusion abounds when it comes to VoIP. Let's start
with the obvious but often misunderstood: VoIP
telephony is not the same as digital voice traffic,
nor is it restricted to either local networks or
wide-area networks like the Internet.
What
exactly is VoIP? It is a type of digital voice
traffic running over TCP/IP. You can do it over
private local networks, public wide-area networks
(the Internet), or even private wide-area networks.
And it's not the only (digital) game in town - there
are plenty of other types of digital voice traffic
using other architectures. While telcos have been
handling digital traffic for years, it wasn't until
quite recently that they started running voice over
IP.
The
promises of VoIP are legion, but the reality is
often somewhat more mundane. For carriers, VoIP
offers the possibility of increased efficiency, new
feature possibilities, and integrated voice, video,
and data. For businesses and consumers, it offers
the possibility of new carrier choices.
IP and
TCP Basics
The
reason for VoIP's growing popularity is simple: it
rides on top of IP networks, which comprise both the
backbone and the back alleys of the Internet. IP
networks have successfully elbowed their way into
corporate LANs, and most IT pros know how to work
with and support IP applications.
The
protocol combination generally used for VoIP is
H.323, an ITU-T standard for multimedia
videoconferencing on packet-switched networks. H.323
is a stack in its own right (a combination of other
protocols) that governs terminals, gatekeepers,
gateways, and MCUs involved in a transmission. H.323
should not be confused with its close cousins: H.324
is for point-to-point videoconferencing over POTS
lines, and H.320 is for ISDN.
Meeting
WAN Expectations
The
major challenge for VoIP is latency. In addition to
network traffic, VoIP's privacy requirements put an
extra burden on quality of service.
Because IP networks are packet-switched (not
circuit-switched like conventional voice networks),
the individual packets constituting a voice "signal"
can travel separate paths to a destination and can
arrive for reassembly out of order. The efficiency
and reliability gains of such networking were the
goals of packet-switching in the first place, but
they don't help out much when it comes to the
quality of a VoIP conversation.
Variable routes and out-of-sequence packets might
cut it for email and Web browsing. They even cut it
for IP broadcast audio and video (thanks to
buffers). But they just don't work for real-time
full duplex voice - at least, not without some help.
In an ordinary phone conversation, there's no time
to wait for the retransmission of lost packets. The
conversation must go on. Lost packets remain lost,
and the conversation gets choppy as a result. Ten
years ago, people might have put up with it for
first-world international telephony. But today, we
have grown accustomed to high QoS (quality of
service) at low cost. Blame it on those old "pin
drop" commercials.
Ironically, in the WAN arena, it is because we're
used to the crystal-clear quality of digital calls
across dedicated circuits that VoIP doesn't yet meet
our expectations. Imagine if we were still calling
long distance over amplified, noise-filtered
high-latency analog circuits when VoIP came along.
We would have probably rushed to even the earliest
incarnations of VoIP.
However, long-distance VoIP has found a niche for
itself in third-world markets, where telephone
services are expensive and, in many cases, difficult
to procure. In North America and Western Europe,
telephony is so affordable and widely available that
VoIP is hard-stretched to provide a price cut.
In
markets where the price of telephony is high, a VoIP
connection can be dramatically lower than
traditional options. Most people erroneously think
long-distance VoIP must run over the public
Internet, but a number of long distance carriers are
already providing service over privately managed
VoIP networks.
The Problem with Connectionless IP Networks
The
big problem with IP networks, and the Internet in
particular, is lost packets and the resultant
latency in the "voice signal" received at the other
end. In a low-traffic environment, unassisted VoIP
might work fine. However, once traffic heats up,
voice conversations suffer while other applications
do not.
Most
applications are not as delay-sensitive as VoIP.
Unlike other traffic types, a little delay equals a
major annoyance in VoIP.
So,
we prioritize. Voice can be treated as data, but it
is a special type of data. As George Orwell might
have written, all data is equal, but voice data is
more equal than others. Not only must it stream
(which means it must minimize lost packets) but it
must stream in two directions simultaneously.
Like
TCP/IP, the H.323 protocol is actually a stack of
other protocols. Originally accepted in 1996, it was
geared towards LANs and it was understood at the
time that H.323 would not provide a guaranteed QoS.
Lots of experimentation on different platforms (LAN,
private WAN, public Internet) and in different
applications (PC-to-PC, PC-to-phone, phone-to-PC)
led to the adoption of version 2 in 1998.
The
transport protocol used in H.323, RTP (Real Time
Protocol), gives priority to delay-sensitive traffic
like voice and video. This was a step in the right
direction. However, while RTP attempts to control
different traffic streams, it cannot actually
guarantee on-time packet delivery.
For
private bandwidth-managed networks, this need not be
a barrier. However, it is surely a problem in
unpredictable, congested network environments -
namely, the public Internet.
That's where RSVP, or Resource Reservation Protocol,
is supposed to come in. It essentially lets you
reserve a user-to-user slice of bandwidth. For the
duration of a voice conversation, RSVP creates a
virtual circuit. The ability of H.323 v.2 client and
network devices to support RSVP, or other protocols
and techniques for managing QoS, is crucial for
widespread adoption and for tweaking the utmost
efficiency out of a network while still retaining
quality.
The LANs First
A
crucial component of any VoIP system running over a
LAN is a gateway to the PSTN. A VoIP PBX can be
installed with a gateway directly linking it to the
PSTN so that any outgoing calls made on the PBX are
immediately routed to the PSTN. Or a VoIP PBX can be
connected to an IP telephony backbone. It, in turn,
could connect to the PSTN to carry a long distance
call. Or, it could carry the call itself if it can
terminate at or near the destination local exchange.
Despite the difficulties, products are already
available that let you expand a VoIP-based PBX to
create voice VPN over the public Internet.
Hardware or Software
Options abound when it comes to VoIP products. The
first VoIP products were all software, but they've
grown up a bit since then. Though run-of-the-mill PC
platform options are out there, robust business
products are built on NT, Unix, or Solaris
platforms.
There's also an increasing number of embedded
offerings. This is one area where DSPs (digital
signal processors) are expected to play a big role.
Built from the ground up to handle analog
information, DSPs will likely replace programmable
hardware in VoIP client devices. On the back end,
we're seeing more and more embedded products both
for carriers and for individual office
installations.
The Future
Eventually, carriers will implement VoIP all the way
to the local loop, even in residential areas. Why?
Because broadband Internet connections will finally
do an end-run around local telephony loops. Demand
for inexpensive broadband technologies and increases
in public and private Internet backbone bandwidth
will further fuel VoIP adoption.
The
timeline for all this? It depends on what kind of
infrastructure you've already got in place. If what
you currently have works, and it's cheap, then
there's less incentive to build. "For the next ten
years," says Pierce, "we will be living in a hybrid
world." For the time being, packetized and
circuit-switched voice will likely coexist in the
marketplace and even on LANs, for better or for
worse.
◄GO
BACK
