Allworx VoIP Tutorial Service Manual
J
Allworx VoIP White Paper
une 2005
Author: Jeffrey Szczepanski, Chief Technical Officer, InSciTek Microsystems, Inc.
Division of InSciTek
Microsystems, Inc.
635 Crosskeys Office Park
Fairport, NY 14450
www.allworx.com
info@allworx.com
1.866.Allworx
585.421.3850 -
585.421.3853 - Fax
Copyright © 2005 All Rights Reserved - InSciTek Microsystems Inc. No part of this document may be
used or reproduced in any manner whatsoever without written permission, including quotations
embodied in critical articles and reviews.
Allworx
Main
Allworx VoIP White Paper
Table of Contents
Introduction
What Does VoIP Really Mean Anyway?
Allworx VoIP Features
SIP Protocol and VoIP
Echo in VoIP Networks
Bandwidth Calculations
SIP Protocol and NAT Firewalls
Allworx Solves SIP NAT Problem
QoS on the LAN
QoS Across a WAN
Key System Feature – Allworx BLF Protocol
Remote Office Phones
Zoning Paging
Common Problems and Tips
Glossary
6/13/05 • Page 2
Allworx VoIP White Paper
Introduction
The Allworx 10X system and family of digital VoIP phones are
designed to meet the communications and networking needs of
typical small businesses, while also simplifying the setup and
maintenance of the voice and IT infrastructure for business owners.
The primary mission of the Allworx product line is to deliver to small
businesses the most recent round of IT technologies (including VoIP)
in “turnkey” solutions that previously were only practical for large
enterprises with full-time administrative teams. While Allworx makes
IT solutions much easier to use and deploy, having a high-level grasp
of the various technologies involved goes a long way toward
understanding VoIP systems better and being able to diagnose issues
that may occur.
This paper is intended to be a tutorial on several topics as they relate
to deploying and maintaining digital phones on a VoIP network. In
particular, this document aims to arm administrators, installers, and
network planners with information to help them take advantage of
the new technologies associated with moving voice traffic over data
networks, both on a LAN and across several sites via a WAN.
6/13/05 • Page 3
Allworx VoIP White Paper
What Does VoIP Really Mean Anyway?
The term “VoIP” is officially an acronym for Voice over Internet
Protocol, but is also used to loosely refer to any application where
packet-based data networks are used to
calls in real-time. This type of telephony contrasts to traditional
hard-wired analog telephony that is
based telephony technology has several advantages, both technical
and economic, but also introduces some new complexities that must
be managed as part of the data network.
Traditionally, data networks and the Internet in general were
developed only as a “best-effort” service. The network was designed
to get the data there as fast as possible – and when there were
problems, to get as much data there as possible
good design characteristic for data, but it has problems with true
real-time constraints to support
toll-quality
packet switch
circuit switched
telephone calls. For
telephone
. Going to VoIP-
eventually
. This is a
telephone audio, not only are bandwidth and throughput important,
but packet loss, latency, and jitter performance are also critical
factors to good-sounding audio. Therefore, real-time applications
like VoIP gave rise to engineering and managing the Quality of
Service (QoS) of data networks.
Designing networks for QoS factors and diagnosing QoS problems
are entirely new dimensions in data networks for many people. In
VoIP applications, a valid data connection is required to ensure
and
application success
uncommon for data networks to have throughput or packet loss
problems that go completely unnoticed until VoIP systems are
deployed. Thus, when deploying VoIP systems, it is important to
inspect or validate the existing network to make sure it is going to be
VoIP-ready from a QoS perspective. This is an especially important
consideration when VoIP calls are going to be placed over data
connections between physical locations. QoS topics are further
a high-quality, maintainable QoS. It is not
explored later in this document, but the main items of interest are
network packet latency, jitter, and packet loss rates.
6/13/05 • Page 4
Allworx VoIP White Paper
Allworx VoIP Features
The Allworx 10x server is a sophisticated VoIP PBX and gateway
designed specifically for use by small businesses. The Allworx 10x
supports traditional analog telephony in a circuit-switched fashion
between its analog FXO loop interfaces and FXS analog extension
ports. It also acts as a VoIP gateway to bridge the digital data packetbased world and the analog world. As a result, the Allworx product
supports ordinary analog telephones, analog telephone lines, and
advanced VoIP telephones simultaneously —and
The Allworx VoIP technology platform is intended to integrate the
following key features as smoothly as possible:
•
Auto Station Discovery
into the network, and the Allworx server automatically discovers
and configures the new station without manual intervention.
•
Simplify Move/Add/Change Administration
seamlessly
: Simply plug a new Allworx VoIP station
: With Allworx VoIP
.
phones, station identity moves with the station, not with the
physical cable drop used. This means that moving phones to new
locations within the office is as simple as moving the phone to the
new location and plugging it into another network drop.
•
Remote Phone Capability with Remote Plug-and-Play
Functionality
home) and seamlessly operate it as if it was directly connected to
the LAN at the office.
Site-to-Site Toll Bypass Calling
•
Allworx system to another Allworx system at a different site,
without placing a call on the regular public phone network.
•
Integration with Internet Telephony Service Providers (ITSP):
Allworx server acts as a proxy server, placing and receiving lowcost Internet telephone calls through ITSP providers without
requiring the use of regular phone lines.
•
Third-party SIP Gateway Product Integration
: Install an Allworx VoIP phone at a remote site (e.g.,
: Seven-Digit dialing from one
: Expand Allworx
The
capabilities via LAN-connected and SIP-based FXO, FXS, and/or
T1/PRI third-party gateway products.
6/13/05 • Page 5
Allworx VoIP White Paper
SIP Protocol and VoIP
The Allworx VoIP platform is built around the industry standard VoIP
protocol known as Session Initiation Protocol (SIP). SIP is a packetbased protocol built on top of the standard IP stack using the User
Datagram Protocol (UDP/IP). Although it is possible for VoIP
telephony to use other standards (e.g., H.323 or MGCP), SIP was
specifically designed for IP stacks, and was developed with Internet
protocols in mind. While historically much of the older installed base
of packet-based telephony used MGCP or H.323, it is generally
accepted that SIP represents the future of VoIP – and nearly all new
installations using industry-standard protocols are deployed using
SIP.
When it comes to IP-based VoIP, SIP is not the whole story —it
actually describes only one of the three functional elements required.
In other words, when designing a VoIP protocol, three basic functions
must be provided:
1. Call Control and Setup/Termination – A set of mechanisms to
locate the intended dialed parties, determine their availability, and
accept or deny their requests.
2. Session Negotiation – Once a new call is going to be accepted, this
determines the format and network locations for transporting
audio between the actual end points.
3. Media Transport – Once accepted and negotiated, this provides
real-time audio transport between the end-points for the call ‘s
duration.
SIP itself actually only provides the first item described above. Other
protocols are actually required to perform the other two primary
functions. When people talk about SIP, two protocols are also
generally implied:
6/13/05 • Page 6
Allworx VoIP White Paper
• Session Description Protocol (SDP) to negotiate the session media
types (G.711 or G.729) and the IP address and port number that
each end-point should transmit toward.
• Real-Time Transport Protocol (RTP) to actually move coded audio
data during the live call.
Therefore, when people talk about SIP VoIP telephony, several things
are implied to be available and working properly for successful
phone calls:
• Reliable IP routing data connectivity of UDP packets between
associated phones and their gateways or proxy servers for basic
network transactions (network settings, DHCP, DNS, etc.).
• SIP protocol and proxy configuration to locate intended parties
and determine their availability (ringing or busy).
• SDP negotiation to determine the final coder type, IP addresses,
and port numbers that should communicate actual audio data.
• RTP to transport coded audio over a network with an acceptable
QoS level from end-to-end.
Acting as a VoIP gateway, the Allworx server contains all the
necessary facilities to make the above happen in as simple a manner
as possible. However, when one of these mechanisms is interfered
with on the network, certain types of symptoms may result – such as
dropped calls, choppy audio, one-way audio, or echo. Installers and
site administrators must be certain that things are configured
properly in their environments to ensure proper data connectivity
and QoS between end points.
Looking forward, the remainder of this document will be dedicated to
helping administrators and installers better understand the potential
pitfalls, so that they may troubleshoot and resolve networking or
configuration difficulties.
6/13/05 • Page 7
Allworx VoIP White Paper
Echo in VoIP Networks
From time to time, echo can be a problem during telephone calls.
Certainly everyone has experienced echo at one time or another,
even for ordinary, non-VoIP calls. Echo is most commonly
experienced in international calls or long-distance calls to rural
areas, and of course in calls on cell phones. Unfortunately, the
characteristics of VoIP telephony connections increase the
opportunity for echo problems to occur. This is due to the
introduction of additional latency (delay) of the voice as it travels
from source to destination over the packetized data network.
To the human observer, echo of his or her own voice is only
noticeable when it is heard back with some amount of delay. Echo
without delay simply sounds like side-tone. Side-tone is the sound
of your talking fed back directly between microphone and speaker
without any delay. It is normally introduced purposely on phones so
that the phone does not sound “dead” when you are talking.
Therefore, when echo exists in the analog phone network, especially
in local calls, it is completely covered up by the existing side-tone.
However, when a VoIP system is attached to that very same analog
phone line, the additional latency of the data network now carrying
the voice to/from the IP phone now makes that echo noticeable to
the user – since the echo now arrives back well after the speaker has
finished each sentence.
Echo round-trip delays of only a few milliseconds (ms) are not really
noticeable, but as the delay accumulates into the area of 10ms, the
system will start sounding hollow and eventually will start sounding
like the reverb of a large stadium echo. As echo latencies run into the
area of 50ms and beyond, the speaker’s own speech will be followed
by a very distinct echo of the same words back in his or her ear. At
this point, unless the echo is very quiet, it starts to become
annoying.
6/13/05 • Page 8
Allworx VoIP White Paper
Generally speaking, the loudness and the latency impact how
objectionable the echo sounds to the talker. As the echo gets quieter
and/or less delayed, it becomes less objectionable. Alternatively, we
can say that the more delayed the echo is, the quieter it needs to be
in order to be acceptable. For echo to be acceptable in a VoIP system,
it typically needs to be quieter than it was to start with in the analogonly part of the network. This is the role of the
echo canceller
in a
VoIP system, which we will cover later.
Where does the echo come from?
Echo results in the phone network when two-wire phone lines
carrying voice in both directions on the same wire pair are converted
into four-wire circuits (where a separate wire pair carries the audio in
each direction). The analog device that does these conversions is
called a
two-wire analog loop world and the four-wire Central Office (CO)
switch world. If
phone and phone lines installed at every site, there would be no
echo. However, in the real world, hybrids are not installed with
perfect impedance matches, and therefore echo results when sounds
“bounce off” the hybrids.
In a typical analog phone call, there will be at least two hybrids
hybrid
– and its job is to convert back and forth between the
hybrids
were perfectly matched to the particular
involved: one at the CO for the calling party (near-end echo) and one
at the CO for the called party (far-end echo). Beyond the hybrid
electrical
common is
echo, there can be other sources of echo. The most
acoustical
echo at the far end – when you call someone
who has a low-quality phone or is using a desktop-type
speakerphone. The near-end echo is determined by the local phone
line loop on which you are making the call, while the far-end echo
depends on the party being called. For this reason, near-end echo is
generally referred to as “line echo” and the other sources of echo are
collectively referred to as “network echo”.
Delay times for “line echo” are not a concern for ordinary analog
phone calls because the delay path is short enough that the echo
6/13/05 • Page 9
Allworx VoIP White Paper
sounds like side-tone. This means that the phone company can
ignore the effects of line echo. However, the delays inherent in
“network echo”
are
typically problematic, even for regular phone
networks, especially with calls that cover long distances. The phone
companies have to do something about this – so they have devices
built into long-distance phone networks called Network Echo
Cancellers (NEC) to remove this echo. Now it is generally safe to
assume that “network echo” is not a particular concern for longdistance calls, even with VoIP systems attached to the PSTN.
The need for Line Echo Cancellers in VoIP
As we stated above, the PSTN is not concerned with line echo, since it
will sound like side-tone. However, if we attach a LAN VoIP system to
a PSTN gateway device (like Allworx), line echo becomes a specific
concern in the system – because the hybrid echo coming back from
the line is now delayed by tens of milliseconds in the IP network and
will no longer be acceptable to the VoIP phone station user. VoIP
gateway systems employ a device in their line interfaces called a Line
Echo Canceller (LEC) that can cancel up to approximately 16 or 32ms
of echo resulting from the hybrid installed on the CO’s local phone
line.
If VoIP systems have an LEC and the PSTN has NECs, why do we still
hear echo at times?
This is a complicated question with several different answers:
• An echo canceller is a very sophisticated device that automatically
attempts to dynamically detect, adapt to, and remove all echo “on
the fly,” while still providing true full-duplex speech performance.
Neither LECs nor NECs are perfect devices – and depending on the
design trade-offs of a given implementation, they will exhibit
certain strengths and weaknesses in some operating
environments.
• The phone company NECs never perfectly converge down to zero
residual echo. When a VoIP system is introduced at one end of the
6/13/05 • Page 10
Allworx VoIP White Paper
connection, the increased delay may make the existing residual
echo more perceptible. As described previously, this added delay
gives the
perception
that the echo is worse, even though the
magnitude of the echo signal is actually the same. In a given call,
depending on the exact level of residual echo, this may or may
not end up being objectionable to the VoIP system user.
• Regional “intra-LATA” calls can be very problematic relative to
network echo. Because latency in the network is not significant,
the phone company doesn’t usually bother to deploy the relatively
expensive NECs for intra-LATA calls. The delay is relatively short,
so the echo is not usually objectionable when using an ordinary
analog phone at each end. However, add a VoIP system to one end
and the network echo can be a real problem. This most often
occurs when placing short-haul calls between competitive local or
regional companies, and the called party has a particularly high
level of far-end echo coming back. The inherent latency of the
echo falls into the hole between the LECs ability to combat the
echo and the lack of an NEC in the phone network. To be clear,
that echo was
always
there – it just took the VoIP system to
actually hear it.
Shouldn’t a VoIP gateway then have both an LEC and an NEC?
Deploying both LECs and NECs in VoIP gateways or PBXes has some
advantages. In particular, it can help with regional calling area calls
(intra-LATA calls), which are typically the most problematic for VoIP.
However, intra-LATA calls are a small percentage of most users’
calls, and having the NEC operating for other types of calls – the ones
that already sounded good - presents some problems. The
fundamental concern is having two different NECs operating on the
same call: the NEC in the VoIP gateway and the one on the phone
network. It can be difficult to get them to work reliably together, and
in many cases it does more harm than good. You run into a situation
where maybe five or 10 percent of calls are improved quite a bit, but
6/13/05 • Page 11
Allworx VoIP White Paper
the remaining 90 percent actually get a little worse. Which is a better
trade-off?
In the end, most VoIP systems installed as end-user customer
premise equipment, (including Allworx) employ only LECs, not NECs.
The reasons are both technical and economic. NECs require
significantly more processing power than LECs and are historically
very expensive to implement on several channels at a time. Market
forces have shown that the added costs are not outweighed by the
functional benefits.
Conclusions
Other than new skills for both installers and administrators relative
to data network Quality of Service (QoS) that are discussed in the
next sections, echo is the biggest hurdle for VoIP systems to
overcome, as they improve with each generation. Echo cancellers go
a long way toward maximizing the user’s perceived audio quality, but
still represent one of the areas for the relatively new VoIP
technologies to improve. Looking forward, the quality and
capabilities of echo cancellers will continue to improve, but the only
thing that will completely eliminate echo sources is when VoIP
systems no longer need to interact with analog phone loops that date
back to the designs of Alexander Graham Bell. Once calls between all
end points are completely digital, the problem of occasional or
persistent echo will be a thing of the past.
6/13/05 • Page 12
Loading...