Reality Check On VoIP
BY DAVID BREGMAN
When we talk about voice over IP, we must realize that it means different things to different people. For some it means VoIP phones at every desktop with universal follow-me numbers; for others it is integration with the existing PBX (IP-PBXs) to provide a mixed environment. With so many definitions and ways to deploy VoIP, it is no wonder that we are all confused.
The goal of VoIP has been to enable the enterprise to create one
heterogeneous IP network to handle all voice and data traffic, alleviating
the need for separate discreet networks. While voice over frame relay (VoFR)
or voice over ATM (VoATM) in the enterprise have gained acceptance, these
implementations still require discrete networks to handle the voice traffic.
A few years ago, VoIP was the answer to all our problems. Falling IP
access charges, high PSTN circuit costs and the promise of advanced features
made for a rosy outlook. Many of us would have predicted that by now we
would see every call center using VoIP with advanced voice-enabled Web
pages. We imagined road warriors using voice over IP enabled browsers to
place calls virtually for free from any location. Thanks to VoIP we would
all have a single follow-me number with unified messaging, including
converged voice, fax, and e-mail accessible from the Web or a phone. Our
telco budgets would be halved and there would only be one converged IP voice
and data network to manage.
Back To Reality
This is not what happened. As IP costs fell, so did toll-quality calling
costs. It is fair to say that as of today VoIP has not taken off as
expected. While some of the aforementioned features are available as
services from a few providers, VoIP implementation is expensive and largely
unreliable. Established carriers are largely relying on the tried and true
PSTN network. It is only the emerging carriers that are investing heavily in
VoIP. These ï¿½VoIP pioneersï¿½ donï¿½t have a large investment in legacy
network equipment and have over-provisioned their backbone so much in the
last few years that they have excess bandwidth on which to carry voice over
For the enterprise, it is often cost-prohibitive to deploy voice over IP.
Most enterprises have a huge investment in their current PBX technology. Add
to this the major budget reductions for network IT infrastructure and we
begin to see some of the stumbling blocks for enterprise implementation of
VoIP. There are many additional issues to contend with.
There is still no clear winner in the standards war. H.323 has gained
early acceptance but SIP (Session Initiated Protocol) is right on its heels.
MGCP has been slow to gain ground and many see it as too vendor-specific.
There is a great variety in the way different vendors implement each
standard as well. Recent independent tests of SIP implementations have shown
that most vendors could achieve basic interoperability, albeit with some
tweaking of the code. When it came to advanced functionality they did not
fare as well.
There are basic security questions to be raised about sending voice
traffic over a public network. Additionally there are firewall issues to
contend with (although SIP has gone a long way to make the firewall issue
One of the major promises of VoIP is its ability to offer advanced
features. As mentioned above, the industry is not quite there when it comes
to interoperability between vendors. Even in single vendor implementations,
there is the major issue of 911 service. In most municipalities, buildings
over a specific size must be able to transmit the physical location of the
caller to the 911 system allowing emergency personnel to locate the caller.
In a traditional PBX environment, this problem is solved by matching the
directory number to a physical wire connected to a port that can be located
in the building. With voice over IP this does not exist and therefore it can
be difficult, if not impossible to locate the VoIP call point of origin.
Vendors are working on this, but no clear standard or solution has evolved.
Quality Of Service
QoS is as misunderstood as VoIP, but is an essential component to any
successful voice over IP implementation. Without some sort of QoS mechanism
VoIP can be rendered useless. QoS in a voice environment relates to delay,
packet loss and jitter. Combined, these factors make a VoIP implementation
Link overutilization is the major QoS culprit. If the link used to carry
VoIP is overutilized then voice traffic will suffer. This is the same for
any application traversing the link but voice, by its nature, is
particularly susceptible to link utilization issues. An overutilized link
will often cause delay, packet loss and jitter.
Delay: There is inherent delay in any network due to the speed of
light. The longer the run, the greater the delay. A general rule of thumb is
that for every 1,000 miles, 10 ms of delay is added to just transport the
data. This may not sound like much, but keep in mind that the generally
acceptable maximum total delay for VoIP is 100ms. If you are calling from
New York to London (3,500 miles apart) you are adding almost 35ms just due
to physical distance (this assumes that the packets will take the most
direct route, which rarely happens.) Further delay is introduced in the
processing of the voice packets (encoding and decoding), routing of the
packets and due to congestion on the line. A link that is congested will add
significant delay over one that is not congested. This delay increases
dramatically with increased congestion. For example a 64 byte packet on a
128 Kbps link with 40 percent utilization might experience a 7ms delay. When
the utilization is increased to 80 percent that delay increases to 20ms.
Therefore it is important to make sure that the link containing your VoIP
traffic is not overutilized. There are steps that can be taken to identify
voice traffic so it will be treated favorably in the backbone; these include
DiffServ tagging, MPLS tagging, and manipulation of the TOS bit.
Packet Loss: Packet loss typically occurs due to congestion on the
link. Packet loss greater than five to ten percent can make VoIP unusable.
Some packet loss is inevitable in any packet-based network. The goal is to
reduce this loss as much as possible. There are techniques in use to reduce
the sensitivity to packet loss through the use of smaller packet sizes and
interpolation. Another effective method for reducing packet loss is to
ensure that voice packets get priority over other packets traversing the
network link, thus ensuring that they are not dropped.
Jitter: Jitter is the amount of variation in packet delay from one
packet to the next. Jitter makes voice quality choppy and difficult to
understand. Most VoIP gateways contain a jitter buffer to introduce a slight
delay into each packet to better control overall jitter, but this oftentimes
makes the conversation sound unnatural by introducing an artificial delay.
Again, by reducing the congestion on the link, delay is reduced and
therefore jitter is reduced.
Looking at all of the above arguments, you might ask, ï¿½Why even
bother?ï¿½ There are many good reasons to consider voice over IP for the
enterprise. Among them: The fact that VoIP helps companies begin to
integrate corporate data applications with voice applications; it can bring
significant savings on international calls; and VoIP allows enterprises to
take advantage of under utilized infrastructure. Many enterprises can
benefit from taking advantage of their current infrastructure by deploying
VoIP on an ad hoc basis via IP-PBXs. In this way they can take advantage of
underutilized bandwidth to make some calls. VoIP is used to augment the
existing PSTN, allowing the enterprise to save money without great risk.
In these ad hoc VoIP implementations, voice is traveling on the same
network as critical business applications (ERP, CRM, etc.) along with less
critical applications (Web surfing, e-mail, real audio, etc). In these
converged voice and data networks, QoS becomes even more critical so a
balance can be struck between the voice and data traffic. Many times you
want to be able to guarantee bandwidth for voice, while leaving enough free
bandwidth to ensure performance for critical applications. In these
situations you may need to actually limit the number of simultaneous
conversations, while being able to guarantee enough bandwidth for each
In the example, we have a 128k WAN link to handle voice, Oracle,
Peoplesoft, and all other data traffic. A balance is needed between voice
and the other traffic. We need to create guarantees for the critical data
(voice, Oracle, and Peoplesoft) and limits for the non-critical traffic.
Furthermore, we need to guarantee each voice conversation to ensure that we
do not have too many simultaneous calls creating poor quality for each call.
This can be accomplished by creating an application committed information
rate (A-CIR) for voice, Oracle, and Peoplesoft. An A-CIR is similar to a CIR
found with frame relay circuits except that it relates to a specific
application. In this case, we need to be even more granular and create an
A-CIR for each voice conversation. In this way we can not only guarantee 64k
in bandwidth for voice, but we can also make sure that each conversation, or
call, gets a guarantee of 16k; ensuring minimal delay, jitter, and packet
With proper QoS mechanisms and careful planning, voice over IP can be
rolled out today to supplement existing PSTN PBXs. To a large extent this
creates the best of both worlds: One can take advantage of reduced
international toll rates, cutting monthly recurring costs; leverage existing
infrastructure, and get a return on the investment that was made over the
past few years; and gain valuable VoIP experience for future deployments.
This is achieved while retaining the reliability of existing PSTN PBXs. c
David Bregman is a senior technologist with NetReality,
a premier provider of network application priority switches (NAPS).
NetRealityï¿½s technology enables organizations to prioritize
mission-critical voice and data traffic on their wide area networks. He is
looking forward to when his eight phone numbers will be reduced to one
To The January 2002 Table Of Contents ]