executive guide

EXECUTIVE GUIDE
Voice
over IP
VoIP is fast becoming a strategic business application
Compliments of
EXECUTIVE GUIDE
Table of Contents
Introduction.............................................................................................................................................................................................. 3
VoIP goes mainstream
VoIP trends
VoIP rollouts are becoming mainstream........................................................................................................................................ 4
Voice over IP
IP softphones slowly gain speed. ..................................................................................................................................................... 8
Watch out for Wi-Fi phones...............................................................................................................................................................10
IP telephony deployments struggle with power/heat issues . .............................................................................................. 11
Fixed-mobile convergence improves the economics of IP voice..........................................................................................13
Case studies
Speaking the language of convergence........................................................................................................................................14
UC Berkeley upgrades voice............................................................................................................................................................16
VoIP-based testing
VoIP testing team ventures into new terrain. ............................................................................................................................18
Session border controllers guide VoIP streams....................................................................................................................... 20
VoIP security
How to protect your VoIP network. ............................................................................................................................................... 26
Phishing leverages VoIP in new scam model. ........................................................................................................................... 30
Secure SIP protects VoIP traffic. ...................................................................................................................................................31
Researchers seek to save VoIP from security threats. ......................................................................................................... 32
Executive Guide EXECUTIVE GUIDE
Back to TOC
Introduction
VoIP goes mainstream
V
oIP is moving past the pilot stage, busting out of the contact center and expanding
beyond the branch office. It’s becoming a mainstream enterprise application.
Sales of IP PBXs surpassed TDM PBXs
for the first time last year, and by 2009 IP
PBXs are expected to account for 90% of the
market. The question for IT execs today is
not whether to move to VoIP, but how to do it
efficiently, securely and cost effectively - and
how to demonstrate ROI.
This Executive Guide presents benchmarks for determining VoIP rollout costs
and calculating ROI, advice from industry
experts on VoIP security threats and countermeasures, plus cutting-edge user case
studies, trends and testing.
According to Nemertes Research,
companies spent an average of 16 minutes
per employee planning their VoIP rollouts
in 2004, and that number skyrocketed to
64 minutes per user in 2005. Installation
time and the amount of time spent troubleshooting VoIP rollouts doubled, according to
the survey of more than 90 IT execs.
The conclusion of Nemertes researchers
is that today’s VoIP rollouts are part of a strategic, enterprise-wide convergence effort
that requires more planning across different
departments. For example, Nemertes found
that companies devoted an average of 12
people to convergence projects in 2004, but
that number increased to 27 in 2005.
When it comes to capital expenses, companies averaged $450,000 for their IP PBX
equipment; $580,000 for IP handsets; $50,000
for voice mail or unified messaging; $182,000
for audioconferencing and $100,000 for
management tools. But the largest expenditure was $1.4 million in network upgrades.
On the payback side, a converged
network can mean savings in staff costs
- companies in the survey averaged $80,000
in personnel savings. Investments in IP
videoconferencing have a payback period
ranging from 12 to 38 months. And payback
periods for audioconferencing are even
more impressive - ranging from 1.4 to 5
months.
Other cost savings can come from
moves, adds and changes, and consolidating
WAN links, reducing the need for cabling
and increased productivity.
Issues remain
But deploying VoIP isn’t easy. There are
a variety of security, policy and management
issues that need to be addressed.
When it comes to VoIP security, there’s
a whole host of new threats. Hackers can
attack VoIP endpoints with viruses and
worms, conduct man-in-the-middle attacks
to steal information or hijack a VoIP server,
launch denial-of-service (DoS) attacks
aimed at overwhelming VoIP gear, or disrupt
VoIP conversations through jamming or
broadcast storms.
However, there are countermeasures
you can take. VoIP is simply another type of
IP traffic, so there are tried and true security
tricks at your disposal. They include keeping
patches up to date, requiring strong authentication, installing anti-DoS tools and securely
configuring VoIP applications. In addition,
you can build an in-depth defense by segmenting your network so that VoIP servers sit
on a different physical or virtual LAN from
VoIP endpoints.
Also, consider Session Initiation Protocol (SIP)-aware firewalls, application layer
gateways, session border controllers (SBC)
to manage VoIP traffic flows, and using IPSec
or secure SIP to make sure that VoIP traffic is
protected between endpoints.
In a recent test of SBCs conduced by
Miercom, a variety of products demonstrated
that they can act as traffic cops, controlling
VoIP traffic streams at the edge of the network. However, the testing also showed that
setting up SBCs can be complex and costly.
Interop iLabs tested whether multivendor VoIP interoperability is possible, and
the results were encouraging. The testers
determined that new QoS mechanisms
introduced by the leading vendors do work
effectively.
On the other hand, there are some
tricky aspects to a VoIP deployment, especially when you get into network access
translation, which masks the identity of the
endpoint, and voice over wireless.
There are also issues that arise with
a convergence project that you may have
never even thought about. That’s what happened when Butler University migrated from
a hosted Centrex phone service to a Cisco
CallManager VoIP system.
Staffers from the voice, data and applications groups found that they didn’t even
speak the same language. For example,
when somebody mentioned MACs, the voice
people thought it meant “moves, adds and
changes,’’ the data people thought it meant
“machine access control’’ and the applications people thought it meant Apple laptops.
Then there’s something as simple as
power and heating issues. Companies are
finding that IP telephony equipment is
causing serious heat issues in wiring closets
and that Power over Ethernet switches are
creating an issue in terms of backup power.
Fortunately, there are solutions to all
of these problems. This Executive Guide
will provide guidance from the industry’s
top VoIP experts, cutting-edge research and
product testing, and those who have gone
through the rigors of a VoIP rollout.
Executive Guide EXECUTIVE GUIDE
Back to TOC
Section 1
VoIP trends
VoIP rollouts are becoming mainstream
Voice over IP
Nemertes study shows that as companies broaden their VoIP
rollouts, setup costs increase - but so do savings.
By Robin Gareiss, Network World
When IT executives make the strategic
decision to implement VoIP and other
converged applications, cost savings is one of
the key drivers.
But is VoIP really a money saver? Based on a
Nemertes Research survey of 90 IT executives,
the answer is yes - over time. In other words,
steep start-up costs will be offset in the long
run by significant savings.
One of the key findings in this year’s study
is that companies are spending more time
and money on planning, installation and
troubleshooting, compared with last year.
The reason is that VoIP increasingly is being
deployed as part of a strategic, enterprisewide
convergence project, rather than as a pilot
project or a technology deployed in a limited
setting, such as a branch office or contact
center.
Another important finding of the study is
that VoIP equipment generally costs about
the same as TDM gear, with the exception of
handsets.
It pays to plan
Since 2004, the amount of time spent
planning a VoIP rollout has quadrupled. This
is where participants spend most of their
overall operational start-up time. They have
learned from peers about the nightmares that
result from a poorly planned deployment.
Because VoIP is typically part of a larger
convergence effort, organizations are
spending more time upfront trying to identify
steps in the project - and preparing the
networks for them. Several early adopter IT
executives who participated in the study said
if they had spent more time planning, they
would have had a smoother rollout and spent
less time troubleshooting.
Is your network ready?
As part of planning, IT staffs should perform
or hire someone to perform baseline network
assessments, also known as network readiness
tests. Companies typically spend $3,000 per
location for small implementations (usually
five or fewer sites) or an average of $63,500
for a comprehensive, multisite evaluation.
Comprehensive evaluations range from
$12,000 to $150,000.
Management costs
When measuring management cost per
user by vendor, Nortel deployments are the
most expensive to manage, primarily because
many are hybrid, and customers still require
staffs to maintain the TDM gear.
Nortel costs $268 per user to operate in
smaller rollouts, and $87 in larger rollouts.
ShoreTel is the least expensive to operate, at
$13 per user for smaller rollouts and $10 per
user for larger rollouts.
In reviewing total overall costs for
maintaining a VoIP system, however, Cisco, at
$256,750 per year, is the most expensive for
Management costs
When measuring management cost per user by vendor, Nortel deployments are the most expensive to manage, primarily because many are hybrid,
and customers still require staffs to maintain the TDM gear.
Nortel costs $268 per user to operate in smaller rollouts, and $87 in larger
rollouts. ShoreTel is the least expensive to operate, at $13 per user for smaller
rollouts and $10 per user for larger rollouts.
In reviewing total overall costs for maintaining a VoIP system, however,
Cisco, at $256,750 per year, is the most expensive for implementations with
more than 1,000 units. and, at $124,266 per year, it’s also the most costly for
rollouts with fewer than 1,000 units.
Those four vendors garnered enough statistical response to be broken out
individually.
Executive Guide EXECUTIVE GUIDE
VoIP trends
Management tools are key
Management tools often are an unplanned
expense, but they’re key to the success of a
VoIP project. Only about 15% of organizations
actually budget
for such tools upfront,
but more than half seek specialty
tools within 12 to 18 months of their rollouts.
The amount organizations budgeting for
or buying third-party management tools are
willing to spend has increased in the past
year. This is primarily because they recognize
they need solid tools - and a new class of
tools - to manage a converged network
effectively. Based on that, the recommended
management budget has increased slightly
this year. (See “Benchmarks for VoIP
deployments.”)
Training is another often-overlooked area. IT
executives cited training as one of their key
recommendations to peers based on lessons
learned in their own projects. Value-added
resellers and vendors often will include
training as part of the deal. But several IT
executives suggest that vendors invest more
in consistent, nationwide training programs
- even if they must charge for them.
“Part of the problem is finding training,” says
the CTO of a healthcare company. “We don’t
have a $2,000-per-engineer budget, but we do
provide training piecemeal.”
In fact, the amount organizations are
spending on training has decreased since
2004. For example, small companies were
spending about $2,500 per person on training
in 2004, and they’re now spending closer to
$2,000.
Nemertes recommends internal IT staffs
train users on the new handsets and features
whenever possible. The best approach is to
schedule 20- to 30-minute sessions with small
groups of users and teach them the basics.
Rather than trying to force all users to use
all features and applications at the same time,
companies that have installed additional
features (for example, unified
messaging or real-time communications
dashboards) should solicit tech-friendly trial
users who will build consensus among their
peers. Before long, users will be asking for the
“cool new feature” that Bob in the next cube
has been using.
Cost savings
The specific areas vary in which companies
find cost savings, but companies almost
always do find some. The most important
thing to remember when creating a businesscase analysis is that each company’s savings
depends greatly on architecture, vendor or
carrier selection, application rollout plans
and staffing levels, among other factors.
Generally, organizations save money (or
increase top-line revenue) the most in a
few areas: staffing, ongoing management
and
administration, IP
audioand
videoconferencing, telecom circuits, cabling
new buildings, and employee productivity.
Staffing
When they start using VoIP, organizations
typically save on their staffing requirements,as
well as the money they spend on outsourcers
Executive Guide GIACOMO MARCHESI
implementations with more than 1,000 units.
and, at $124,266 per year, it’s also the most
costly for rollouts with fewer than 1,000 units.
Those four vendors garnered enough
statistical response to be broken out
individually.
As companies install VoIP in more branch
offices and give handsets to more users (as
opposed to simply IP-enabling a TDM PBX),
the amount of time staffs spend installing the
gear increases.
Troubleshooting time also is increasing,
but not at the same rate as planning and
installation.Troubleshooting includes the time
spent repairing problems after installation and
until the system is considered full-production.
Companies
with
higher-than-normal
troubleshooting times typically devoted
lower-than-normal time to planning. So it
makes sense that as IT staffs spend more time
upfront planning the rollout, troubleshooting
time should grow more slowly.
There are three primary reasons behind
the increases in operational start-up time
- and thus, cost. First, organizations are
taking their VoIP projects more seriously
because they are the first step of an overall
convergence effort, and consequently
need to devote more people from different
disciplines (applications, security, voice, data)
to the rollout. In 2004, companies devoted an
average of 12 people to convergence projects,
compared with 27 people by late 2005.
Second, the salaries of IT staff working on
convergence projects have increased. The
average salary with benefits was $96,766 in
2004, compared with $98,621 in 2005.
Third,companies are devoting more money to
consulting costs related to design and
implementation. The median consulting cost
is $23,125, but the range is from $500 to $2
million, according to the survey. The goal is to
take advantage of the experience of systems
integrators and resellers, maintain flexibility
with internal staffs, and improve the rate of
project success.
Back to TOC
EXECUTIVE GUIDE
VoIP trends
and consultants. However, a small
percentage (5%) said they had to
increase their staffs because of
VoIP. In those cases, they added one
to three employees, regardless of
overall staff size.
The average personnel savings
has increased from 2004, when
organizations
reassigned
or
eliminated an average 0.74 positions,
at $76,830 per year. This year the
figure, when averaged among all
organizations, is 0.76 positions, at
$81,240 per year.
Nearly one-third of the participants
said they saved on staffing costs.
When the numbers were run
for only those organizations, the
average staff savings jumped to 1.46
employees, or $192,584 in salaries
and consulting costs.
Participants said they typically
reassign people rather than walk
them to the door. In addition, some
of the personnel savings comes from
cost avoidance.
“If I had to go with TDM, I’d have
to hire more people,” says the global
telecom director of an entertainment
company with a growing, 2,500person VoIP rollout. “I’m working
with 20% to 40% less with IP.”
Management and administration:
Exactly what are these staff
members doing, and how much
time are they spending maintaining
the voice network? First, they
generally don’t distinguish between
maintenance and troubleshooting.
It’s all just managing the voice
network.
What that includes is making sure
IP PBXs, handsets and softphones
are up-to-date on the latest revisions;
troubleshooting
performance
problems or outages; moves, adds
and changes (MAC); and monitoring
overall performance.
Some - typically small and
Back to TOC
midsize
organizations
are
starting to outsource the day-today management of VoIP systems.
“We’re considering eliminating a
person and outsourcing the actual
maintenance of the system,” says
the IT director of a large law firm.
“There’s not enough to do to keep
someone with those skills on-site.”
Savings on MACs are one of the
most important ways organizations
justify their VoIP rollouts. Overall,
participants spend an average of
$124 on MACs.This number includes
MACs done internally and externally.
The cost ranges from $29 to $450:
At the low end are internal MACs
done by an efficient, experienced
and/or low-paid staff. At the high
end - generally in large cities - are
external MACs.
The number of MACs increases
with company size, not surprisingly,
and ranges from 197 to 136,020.
MAC penetration, however, isn’t
as dependent on company size
(penetration is the percentage of
MACs based on the total employee
base).
The big shift this year is that on
average, organizations make 1.28
MACs for each employee.Realistically,
at most organizations employees
don’t change offices more than once
a year. What happens is more like a
chain reaction. One person leaves
the company, and three to five MACs
result - one for the person leaving,
one for the person who wants that
office, one for the person who wants
the next-vacated office, and one for
the replacement.
In moving to VoIP, MACs become
very simple. The time involved for
a TDM MAC is 30 to 90 minutes, but
an IP MAC takes 10 minutes or less.
The total cost savings, depending
on the number of MACs at a given
organization, can therefore be
significant.
Benchmarks for VoIP deployments
There are four spending benchmarks: start-up
costs, capital expenses, training and management.
MEDIAN START-UP COSTS
Fewer.than.100.users
$143.per.user
More.than.100.users
$53.per.user
AVERAGE CAPITAL EXPENDITURES
VoIP implementations, all sizes
IP.PBX
$448,221
IP.PBX,.messaging
included
$562,024
IP.handsets
$580,799
Network.upgrades
$1,398,527
Voice.mail/UM
$54,333
Audioconferencing
$182,463
Management
$100,000
RECOMMENDED TRAINING
Deployment Number of
locations
size
Very.small Fewer.than.5
Users to train
0.to.1.
(0.=.outsourced)
Cost per
user
$2,000
Small
6.to.20
1.to.2
$2,000
Midsize
21.to.250
3.to.5
$1,800
Large
251.to.1,000
10.to.15
$1,500
15.or.more
$1,500
Enterprise 1,001.or.more
RECOMMENDED MANAGEMENT BUDGET
Number of
Budget
Deployment size locations
Very.small
Fewer.than.5 Freeware,.IP.PBX.tools,
carrier.tools.
Small
6.to.20
$25,000.to.$50,000
Midsize
21.to.250
$75,000
Large
251.to.1,000
$100,000
Enterprise
1,001.or.more $100,000+.(depends.on
the.configuration;
requires.consultation)
SOURCE:.NEMERTES RESEARCH
Executive Guide EXECUTIVE GUIDE
VoIP trends
Back to TOC
IP conferencing:
Another area of savings is video- and audioconferencing.
The payback period is six to 12 months when organizations
replace an ISDN-based audio- or videoconferencing system with
an IP system. Typically, companies pay $200 to $300 per hour
for ISDN-based videoconferencing services (and as much as
$2,000 for global calls), and 6 cents to 12 cents per minute for
audioconferencing services.
Several organizations say they’re using IP video- and
audioconferencing for internal communications, which can be
10% to 75% of their audioconferencing calls and 30% to 60% of
their videoconferencing calls, depending on the industry. They
use service providers for external calls; typically these are ISDNbased services, but they’ll use more IP-based services as the
carriers migrate to IP.
By shifting from ISDN to IP videoconferencing, organizations
can see a payback in 12 to 38 months, based on the averages
from the Nemertes study.
Payback periods are even more compelling for
audioconferencing: 1.4 to 5 months, based on averages from the
study (see “Benchmarking VoIP savings”).
Telecom circuits
By integrating access lines and consolidating unused capacity
on WAN links, organizations report they’re saving as much as 50%
on their network service costs.
Cabling
For new offices, cabling costs drop by 40% to 50%, because
there’s no need to run three to four drops per desktop. Instead,
companies can run one or two drops per desktop, eliminating
the cost of the cable and, more significantly, the labor to do the
job.
Employee productivity
Though difficult to measure, organizations are seeing improved
productivity when they roll out VoIP and associated collaborative
applications. These savings are mostly anecdotal, however.
For example, hospitals save on nurses’ salaries by deploying
wireless VoIP phones. They trim 15 to 30 minutes off each eighthour shift of a nurse, nurse technician or unit clerk in a hospital
setting. That translates to 234 to 548 hours per year, per shift, per
employee that can be devoted to other tasks. With an average
loaded hourly salary of $28, hospitals save $6,552 to $13,104 per
nurse, nurse technician or unit clerk per year.
Gareiss is executive vice president and senior founding
partner and CFO for Nemertes Research. She can be reached at
robin@nemertes.com.
Executive Guide EXECUTIVE GUIDE
VoIP trends
Back to TOC
IP softphones slowly gain speed
PC-based VoIP gains a foothold in call centers
and with mobile workers
By Phil Hochmuch, Network World
Corporate users are talking on IP softphone
clients everywhere - or nowhere, depending
on whom you talk to.
While use of PC-based VoIP software is taking
off in homes and college dorms, the use of
softphones in companies remains somewhat
mixed. They are having some success among
road warriors and telecommuters, as well as
telephone-centric workers such as call-center
agents.
Telephony software on PCs has been
around since the 1990s, but the emergence of
Skype and the wider adoption of broadband
have made the technology more accessible
and familiar than ever. Many companies also
now support pockets of softphone users or
even large divisions of traveling employees
with the technology.
“The IP softclient is a big thing for us,” says
Steve Lydston, network manager for Nissan
North America, whose company is in the
process of installing Siemens softphone
clients on more than 1,000 laptops for
its executives and mobile users. He says
deploying softphones on the laptops of
executives traveling abroad provides
measurable cost savings.
“[Users] could be ringing up hundreddollar cell phone bills by making cell phone
calls overseas,” Lydston says.“If you’re already
paying $10 to the hotel for broadband, the
calls are free over the softclient. Plus, the
quality is about as good as a cell phone’s, and
a lot of times, it’s better.”
Nissan North America also is gaining
productivity and cost savings with softphones
without having to go through an entire
corporatewide VoIP upgrade, which could
add cost and complexity, Lydston says.
Softphone clients on laptops are configured
to connect into one of several large PBXs.
The clients tunnel into the corporate LAN
with VPN links and access IP cards installed
on the PBXs.
Overall, Lydston admits, the financial
payback of softphones won’t blow away the
company’s accountants.“It’s more like found
money,” he says of the savings, which could
run into the tens of thousands of dollars
per month.“That’s a drop in the bucket for a
billion-dollar company like ours.”
What keeps softphones from becoming a
killer app in other companies seems to be
like the proverbial death from a thousand
paper cuts. Some of the many issues include
complicated PC sound configurations,
end users’ dislike of headset devices,
unfamiliarity with softphone interfaces and
the awkwardness of talking to someone over
a PC instead of a handset.
“Quite frankly [softphones] are more of
a novelty than a real value-added type of
application for us,” says Phil Go, CIO for
Barton Marlow, a Chicago construction firm.
VoIP is a mature technology at Barton
Marlow, which installed a Cisco CallManager
IP PBX and more than 200 IP phones four
years ago. Go can rattle off dozens of benefits
that IP telephony has made for his company,
but softphones are not high on the list.
There is no such thing as making a quick
call with a Cisco softphone client, he says. A
user’s laptop must first boot up, and then the
correct PC audio settings must be configured.
The VPN client must log into the network to
connect with the Cisco CallManager. Carrying
around a headset is another negative.
“End users sometimes have a hard time with
all this stuff,” Go says.“Plus, cell phones are so
cheap these days, and it’s so much easier and
faster to pick up your phone wherever you
are and make a call.”
Perhaps the brand most known for bringing
softphone technology to the mainstream is
Skype. The little European start-up, purchased
by eBay last year for $2 billion, has an
installed base of 9 million users. Recently,
the company launched a small-business VoIP
service for organizations with fewer than 10
users.
Skype is used widely at Dickinson College
in Carlisle, Pa., where IT staff has found
interesting ways to use the technology.
The college’s IT department made Skype
part of its standard PC and laptop software
image distributed to computers for staff,
faculty and students.
“We have a lot of offices abroad, with people
doing research who can use Skype even if
they don’t have phone service,” says Todd
Bryant, language program administrator for
the college’s academic technology division.
“The IT staff likes it because they can send
quick messages [via instant message] and
share files as well.”
Skype is a natural fit for the college’s
languages
department, where
Skype
conversations are set up between Dickinson
students studying French, German, Italian,
Russian or Spanish and native speakers from
those countries who are at a similar level in
studying English.
“Language students can make a [Skype
connection] from our PC lab and get
Executive Guide EXECUTIVE GUIDE
VoIP trends
bandwidth priority,” Bryant says. “And if
students want to record the conversations for
credit, we have software for that, too.”
What makes Skype so useful is its simplicity.
Back to TOC
“We started to try to do this before Skype came
around,” Bryant says. “But it’s so far ahead
of other applications, especially in getting
through unpredictable firewall or [network
address translation] configurations. If you’re
calling up a random class somewhere that
might not have good IT support, that’s where
Skype has a big advantage.”
Softphone options
Almost all PBX and IP PBX vendors offer softphone clients for their phone systems. (These include
3Com, Alcatel, Avaya, Cisco, Mitel, Nortel, Siemens, ShoreTel, Inter-Tel, Sphere, Toshiba and Zultys
Technologies, among others.) Depending on what type of phone system is (or isn’t) already installed,
users have several options.
Traditional PBXs
VoIP traffic through.
Users of traditional PBXs can connect workers with
softphone by:
No PBX (client-based only)
• Installing an IP card - such as an NIC for the PBX,
• Download clients such as Skype, Vonage, SIPhone,
supplied by the vendor - which gives the phone switch an IP
address on a LAN.
• Installing softphone clients (proprietary to the vendor) on
laptops and PCs. (Remote users will require a VPN infrastructure to access the PBXs IP internal address.)
• Reconfiguring firewall settings, if necessary, to let all VoIP
traffic through.
• In April, the Federal Trade Commission brought suit
against four Detroit men who used open relays to disguise
their e-mail identities and sent spam promoting bogus diet
aids.
IP PBXs
• No special hardware is required on IP PBXs.
• VPN software and hardware are required to access the
phone system remotely.
• Firewall settings may have to be reconfigured to let all
Net2Phone, FreeWorldDialup, SipXphone and many others.
• Most clients support PC-to-PC calls for free with compatible SIP-based clients (except Skype, which is proprietary).
• Clients can be used internally or externally, since a peer-
to-peer or an external VoIP infrastructure is used to control
calls.
• Calling real public phone numbers could require gateway
hardware or cost extra as a monthly service or minutes
plan.
• Firewall settings may have to be reconfigured for all VoIP
traffic to get through. Windows and open source options
• Windows Communicator clients can act as softphones,
running off a Live Communication Server on the back end.
• Asterisk, a free, downloadable open source IP PBX, has
a softphone client and interoperates with standard Session
Initiation Protocol-based softphones.
Executive Guide EXECUTIVE GUIDE
Back to TOC
VoIP trends
Watch out for Wi-Fi phones
Dual-mode phones could be an IT management nightmare
By Keith Shaw, Network World
Do you remember all of those employees who
brought home wireless LAN (WLAN) equipment and
then started bringing their cards and access points into
the workplace?
If you thought that was a mess, get ready for Wave 2
- the Wi-Fi cell phone.
At the recent CTIA Wireless 2006 show in Las Vegas,
Nokia and Samsung Mobile displayed mobile phones
that included a Wi-Fi radio in addition to the normal
wide-area wireless radio.
These vendors weren’t the first to do this, but these
models were the first ones geared to a consumer
audience. The earlier devices were geared to enterprise
customers who want to use Wi-Fi in an IT-controlled
environment, such as a college campus or warehouse,
as well as integrate with existing VoIP or PBX
infrastructures.
The Nokia 6136 and Samsung T709 are geared to the
Best Buy/Circuit City/mall kiosk crowd. For example, the Samsung
T709 lets calls channel from a Wi-Fi access point, through the Internet
and onto a cellular network to give users uninterrupted connections
when traveling between home and office or while on the road.
A phone that uses Wi-Fi and a cellular connection could mean
trouble for network managers. Imagine this help desk query from the
vice president of sales.“Yeah, I was making a cell phone call with my
spankin’ new cell phone, and I walked into a stairwell and the call
dropped - I just lost the $100 million deal I was working on.”
The vice president might not have realized that the call he was
making connected via the internal Wi-Fi network instead of the
regular cell network - all he knows is that the call dropped, and he
may blame you.
Just like they started asking for WLANs in the workplace, users
will start asking for better WLAN coverage for voice applications. I
The Nokia 6136 (left) and
Samsung T709 are some of the first
consumer-aimed cell-phones with
WI-FI capabilities. You’ve been warned.
discussed this issue with the head of the Wi-Fi Alliance at the CTIA
show, and he admitted that most enterprise WLANs were designed for
wireless data, not wireless voice.
He suggested that the best way for a company to find out where
its wireless coverage holes are is to add Wi-Fi-enabled phones to the
network and have people walk around the office and wait for the
calls to drop.
Last year when Network World tested the ability for WLAN systems
(enterprise switches and access points) to handle wireless VoIP traffic,
the results were dismal. We hope that when we test these systems
again later this year the numbers will improve.
At any rate, the clock is ticking for you to start improving your WLAN
network before other vendors come out with their Wi-Fi cell phones
and you’re inundated with employees pounding your WLAN with
voice traffic.
Executive Guide 10
EXECUTIVE GUIDE
VoIP trends
Back to TOC
IP telephony deployments struggle
with power/heat issues
Power-over-Ethernet switches, servers replacing
key phone systems make data center hotter.
By Phil Hochmuth, Network World
While the IP telephony market heats up,
thermometers are literally spiking in some
wiring closets and computer rooms where
VoIP and power-over-Ethernet (PoE) gear is
being installed, users say.
Equipment density and overheating are
constant issues for data center managers;
beating the heat is also becoming a topmind concern for network and telecom staff
deploying gear in wiring closets, as PoE and
VoIP equipment are set up in places that once
just housed lower-power switches, cooler hubs
and patch panel racks.
“Power in general has been our Achilles
heel in our [IP telephony] deployment,” says
John Haltom, network director at Erlanger
Health Systems, a southeast regional HMO in
Chattanooga, Tenn.
Achilles heel might overstate it, as Erlanger
has deployed over 1,500 IP phones in
production, both wired and wireless, running
off of a Nortel Communication Server 1000 IP
PBX. To support IP telephony, Haltom and his
staff installed PoE switches in wiring closets to
light up the phones, and uninterruptible power
supply (UPS) equipment to allow switches to
run during a power outage.
These redundancy and power requirements
challenged the healthcare organization’s IT
staff, which supports one 112-year-old hospital.
“Trying to retrofit areas that are already
cramped with larger PoE switches, larger
UPSes,” was the challenge, Haltom says.“By the
way, all that gear generates more BTUs, so you
have to upgrade the AC units in those closets.”
By most measures, the biggest heat-boosters
in wiring closets are the PoE switches, which
VoIP environmental fundamentals
When putting an IP PBX or Power over Ethernet (PoE) LAN switch
in a wiring closet to support IP phones on desktops, consider
power and cooling requirements for the equipment, experts say.
A sampling of environmentval/power specifications of some IP PBX/PoE LAN gear:
IP PBX gear
Vendor
Product
Heat (BTU’s
per hour)
3Com
Avaya
Cisco
Nortel
NBX 100
S8700 Media Server
MCS 7825
CS 1000
923
1,000
853
1,024
32 to 104
40 to 110
50 to 95
50 to 95
Heat (BTU’s
per hour)
Operating
temperature
938
32 to 104
534
546
575
32 to 113
32 to 104
32 to 104
Service provider
Vendor
Product
3Com
SuperStack 3 Switch
4400
Catalyst 3750 G-24PS
Summit 400-24p
Switch 460-24T-PWR
Cisco
Extreme
Nortel
Operating
temperature
Executive Guide 11
EXECUTIVE GUIDE
VoIP trends
do double duty in transporting Ethernet
traffic, and acting as AC power supplies for
all IP phones and other PoE-capable gear
plugged into the devices powered ports. For
example, Cisco’s non-PoE 24-port Catalyst
3750 LAN switch generates around 176 BTUs
of heat per hour; add the PoE option, and the
switch heats up to 534 BTUs.Add in a standard
UPS that dissipates 80-100 BTUs, and you’ve
more than tripled the heat output in just one
wiring closet in order to support IP telephony.
Similarly, Nortel’s 24-port Switch 420-T heats
up to 220 BTU; its PoE-capable Switch 460-24TPWR is more than double that.
Planning for how this gear will be cooled off
and kept safe should not be an afterthought,
experts say.
“All network devices should be placed in
Back to TOC
locations with … adequate heat dissipation,
ventilation, and air conditioning,” according
to Salvatore Collora and Ed Leonhardt,
two Cisco Certified Internetwork Experts,
writing in Planning the Cisco CallManager
Implementation, published in 2004 by
Cisco Press. “Although it is surprising, some
deployments actually store servers and
switches in broom closets and under desks.
Improper care of your equipment contributes
to environmental and security hazards
that can disable or degrade your voice
deployment.”
This could especially be true in small
businesses, where an older key telephone
system is being replaced. These devices
combined call processor, phone power supply
and switching and could be stored almost
anywhere. However, companies should have
a cool, dry place ready for newer IP PBX gear.
“In certain climates, you could have very
high humidity, with the ambient temperature
getting above [104 degrees Fahrenheit],” says
Patrick Ferriter, vice president of marketing
for Zultys, a maker of IP PBXs that targets the
small-offices as a key system replacement.
“There are places where it does get hot, and
you’re going to have problems if you don’t
have air conditioning.” How much cooling
will depend on the IP PBX itself, he adds.
“If you have an IP PBX which has built-in
gateways, and if you have a lot of analog
connections - FXS boards which provide
ring voltage - it could start to get even hotter,”
Ferriter says. “It’s going to be hotter than a
traditional key system for sure.”
Executive Guide 12
EXECUTIVE GUIDE
App-centric network management
Back to TOC
Fixed-mobile convergence improves
the economics of IP voice
VoIP convergence used to mean a bunch of
softswitches, media gateways, replacing Class
5 switches and - not accidentally - spending
telecom dollars that used to be spent on
traditional TDM on VoIP voice instead. Not
much of that ever happened. Today, carrier
planners at all levels are focusing on a
new kind of convergence - fixed-mobile
convergence (FMC). This time may be the
charm.
The idea behind FMC is to create a supervoice service that lets customers mingle calls
between fixed-line and mobile handsets. A
customer could set up rules that govern the
conditions under which a call placed to one
or the other line is completed. The easiest
example is a rule that says, “If my mobile
phone is off, ring the call on my fixed line
instead of going to voice mail.” This could
be expanded to include a test for specific
numbers, letting non-critical calls go to
voice mail. It would also be possible to do
the opposite: Ring fixed-line calls through
automatically to the mobile number if the
mobile phone is on.
There is clearly a customer value for all
of this, but the value proposition for service
providers goes beyond making customers
happy. Where the value is found varies
depending upon what kind of voice carrier is
looking at FMC.
An incumbent local exchange carrier
(LEC) could see FMC as a way to futureproof
wireline voice services against broadbandbased VoIP offerings. Most incumbent LECs
(ILEC) also have wireless subsidiaries, and a
VoIP offering based on FMC ties the popular
mobile service to the increasingly pricepressured wireline voice. Because modern
3G services are based on Session Initiation
Protocol calling, just like most VoIP services
(except Skype), FMC would allow for VoIP-
to-mobile calls without going through
a relatively expensive public switched
telephone network gateway. This improves
the economics of IP voice.
For the cable companies, an ILEC drive to
FMC creates competitive pressure to follow
suit, and they have been signing mobile
virtual network operator (MVNO) deals with
wireless carriers to create their own FMC
services. But cable companies have another
reason to like FMC, and that relates to the
dual-mode Wi-Fi/mobile handset.
A dual-mode handset is capable of using
Wi-Fi in the home (or, in theory, in other
hot spots) and standard cellular mobile
frequencies when on the road. With the right
carrier equipment behind it, such a handset
can let a user roam between Wi-Fi and cellular
while keeping a call connected. When the
user is at home (or at work, for a business
version of the service), the calls can be rung
through the VoIP and Wi-Fi connection, so
there would be no airtime charge.
By offering phone connections over home
Wi-Fi, a dual-mode handset eliminates the
need to connect the old phone wiring to a
VoIP service. This reduces installation costs
and potentially increases VoIP penetration.
The cable companies might find this a
critical edge in getting their VoIP services
rolling quickly.
For the overlay VoIP players, such as Vonage,
it might be that dual-mode handsets, FMC and
an MVNO relationship with a cellular carrier
would be the difference between profit and
being marginalized.
By adding features to their FMC offerings,
Vonage and other VoIP players might raise
their margins and attract more customers.
Basic Internet calling clearly is going to be
virtually free, so if you want to make money
you have to look beyond it. FMC certainly is
an option.
For users, FMC is likely to bring about major
changes in calling. In the future, you might not
have a mobile number and home number,
just a personal number and set of rules that
determine which calls placed to that number
are connected on each of the voice services
you have. For outside sales and support
personnel, it could mean more freedom and
flexibility; for home users, a single phone that
works everywhere.
This won’t be an overnight process, but
the pressures of the competitive market are
clearly driving us in this direction. Planning
now for FMC seems a prudent step for
carriers and users alike.
Executive Guide 13
H A L M AY F O RT H
By Thomas Nolle, Network World
EXECUTIVE GUIDE
Back to TOC
Section 2
Case studies
Speaking the language of convergence
Butler University learned to keep an ear out for confusion over the terms
and concepts used when groups collaborated on a VoIP deployment.
By Phil Hochmuth, Network World
When Butler University recently migrated
from an on-campus hosted Centrex phone
service to a Cisco CallManager VoIP system,
one of the first challenges it encountered was
to get more than a dozen staffers from the
voice, data and application groups speaking
the same language.
The Indianapolis-based institution wanted
to integrate its voice and data networks
physically,meld several back-end applications
- such as its PeopleSoft ERP system - and
update its interactive voice-response system
for self-service information-gathering.
The deployment took two years, from
planning to completion in late 2005,
and required a lengthy RFP process, an
independent consultant to provide outside
perspective and advice, and the gradual
merging of four separate staffs: data and
networking, telecom, facilities management
and applications, says Scott Kincaid, CIO for
Butler University.
The integration of the staffs was smooth,
Kincaid says. But after a few meetings with
everyone in the same room, Kincaid realized
how high the barrier of technical language
and jargon was going to be.
Say what?
“First, we started talking about MACs,”
Kincaid says. “I thought it was a PC-vs.Macintosh debate; the voice people are
talking about moves, adds and changes; and,
of course, for the data people, this was about
the Machine Access Control addresses” on
the IP phones and PCs on the network.
In addition to overlapping acronyms,
concepts that are second nature to one group
may mean something different to another. An
instance of this was the idea of an extension.
“In the middle of our project, we kept using
the word extension, and we found it was a
meaningless term,” Kincaid says. To telecom
staff, an extension was a logical endpoint that
could ring in possibly multiple places. Data
staff thought of an extension as a physical
phone, not a programmable port or portable
number that moved around. “Then you had
the PeopleSoft/ERP team members, who
thought we were talking about data fields in
a software product,” he says.
Another concept that needed to be defined
clearly as the project got underway was the
word directory, Kincaid says. To the data
group “this is all about Active Directory and
LDAP,” he says.
For the voice technicians, directories were
lists of phone extensions.To the programmers,
these were the file structure and hierarchy of
the servers and systems on which the ERP
software and applications were running. The
trickiest part about all of this, Kincaid adds,
was that eventually all these concepts would
have to come together: Cisco CallManager
runs Active Directory, which includes phone
extensions and dial-plan data, and is stored
on Microsoft Windows 2003 servers in a
directory hierarchy.
Besides separate definitions of terms,
Kincaid says he found the groups differed
in their approaches to and philosophies
about maintaining and managing a network,
because of habits and tendencies built
up over the years related to the technical
cultures of each group.
“Most voice people I work with seem to
come from a mainframe background, and
they have that kind of mentality. There’s a
centralized mind-set to it; there aren’t that
many of them, first of all,” Kincaid says.“They
like documentation. And there are only so
many things you can do on a PBX. They’re
used to a very stable environment.” Above all,
he adds, “They tend to have this belief that
end users have a God-given right to [a] dial
tone, and you have to respect that.”
As he worked with data people, he found
their approach was more distributed and
decentralized. “The data people were
comfortable and used to pulling different
pieces together. But they’re not used to having
someone come into their network without
them being in the loop.”
Using an outside consultant was key in
helping the converged IT staff at Butler
understand their communication differences
and various philosophical approaches.
“It was important for us to have an
independent consultant, not to make the
decisions or to lead the project, but to guide
us and help keep a level base line,” Kincaid
says. In meetings, the presence of an outside
voice helped encourage the members of
Executive Guide 14
EXECUTIVE GUIDE
Case studies
Back to TOC
each IT faction to clearly describe what they
were talking about in the larger context of the
project.
Above all, a group of users - university staff
and faculty - had the biggest jargon-cutting
role in the combined IT organization. They
were not afraid to raise their hand in meetings
and question what the IT staff were talking
about, Kincaid says.
“We got into all of these discussions about
QoS and data packets and security; none of that
mattered to the user. What mattered to the user
was the phone conversation. The call center
being there. Having availability to information.
Having them involved was probably the most
important step we took.”
Executive Guide 15
EXECUTIVE GUIDE
Back to TOC
Case studies
UC Berkeley upgrades voice
By Ann Bednarz, Network World
University of California, Berkeley, eked all it
could from its legacy voice mail system - and
then some.
Even after Unisys dropped support in 2001
for the university’s Digital Sound voice mail
system, it located a third-party vendor willing
to keep the system alive with components
found on eBay and salvaged from other
retired systems. “They weren’t making any
new parts or upgrading the operating
system. It was a very closed system,” says Terri
Kouba, a systems developer in UC Berkeley’s
communications and network services
department.“But it was maintained.”
The university knew the fix was temporary
and started looking for a replacement to
provide basic voice mail functionality and
unified messaging. None of the available
unified messaging products won them over.
“The industry really wasn’t ready for a system
of our scale at that point,” Kouba says.
UC Berkeley gave it another shot in 2004 and
found the vendors were better equipped to
handle a rollout to tens of thousands of users.
After a lengthy review process, the university
chose Interactive Intelligence and licensed
its Communité unified communications
software last year.
Communité supports a unified in-box so
users can browse and open e-mail, voice mail
and fax messages from a single interface.
The system also lets users retrieve voice, fax
and e-mail messages from multiple devices,
Executive Guide 16
EXECUTIVE GUIDE
Case studies
including desktop PCs, wireless handhelds or
cell phones.
Unified messaging helps break down some
of the walls between voice mail and e-mail
and connects the message streams, Kouba says.
In the past, people tended to reply to voice
mails with another voice call and to e-mails
with another e-mail message.“Now, if someone
sends me an e-mail and I’m listening to my
e-mail over the telephone, I can reply to that
with a voice mail attachment,” Kouba says. The
sender gets back the original e-mail message
with a small .wav attachment. “No matter
how you send me information, I can reply or
communicate in the way that I want to.”
Call-screening features tell users who’s
calling before a call is accepted, and followme/find-me technology lets users set precise
call-handling rules - specifying, for example,
which callers to send to voice mail and which
to forward to certain alternative numbers.
Users also can opt to be alerted by Short
Message Service if parties leave a voice mail
message.
Into production
UC Berkeley started its implementation
last October with a pilot group. To drum up
interest in the new technology, the IT group
asked for volunteers from different campus
departments. Getting volunteers excited about
the new system - and talking it up to their coworkers - was one of the smartest things the
university did, Kouba says.
The pilot allowed Kouba’s group to test the
application under real-world conditions.“One
of the things that we can’t do very well on
the telephony side in a development or test
environment is test-load,” Kouba says.“It’s hard
to generate real-looking calls. So that’s one of
the things that we focused on during the earlyadopter period.”
Kouba also used the pilot to tune the
integration points between the Interactive
Intelligence software and the university’s
existing systems. UC Berkeley didn’t upgrade
its telephony systems for the rollout, but it did
Back to TOC
do some heavy integration: The Communité
software is tied to the university’s Centrex
service, Nortel PBX gear, CommuniGate
Systems e-mail, iPlanet Lightweight Directory
Access Protocol directory, Kerberos security
system and campus storage-area network.
After the pilot, in January the team moved
the remainder of the university’s 10,000 faculty
and administrative staff from the old voice
mail system to the Communité platform.
Because not every user needs all the
available features, the communications group
offers different classes of service, starting with
basic voice mail and traditional telephoneonly message access. Enhanced voice mail
services let users access messages via the
Web, and unified messaging services add the
option to retrieve messages via e-mail. Addons include call screening, call routing, and
incoming and outgoing faxing options.
The communications group makes these
services available to university departments on
a chargeback basis, so department managers
can stretch their budgets by choosing services
for staff judiciously.
This fall, UC Berkeley plans to offer the new
services to residence hall students, which
could increase its implementation to 50,000
users.
In the past, as many as three students in a
dorm room had to share a single phone line.
With Communité, every student can get a
personal phone number, and each can opt
to route calls to the dorm-room phone, a cell
phone or any other phone. “Somebody can
always call that one campus phone number
and ultimately reach the student,” Kouba says.
Attracting student users is important.
Providing dorm-room telephone service is
a moneymaker for UC Berkeley, which, like
many universities, has seen its revenue drop
as students increasingly favored cell phones
over dorm lines. By offering unified messaging
options such as advanced call-forwarding
features and Web-based message retrieval,
the university hopes to regain some of those
customers.
Executive Guide 17
EXECUTIVE GUIDE
Back to TOC
VoIP-based testing
VoIP testing team ventures into new terrain
ILabs testing team finds that VoIP QoS works well, but NAT,
security remain tricky
By David Newman, Network World
By now, basic interoperability is generally
a given in multivendor VoIP settings. What
happens, however, when VoIP devices go to
work in decidedly unfriendly environments,
such as through security devices and across
wireless LANs?
Results of the testing completed by the
InteropLabs VoIP team suggest new QoS
mechanisms can work effectively, but security
remains as tricky as ever to get right. Even
though it’s not a security mechanism, network
address translation (NAT) also proved
especially troublesome.
The team built a complex test bed
connecting the VoIP phones of five
enterprises across a vast armory of firewalls,
IPSec and SSL VPN concentrators, and
intrusion-detection systems.
The security-gear suppliers included
Aventail, BorderWare, Check Point, Cisco,
Juniper and Nokia. Some vendors shipped
multiple security devices: For example,
Juniper supplied a firewall, an intrusionprevention system (IPS), two IPSec VPN
concentrators - and three engineers to get
everything working.
In addition to security boxes at the edge
of each enterprise’s network, the security
apparatus included IPSec and SSL VPN
clients for remote users. Corporate network
managers planning VoIP rollouts will probably
deploy similar setups, configuring IP phones
and security devices and drop-shipping them
to remote users.
All this equipment ensured tight security
- in some cases, a little too tight. For example,
BorderWare’s SIPAssure offered detailed
control over Session Initiation Protocol
(SIP) but didn’t provide the access controls
needed in a general-purpose firewall.
The team redesigned the network by
placing this device alongside another
firewalls. The BorderWare box became a VoIP
session border controller alongside another
BorderWare firewall.
The test bed also comprised numerous
wireless LAN (WLAN) switches, access points
and end-stations, all using the new 802.11e
standards for QoS enforcement. Phones in
this year’s event were equally diverse, ranging
from softphones on PC and Mac clients to
old analog handsets with SIP adapters and
Wi-Fi and Ethernet SIP handsets.
Unlike past years, where the focus was on
interoperability among multiple vendors’
SIP proxies, the InteropLabs team this year
standardized on the open source Asterisk SIP
proxy for four of the enterprises. At the fifth
were two proxies: an Asterisk box and the
SpectraLink SIP proxy, which SpectraLink’s
new SIP-enabled handsets require. In general,
however, the focus wasn’t on the SIP proxy
used but on the diversity of the equipment
around it.
In all, around 20 vendors contributed
equipment and engineering resources to the
effort, making this among the largest VoIP
test beds yet constructed by the InteropLabs
team.
To NAT or not to NAT
One of the most difficult decisions in this
testing demonstration was whether to use
NAT. Network architect and team leader Jim
Martin - his day job is distinguished architect
at Netzwert - initially opposed its use on the
grounds that NAT breaks the end-to-end
principle of Internet communications and
might also introduce interoperability issues.
As it turned out, he was right on both counts.
Other team members argued that
regardless of whether NAT is good or evil,
it’s in widespread use today and should be
included in at least part of the test bed. The
pro-NAT argument prevailed. Team engineers
configured one of the five enterprises to use
private net-10 addresses and enabled NAT on
a Check Point firewall linking this enterprise
to the rest of the test bed.
Enabling NAT proved to be troublesome
from the start. Initially, neither inbound nor
outbound calls reached their destinations.
It took two hours of capturing traffic from
various points and then an hourlong
discussion in front of a whiteboard to lay out
the various issues.
In situations where one side used NAT but
the other didn’t, the SIP proxy received traffic
but didn’t return it. That’s because SIP proxies
get source IP addresses from the SIP header
by default, not from the IP header. In this case,
NAT translated the source IP address in the IP
header, but not in the SIP header. Because the
SIP proxy had no route to the source address
using NAT, there was no way for the proxy to
return traffic (see diagram).
The team set a “nat=yes” parameter on the
Asterisk SIP proxy, forcing it to read addresses
Executive Guide 18
EXECUTIVE GUIDE
VoIP-based testing
from IP rather than SIP headers. This solved the first problem of the
SIP proxy not being able to send return traffic. It did not help with the
second problem: the Check Point firewall not sending return traffic
through an IPsec tunnel (this isn’t a knock on Check Point’s firewall;
virtually any NAT box would do the same thing).
This second problem proved more intractable than the first. Even
though the SIP proxy now processed traffic correctly, the firewall at
the enterprise site forwarded VoIP traffic onto the public network
instead of placing it inside an IPsec tunnel for routing back to the
remote-side caller.
Engineers from Check Point and the InteropLabs team worked to
resolve the problem but couldn’t get VoIP working with NAT during
the HotStage event. Check Point’s engineers believe the problem is
caused by the configuration’s parameters.
Cutting the cord
The WLAN setup comprised a mix of access points and WLAN
switches from such vendors as Aruba Wireless Networks, Cisco (in
IOS and Linksys versions), Extreme Networks and Symbol. In addition,
Check Point and Juniper supplied remote-office devices that combine
firewall and VPN concentrator functions with access points.
Hanging off these devices were softphones and wireless handsets
from Cisco, CounterPath Solutions, SpectraLink, Unex and UTStarcom.
A key goal of the testing was enabling the Wi-Fi Alliance’s Wi-Fi
Multimedia Extensions (WMM) to ensure better treatment for voice
traffic. Based on the IEEE’s 802.11e standard, WMM introduces a new
twist to QoS enforcement. Instead of simply queuing VoIP packets
ahead of others on any given station, it seeks to transmit VoIP packets
first from any station, helping to keep delay and jitter to a minimum.
Back to TOC
Determining which devices supported WMM wasn’t always intuitive.
For example, a consumer-grade Linksys access point offered WMM
support out of the box, but new SIP-enabled handsets did not create
packets with WMM’s QoS headers. The SpectraLink problem could be
caused by the handset or SIP proxy configuration, and at press time
team engineers were continuing to examine it.
Another problem in prioritizing VoIP traffic has to do with lining
up multiple QoS mechanisms. IP-forwarding devices, such as routers,
generally use Layer 3 criteria such as DiffServ code points (DSCP) or
IP precedence flags to classify traffic. In contrast, Layer 2 devices, such
as wireless switches, use WMM access classes found in the 802.11
header.
Most sites will generally use only one WMM access class for VoIP
traffic, but there may well be multiple DSCPs in use. As the team
learned, it’s critical that devices with both IP and WLAN capabilities
(such as WLAN switches) map all the relevant DSCPs to the
appropriate WMM access class.
Yet another issue for WLAN forwarding had to do with virtual
LAN (VLAN) tagging. Network designs often use separate VLANs for
VoIP traffic, and the InteropLabs VoIP network was no exception.
This generally worked fine, with two exceptions: First, a relatively
old Symbol switch supported only VLAN IDs between 1 and 31 - too
narrow a range to accommodate the VLAN IDs between 100 and 300
in use on the show network. To its credit, Symbol promptly supplied
its newer WS5100 switch, which supports any VLAN ID.
Second, the SpectraLink SIP proxy required that handsets reside
in the same VLAN and IP subnet as the proxy. The workaround:
On each access point, the team allocated two VLANs (each with a
unique service set identifier), one for the local subnet and one for the
SpectraLink proxy’s subnet. The
enterprise-grade WLAN devices
all handled this workaround,
but some consumer-grade
access points (such as a Linksys
WRT54GX) don’t support VLANs
at all.
Despite the various hurdles
encountered, team engineers
generally were able to call
from any location to any other
location (including offsite) by
the end of the HotStage testing
period. Team engineers and
vendors continue to work to
resolve the few outstanding
issues, and most agreed that
VoIP is getting easier to deploy,
even in environments that
aren’t necessarily VoIP-friendly.
Executive Guide 19
EXECUTIVE GUIDE
Back to TOC
VoIP-based testing
Session border controllers guide VoIP streams
SBCs are traffic cops that control VoIP traffic at the network edge
By Edwin Mier, Anthony Mosco, Robert Tarpley and Robert Smithers, Network World
Is there a session border controller in your
enterprise’s VoIP future? If you’re looking
to expand your organization’s VoIP reach
- to VoIP-based service providers, to other
enterprises or even to VoIP-interconnected
distributed sites via the Internet - there very
well may be.
Functionally, an SBC is a traffic cop: It
facilitates and mediates VoIP flows in real
time, in both directions between private VoIP
domains: an enterprise and a VoIP-based
service provider - the environment we tested
here - or two service providers. SBCs came
of age by providing peering connectivity
between different carriers’ VoIP services
and only recently have begun penetrating
enterprises.
There is no universal job description for
an SBC. Certainly there has to be versatile
handling of VoIP call-control protocols, such
as Session Initiation Protocol (SIP) and H.323,
especially amid different firewall and network
address translation (NAT) configurations.And
there needs to be some security safeguards
- hiding the network topology of the private
network, for example. But overall, SBCs are
complex and costly components, coming
from diverse backgrounds and offering
widely varying capabilities.
We invited more than a dozen vendors
who were touting new SBC wares earlier
this year to submit their packages for testing
in Miercom’s New Jersey lab. Four accepted
our challenge for this feature-based testing:
Ditech Communications, Ingate Systems, Mera
Systems and NexTone Communications.
Despite many differences in the feature
sets of these products (see “What SBCs do”),
their general orientations lie in a few similar,
basic areas, including VoIP call handling, QoS
handling and security capabilities. Based
on our assessment in these areas, our Clear
Choice Test Award goes to NexTone’s package,
CLEAR CHOICE TEST
the Multiprotocol Session Controller (MSC)
coupled with its iView Management System
(iVMS). NexTone’s dynamic VoIP session
control, real-time monitoring with active
error and threshold-limit notification, calllevel reporting system, and integrated firewall
features make it the best of the enterprisefocused SBCs we tested. We note, though,
that the NexTone package costs considerably
more than the competition (more than
$100,000, compared with $25,000 to $38,000
for the others).
NexTone Communications
One strength of NexTone’s Linux-based
MSC was its exceptional management and
reporting, augmented by the powerful routing
engine of the optional iVMS. NexTone could
be set up to adapt dynamically and to alter
operational behavior involving admission
control, routing priorities and bandwidth
allocation, based on fluctuating network
conditions and changed user or application
behavior. For example, we observed how the
system can be set up to divert traffic from
low-cost VoIP carrier A to carrier B, if the
quality measurements of calls via carrier A
drop below established thresholds. Also, the
parameters that users can apply for routing
decisions by NexTone’s MSC are broader and
include, for example, user profile, time of day
and desired QoS - the example cited earlier.
The iVMS allows routing and rerouting of
calls among carrier services and trunks, and
serves up extensive VoIP-quality reporting,
including statistics on average call duration
and postdial delay. We exercised the routing
capabilities of this product by setting
up multiple trunk groups and changing
conditions to cause rerouting. One way was
to unplug a gateway and see whether calls
would reroute if there was a viable alternate
path. In another case we intentionally
oversubscribed the amount of bandwidth
allocated in Call Admission Control, to
ensure the overflow calls would be blocked.
In both cases, the NexTone product worked
as advertised.
Another capability of NexTone’s SBC is that
it offers seamless connectivity between SIP
phones and applications and H.323-based
IP PBXs. This feature lets users connect
their existing legacy VoIP environments,
which are mostly H.323-based, to VoIP-based
A word about performance
In this inaugural test of session border controllers (SBC), it was not
our intent to get into the minutiae of product performance, because SBCs
have disparate feature sets and deployment options. That said, we can
make some general assessments about SBCs based on the results of our
sending modest levels of Session Initiation Protocol call traffic through
them. SBCs’ effects on call quality varied from essentially no degradation
(mean opinion score [MOS] of 4.5, R-factor of 93) to measurable degradation (MOS of 3.9, R-factor of 85). SBCs also could add to call-setup time
and latency; the extent appears to vary based on the power of the SBC
hardware platform.
Executive Guide 20
EXECUTIVE GUIDE
Back to TOC
VoIP-based testing
carrier services, which are mostly SIP-based.
We tested the MSC’s role in this process by
placing a VoIP call between an H.323 and
a SIP endpoint, and verified that it worked.
The connection setup and quality were
good, despite the mismatch in call-control
protocols.
For security, NexTone does token-based
bandwidth throttling of sessions that exceed
a set threshold, with stepped reinstatement.
Both are sophisticated mechanisms for
protecting against incorrect or unauthorized
IP traffic, which could be denial-of-service
(DoS) attempts. There can be multiple
cycles of allowing or reinstating a suspect to
see whether their intentions are legitimate.
NexTone also can tell whether there is
a mismatched address in the call-setup
process, which normally would prevent
call setup or indicate a possible threat. In
this case NexTone will send call-control
information to the source address - where
the request actually came from - to set up an
audio path and ignore what is the incorrect,
possibly spoofed originating address. Here,
the NexTone package must take over routing
of the call, which it can do only because it
can assume full SIP call control.
The downside to this product is its
complexity. Installation and configuration
require an onsite NexTone team, who
configure the system to be left on its own.
NexTone strongly suggests the NexTone
University for training additional customer
personnel who will configure and tune
the system. Also, unlike some competitors,
NexTone’s package does not interact with
any existing or legacy firewalls. This can be a
major shortcoming for an organization that’s
comfortable with its embedded firewalls.
VoIP (while having another firewall handle
all other firewall functions) or to handle all
firewall processing. There’s no underlying
H.323 support - it’s SIP-only - but the base
firewall has been extended considerably
with SIP-based VoIP features.
We spent the bulk of our testing time
focused on how SIParator’s firewalling
integrated with its QoS capabilities. For
example, we examined its ability to
recognize and appropriately handle type of
service and Differentiated Services values.
We went through screens and configuration
for categorizing call types into queues with
different threshold, QoS and priority settings.
We confirmed the system marked and
handled traffic as expected.
Ingate has detailed SIP-configuration
settings, so it is rich in that regard, but
understanding and applying the appropriate
settings requires more than typical
knowledge of VoIP in general and SIP in
particular, especially if you need to integrate
the Ingate system to work with an existing
firewall. Online help is available on a screen
basis, but that can still be a pretty awesome
task and entails dozens of technical settings.
We checked the configuration screens,
documentation and online help to make sure
that it was clear how to attach this system
behind a legacy firewall, split data from VoIPhandling tasks and route between the two.
We did not integrate this unit with any legacy
firewall as far as our test process. We saw that
deploying it in this manner was supported
and documented.
Ingate Systems
The strength of the Ingate SIParator 60 SBC
centers on its solid firewall platform, which
works with existing, legacy firewalls.
The Ingate firewall is SIP-aware, which
means it understands and accommodates
SIP-protocol flows for opening and closing
ports, address translation and so on. The
SIParator is especially clear in its setup
choices. You can configure it to handle just
Executive Guide 21
EXECUTIVE GUIDE
VoIP-based testing
There’s also a full SIP proxy server on board
the Ingate box, which allows it to participate
in SIP call control. An SBC normally is not
expected to interfere with or modify the SIPcalling information. By containing a full SIP
proxy server, however, the SBC can apply a
higher level of oversight and involvement in
SIP operations. For example, as a proxy server,
the Ingate SBC can rewrite the SIP header of
inbound and outbound call-setup messages
on the fly, to accommodate particular SIP
domain names and name changes.
The Ingate product offers no trend reporting,
no call-quality reporting and no per-call
quality assessment. Ingate monitors what is
going on and provides real-time data, such as
number of active calls and ports open, but it
does not address any sort of cumulative data
collection or reporting. The administrator of
the SIParator can access a monitoring GUI,
but what is available is limited and reported
in real time; it might help troubleshooting
somewhat, but not in facilitating any kind of
trend reporting.
Near- and far-end NAT-traversal support
make the Ingate product adept at getting
VoIP calls through to the right destination,
even with different near- and far-end firewall
and NAT configurations in place. The Ingate
SIParator also offers redundancy and VoIP
survival features, such as alternate gateways,
backup registration for callers, domainavailability checking and failback rerouting.
It is also tightly integrated with Microsoft Live
Communication Server 2005, for handling
VoIP in conjunction with video, IM and
presence applications.
Mera Systems
Mera Systems’ Mera VoIP Transit Softswitch (MVTS) software-only SBC began
life as a softswitch and is extremely rich in
supported VoIP call-handling protocols and
features. MVTS runs atop Red Hat Linux 9
on almost any high-end server platform (the
more the better, as far as RAM and gigahertz).
Sophisticated call routing through this
product employs a panoply of criteria,
including time of day, QoS and precedence,
and route load. Of the products tested, Mera
Back to TOC
Ingate Systems’ SIParator 60 Score: 3.6
This SIParator 60 originated as a firewall, on top of which Ingate added a full
Session Initiation Protocol proxy server and various add-on software modules for
VoIP call handling and routing. We tested the SIParator with several separately priced
add-on modules, including the Remote SIP Connectivity Module, the Advanced SIP
Routing Module, the Quality-of-Service Module and the VoIP Survival Module.
Besides the SBC basics - like individual VoIP-call monitoring, topology hiding, and
caller authentication - the Ingate appliance adds security, survivability and routing
features to an enterprise network. Security-wise, the system employs various
techniques for delivering calls through remote firewalls, and it can work alongside
existing, legacy firewalls.
Survivability is enhanced by software that lets VoIP operations continue around IPconnection failures-by handling reregistration of SIP callers-and alternate-gateway
re-routing. Only SIP-based VoIP calls are supported.
Other notable, though not unique, aspects of the SIParator include: tight integration
with Microsoft’s Live Communications Server 2005 (Microsoft has its own special way
of handling SIP calls, with regards to encryption and call routing); several methods of
authenticating callers (via internal databases or external RADIUS servers); and good
alarm and log capabilities, including SNMP support.
While it was not yet available when we tested the product in February, Ingate
indicated it would add Secure-RTP encryption for VoIP in its next release, expected to
ship sometime this month.
NexTone Multiprotocol Session Controller and iView
Management System Score: 4.2
The core of NexTone’s SBC package is the MSC, a souped-up VoIP-call routing
engine. The extra-priced iVMS is a call-quality rating, performance monitoring, and
reporting system. The set-up of call routing with NexTone’s MSC is extremely granular.
For example, the system can be setup to dynamically change such settings as Call
Admission Control, Routing Priorities, Policy Enforcement and Bandwidth Allocation
based on the usage behavior, service availability and so on.
With its broad protocol support - H.323, including many variants for specific IPPBX vendors, as well as Session Initiation Protocol, and translation between the two
- this SBC is well-suited for mixed-protocol and multi-vendor environments. We tested
this by connecting SIP and H.323-based softphones, which interoperated transparently.
The second part of the NexTone package, the iVMS system, provides collects
and reports session information, and includes an excellent GUI-based monitoring tool
called iView. A short list of the call information that can be collected and reported
includes: origination, destination, IP addresses, endpoint entities, call durations, ring
times, error codes, Mean Opinion Score ratings, latency, dropped packets and total
packets.
Executive Guide 22
EXECUTIVE GUIDE
Back to TOC
VoIP-based testing
supports the most complete transcoding - onthe-fly conversion between high-bandwidth
G.711 VoIP Real-time Transport Protocol (RTP)
streams and low-bandwidth G.729 streams. A
host of other vocoders also are supported. SIP
to H.323 translation is akin to the seamless
gateway interworking that NexTone provides.
To test the translation capabilities of the Mera
product, we placed calls through it between
an H.323 endpoint and a SIP endpoint on the
other side and confirmed that these features
worked as advertised.
Mera’s software collects a lot of useful
details about VoIP traffic and activity. It can
collect and display dozens of parameters
about each call. These are stored in detailed
logs, but in a confusing Linux-style format,
which frustrates the useful consolidation and
consumption of this data. While the product
provides a lot of data, you’ve got to extract it
in an ASCII log file via command-line entry.
It’s by no means a neat, legible graphical
presentation of the information. It also
doesn’t provide much in terms of formatted
reports or trend analysis.
Another shortcoming of the Mera package
is security: There are no firewall capabilities
and no direct protection from a DoS attack,
for example. Enterprise users considering the
Mera package will need to address firewall
and intrusion-prevention system security
separately.
Ditech Communications
Ditech’s PeerPoint C100 is a Linux-based
appliance that supports only SIP-based call
control. Beyond VoIP call handling, this SBC
provides rich firewall capabilities, as well as
strong DoS-attack handling.
Many of these security features were
demonstrated on monitored calls and showed
a detailed level of settings for automatic
protection. DoS-attack profiles can be created
based on standard Internet protocols or
detected call-transmission rates. SIP protocol
header fields also can be filtered actively to
prevent details of the internal network from
being broadcast to the Internet. Intelligent
monitoring is used by the C100 to flag and
monitor suspect incoming connections.
The monitoring uses active scorekeeping
and configurable timers to identify problem
THE TIPJAR: Get to know your VoIP network
1.) Know your VoIP network well in terms of equipment, protocols, traffic load. In
addition to IP phones and VoIP gateways, you’ll need a firm understanding of the
other network components that may affect VoIP flows and your session border
controller (SBC) deployment, including firewalls and intrusion-prevention systems,
DHCP and DNS environments, and possibly some aspects of your Layer 2 and Layer
3 infrastructure .
2.) Plan to test all VoIP flows and routes through the SBC before going live.
3.) Get your carriers and IP telephony vendors involved in the process. The questions
you need input on include: Do they have experience working with the SBC you’ve
selected? Have they worked in combination with other service providers and the IP
PBX vendors you have chosen? What are the preferred setting you need to have in
place with regard to timers, rerouting messages, security setting and the planned
SBC settings?
4.) Remember that your SBC objectives are improving security and saving money.
With the complexities of VoIP networking, it’s possible to lose sight of why you’re
deploying an SBC in the first place. If, for example, VoIP call quality drops to the
point where all or most calls are rerouted over the public switched telephone
network, it may end up costing you a lot more money.
connections from an incoming client,
who is then incrementally prevented and
optionally reinstated for access back into
the local network. This process, which can
be configured by combinations of IP address,
port number and dynamic message failure
ratios, performs automatically without
administrator
intervention.
Additional
protection is provided by enabling
examination of RTP, the standardized Internet
content transmission format, to validate its
declared content (audio and video), thus
preventing a disguised executable from
entering the system.
Other strengths include sophisticated nearand far-end NAT traversal (such as with the
Ingate product), and Secure RTP (sRTP)
encryption and Transport Layer Security
(TLS: encrypted SIP call control) support. To
check out Ditech’s NAT traversal, we used
Ditech’s own method of querying the open
call sessions and problems by sending and
monitoring the results of SIP reinvites to both
sides of the NAT. We captured and examined
call sequences and RTP streams to confirm
TLS and sRTP.
We give kudos to Ditech’s installation
because initial configuration and establishing
settings are based on an embedded relational
database that retains values entered and
propagates the values to other screens and
tabs in the system (to drop-down boxes, for
example). This lets you avoid the arduous
process of having to reenter the same data
multiple times, and helps ensure valid entries
in screens.
The vendor’s adjunct Packet Voice Processor,
which was not included in the configuration
we tested, reportedly adds support for
transcoding and other per-call quality
measurement and reporting, and quality
trend reports and intelligent packet repair.
Other noteworthy aspects of the Ditech
package include its tight compatibility with
Microsoft Live Communications Server 2005;
a special feature for keeping calls connected
(called stateful failover, it worked seamlessly
in our testing, with failover occurring in
less than a second, resulting in no dropped
calls); and what Ditech calls media path
optimization, where the system decides
Executive Guide 23
EXECUTIVE GUIDE
Back to TOC
VoIP-based testing
whether to proxy media streams or allow
direct point-to-point RTP communications.
The four SBCs tested all showed they could
competently process and manage SIP-based
VoIP calls between an enterprise environment
and a simulated service provider, front-ended
by a prominent third-party, carrier-oriented
SBC. Interoperability between the carrierside SBC employed in the test bed and the
enterprise-based SBCs we tested did not
prove to be a concern.
Emerging with the top score from this
Ditech Communications’ PeerPoint C100 Score: 3.4
The PeerPoint C100 is a Linux-based appliance that is - as alluded to in its name usually sold as two redundant units where one runs as primary, the other as secondary
hot standby. There is no hard drive - a design option chosen mainly for reliability and,
secondarily, for security. Instead, the operating image loads from a flash-memory card
and runs in RAM.
The SBC ships with one of its laudable features - near- and far-end NAT traversal
- enabled by default. Because of the complexity of setting up some parameters, such
as security certificates, the vendor is usually engaged for a “pre-provisioning” service.
A separate adjunct subsystem, called the Packet Voice Processor (PVP), adds
many features for massaging VoIP RTP streams, such as noise and echo control,
volume control and intelligent packet restoration. But the PVP was not included in the
configuration tested, a fact which limited the range of features we could give Ditech’s
SBC credit for.
A notable aspect of the PeerPoint C100 that we verified was its ability to diagnose
the network on a per-call basis and determine when to regenerate VoIP streams,
or allow direct media flows between endpoints. It’s important to note that this SBC
addresses Session Initiation Protocol-only call environments. Support for SIP
environments is fairly full, including RTCP features and was fully interoperable with
the carrier-level Sansay VSX SBC with which we tested it.
Mera Systems VoIP Transit Softswitch Score: 3.6
test round was NexTone, whose package
we believe best suits a large enterprise
- because of its high price tag, support for
legacy H.323-based PBXs, and very detailed
reporting that most benefits an organization
with a dedicated VoIP admin staff. Ingate
placed second, with a system that adds good
SIP-based VoIP security to an enterprise that
may want to retain its legacy data-network
firewalls. Closely behind Ingate were Mera
Systems and Ditech, which tied. Mera’s
software-only package favors enterprises with
a lot of legacy VoIP, as it handles many forms
of VoIP protocol and RTP stream conversion.
Ditech’s appliance provides enterprises with
SIP-based VoIP, added security, call- and QoShandling.
Mier is founder and president, Mosco
and Tarpley are lab testers, and Smithers is
CEO at Miercom, a network consultancy
and product test center in East Windsor, N.J.
They can be reached at: ed@miercom.com,
amosco@miercom.com, rtarpley@miercom.
com and rsmithers@miercom.com, respectively.
They are also members of the Network
World Lab Alliance, a cooperative of the premier reviewers in the network industry, each
bringing to bear years of practical experience
on every review. For more Lab Alliance information, including what it takes to become a
member, go to www.networkworld.com/alliance.
The Mera VoIP Transit Softswitch is a software-only SBC package, which we
tested on a not particularly high-end laptop (a Pentium 4, 2.4 GHz, 512KB RAM
- running Red Hat Linux 9.0). A separate software module, the Session Initiation
Protocol-H.323 Inter-protocol Translator (SIP-HIT), ran on the same Linux platform.
The setup is extremely tailorable - more than 400 parameters can be defined, mainly
related to routing, protocol handling, and call-load distribution.
There is separate management software, called the MVTS Manager, which we
loaded and ran on a Windows XP laptop. Management access can be accomplished
either as a Windows GUI or via a Web browser. MVTS is natively H.323 based.
The SIP piece adds all the SIP functionality. The package extends from a softswitch base, with features that add to the efficiency of VoIP call handling. Call load
can be distributed to avoid bottlenecks or heavily used routes, which keeps callquality high. The ability of this package to transcode on the fly between different VoIP
coders is impressive.
With the very tailorable settings and SIP and H.323 interoperability, this SBC
package is likely to be able to handle interoperability and inter-connectivity of many
different IP-telephony systems, as well as VoIP-based carrier services.
Executive Guide 24
EXECUTIVE GUIDE
VoIP-based testing
Back to TOC
.ET2ESULTS
0RODUCT
/FY5POF
.VMUJQSPUPDPM4FTTJPO
$POUSPMMFS.4$
BOE
J7JFX.BOBHFNFOU
4ZTUFNJ7.4
*OHBUF4*1BSBUPS
.FSB7P*15SBOTJU
4PGUTXJUDI
%JUFDI1FFS1PJOU
$
.EX4ONE
#OMMUNICATIONS
WWWNEXTONECOM
)NGATE3YSTEMS
WWWINGATECOM
-ERA3YSTEMS
WWWMERASYSTEMSCOM
$ITECH
#OMMUNICATIONS
WWWDITECHCOMCOM
&ROMUP
FOR-3#
DEPENDINGONSERVICEAND
OPTIONSI6-3BASE
PRODUCTSTARTSAT
FORSYSTEM
FORSYSTEMTESTED
FORSYSTEM
0ROS
'REATDETAILEDREPORTS
ONCALLQUALITYAND
PERFORMANCESTATISTICS
BESTADMINISTRATION
INCLUDINGALARMSAND
PROVISIONING(
HANDLINGINTERWORKING
WITH3)0RICHANDFLEXIBLE
CALLROUTING
CONFIGURABILITY
#ONS
6ENDOR
0RICE
CONCURRENTCALLS
ALLSOFTWAREPRODUCT
,INUXBASED
TESTEDCONCURRENT
CALLS
&ULLFEATUREDFLEXIBLE
INTEGRALFIREWALLCAN
DEPLOYWITHEXISTING
LEGACYFIREWALLVARIOUS
NETWORKADDRESS
TRANSLATION.!4
ENVIRONMENTSSUPPORTED
VIAOPTIONALMODULE
"ROADEST6O)0PROTOCOL
SUPPORTFULLTRANSCODING
SUPPORTSSEVERAL
REDUNDANCYCONFIGURATIONS
RICHCALLROUTING
CAPABILITIES
&LEXIBLECONFIGURATION
INCLUDING.!4TRAVERSAL
SUPPORTSTRAIGHTFORWARD
INSTALLATIONSPECIAL
-ICROSOFT,IVE
#OMMUNICATIONS3ERVER
3)0SUPPORT6O)0
ENCRYPTION3ECURE2EAL
4IME4RANSPORT
0ROTOCOLSPECIALSUPPORT
FOR6O)0CONFERENCE
SERVERS
.OTRANSCODINGHIGH
PRICETAG
.O(SUPPORTNO
TRANSCODINGLIMITED
6O)0QUALITYANDTREND
REPORTING
,IMITEDSECURITYNODIRECT
PROTECTIONFROM
DENIALSOFSERVICEATTACKS
NOFIREWALLCAPABILITIES
3)0ONLYPROTOCOL
SUPPORTNOINTEGRAL
FIREWALLLIMITED
6O)0QUALITYREPORTING
3CORE
TESTEDREGISTERED
CALLERSINCLUDING
REMOTE3ESSION)NITIATION
0ROTOCOL
3)0CONNECTIVITY
ADVANCED3)0ROUTING
6O)0SURVIVALAND1O3
OPTIONALMODULES
.EX4ONE-ULTIPROTOCOL3ESSION
#ONTROLLERANDI6-3
)NGATE3)0ARATOR
-ERA6O)04RANSIT3OFTSWITCH
$ITECH0EER0OINT#
6O)0HANDLING
#ONFIGURATION
3ECURITY
!DDITIONALFEATURES
5IF#SFBLEPXO
5PUBMTDPSF
4DPSJOH,FZ%XCEPTIONAL6ERYGOOD!VERAGE"ELOWAVERAGE3UBPARORNOTAVAILABLE
Executive Guide 25
EXECUTIVE GUIDE
Back to TOC
VoIP security
Lab Alliance
How to protect your VoIP network
Beware of phreakers, fraudsters, sniffers, RATS, SPIT,
men in the middle, broadcast storms, Wi-Fi jamming.
VoIP has finally arrived as a mainstream
application. IP PBX equipment sales topped
$1 billion in 2005, for the first time outpacing
traditional TDM PBXs, according to Dell’ Oro
Group.
In fact, analysts predict that IP PBXs will
account for more than 90% of the market by
2009. Before you deploy VoIP, however, you
need to be aware of the security risks and the
countermeasures that you can take.
Security is important in every context,
but especially when you’re replacing the
world’s oldest, largest and most resilient and
available communications network. While no
individual security measure will eliminate
attacks against VoIP deployments entirely, a
layered approach can meaningfully reduce
the probability that attacks will succeed.
The threats
Enterprise VoIP customers and service
providers are vulnerable to many of the same
impersonation-based attacks “phreakers”
attempt against traditional telephone and
cellular services. The goals - identity and
information theft and toll fraud - are the
same.
Many attacks focus on VoIP endpoints.
The operating systems, Internet protocols,
applications and management interfaces of
VoIP hard phones and computers running
softphones are vulnerable to unauthorized
access, viruses and worms, and many denialof-service (DoS) attacks that exploit common
Internet protocols and VoIP protocols
themselves.
VoIP uses the IETF Session Initiation
Protocol (SIP) and the Real-time
Transport Protocol (RTP) for call
signaling and voice-message delivery.
These and complementing session
description and RTP control protocols
(SDP, RTCP) do not provide adequate
call-party authentication, end-to-end
integrity protection and confidentiality
measures on call signaling and call
data (such as media streams containing
compressed and encoded speech). Until
these security features are implemented and
put into service, attackers have many vectors
to exploit.
Today, SIP and RTP protocols do not encrypt
call-signaling packets and voice streams,
so identities, credentials and SIP Uniform
Resource Identifiers (phone numbers) of
callers can be captured using LAN and
wireless LAN (WLAN) traffic-collection tools
(sniffers).
An attacker can use captured account
information to impersonate a user to a
customer representative or self-service portal,
where he can change the calling plan to
permit calls to 900 numbers or to blocked
international numbers. He also can access
voice mail or change a call forwarding
number.
Impersonation attacks commonly are
used to perpetrate toll fraud, but financially
motivated attackers also can capture voice
conversations and later replay them to obtain
sensitive business or personal information.
Flooding VoIP targets with SIP call-signaling
messages (e.g., Invite, Register, Bye or RTP
media stream packets) can degrade service,
force calls to be dropped prematurely and
render certain VoIP equipment incapable of
processing calls entirely.VoIP equipment also
may be vulnerable to DoS attacks against
such Internet protocols as TCP SYN, ping of
death and the recent DNS distributed DoS
amplification attacks.
VoIP systems also can be disrupted by
media-specific attacks, such as Ethernet
broadcast storms and Wi-Fi radio jamming.
Operating systems and TCP/IP stacks used
in new VoIP hardware may be susceptible to
implementation-specific attacks that exploit
programming flaws. This can cause the
Executive Guide 26
GIACOMO MARCHESI
By David Piscitello, Network World
EXECUTIVE GUIDE
VoIP security
system to cease operating or provide the attacker with remote
administrative control of the system.
VoIP softphones pose a unique and thorny problem. Softphone
applications run on user systems (PCs, PDAs) and thus are
vulnerable to malicious code attacks against data and voice
applications. IT administrators must consider the possibility that
an attacker may try to evade conventional PC malware protection
by injecting malicious code via a VoIP softphone application.
Spam often harbors spyware and remote administration tools.
Spam over Internet telephony can carry unsolicited sales calls
and other nuisance messages, and programs downloaded to
softphones could include hidden malware.
Even this partial description should cause IT managers to
assess the risk of introducing VoIP, and to develop a policy and
an implementation plan to reduce the risks using security
technology at hand.
Back to TOC
VoIP vulnerabilities
1. Call tampering
The attacker can tamper with calls in progress; for example,
he could impair the quality of the call by interjecting noise in
the Real-time Transport protocol stream, by withholding
delivery of RTP packets so that conversation elements are
lost or by delaying delivery so participants encounter long
periods of silence during the call.
Internet café hot spot access
point (open authentication,
no encryption)
INTERNET
Risk assessment
Voice is a perennial cash cow for traditional telephony service
providers, a lucrative emerging market for VoIP vendors and
a mission-critical service for businesses. Thus, the most serious
risk public (carrier) and private (enterprise) VoIP operators must
manage is service disruption.
VoIP users will expect no less than the high availability they
are accustomed to receive from the public switched telephone
network (PSTN). Accordingly, a thoughtful VoIP deployment
plan for all would-be VoIP operators must include measures for
reducing the threat of DoS attacks.
Other priority risks include identity theft and toll fraud.
Public operators face a greater challenge than do PSTN and
cellular carriers with identity and endpoint verification in VoIP
deployment because endpoint IP addresses are generally not
validated at Internet ingress points, and unlike public telephone
numbers, there are as yet no widely adopted methods for VoIP
operators to certify or assert cooperatively that a SIP identity is
valid.
VoIP operators must manage trust relationships with other
VoIP operators carefully and should avoid service arrangements
unless they have some confidence that the other providers are
using equivalent identity and endpoint verification methods.This
might be arranged contractually across an extended enterprise
or business-to-business VoIP deployment.
In general, insider attacks are more frequent than outsider
attacks, so enterprise VoIP network operators must consider
impersonation a threat even if they operate in isolation. Enterprise
VoIP managers then must consider methods to detect and block
impersonation attacks, and should maintain accounting and
auditing tools to help detect abuse and identify perpetrators.
While public VoIP infrastructures may be more frequently
targeted for politically motivated attacks and terrorism, private
VoIP networks increasingly are at risk of electronic industrial
Alice’s Session
Initiation Protocolenabled phone
1
Ted
connects to
wireless LAN
at Internet café,
calls Alice from
softphone.
2
RTP media packets
of conversation
Attacker intercepts
voice traffic and degrades
call by injecting noise
and delay.
RTP media packets
containing noise
Attacker-injected delay
2. ‘Man-in-the-middle’ attacks
VoIP is vulnerable to man-in-the-middle attacks. In MITMs,
the attacker intercepts SIP call-signaling traffic and masquerades as the calling party to the called party, or as the called
party to the calling party. Once the attacker has gained this
MITM position, he can hijack calls via a redirection server.
Ty p i c a l V o I P c o n v e r s a t i o n .
1
User IP phone
IP PBX
At t a c ke r i n te rc e p t s S I P s i g n a l i n g t r a ff i c .
2
User IP phone
IP PBX
Hacker
At t a c ke r m a s q u e r a d e s a s t h e c a l l i n g a n d t h e c a l l e d
p a r t i e s , a n d h i j a c k s c a l l s v i a a r e d i r e c t i o n s e r v e r.
3
Fake user
IP phone
IP PBX
Hacker and redirection server
Executive Guide 27
EXECUTIVE GUIDE
VoIP security
espionage and eavesdropping attacks (for example,
employees intercepting privileged calls).
Enterprise customers also must consider help desk and
customer care. Service disruption, subscriber impersonation
and toll fraud are serious support matters. Resolving disputes
and restoring service to employees who are victims of such
attacks sap resources and adversely affect productivity. The
effects that security incidents may have on consumer, user,
management and even shareholder confidence can be
lasting.
Countermeasures
Back to TOC
Anatomy of a VoIP DDoS attack
SI
SI
P
P
IP PBX
IN
IN
VI
VI
TE
TE
>S
>
IP
SIP
INV
INV
ITE
ITE
> SIP
> SI
INVITE
ITE
P INV
Call table entries
INTERNET
2 IP PBX creates a 3 IP PBX sends
VoIP is a new and different type of Internet application, 1 Attack hosts send
multiple simultaneous new entry in local
response and
but ultimately it is another real-time data stream delivered
Session Initiation
call table for each
waits for next message
using IP. Many of the security measures widely used today to
Protocol Invite
Invite message.
from caller’s party.
protect other plain text applications, from telnet and FTP to
messages to IP PBX.
Web, e-mail and instant messaging, can be used to improve
VoIP security.
The majority of VoIP service applications are run on
IP PBX
commercial server operating systems. Hardening servers
and employing antitampering and host intrusion detection
demonstrably improve an organization’s baseline VoIP
security. The most frequently recommended server security
measures that can be applied to voice servers include:
Maintain patch currency for operating system and VoIP
INTERNET
applications.
Run only applications required to provide and maintain
4 Attack hosts ignore response message from IP PBX and continue
VoIP services.
sending Invite messages, overwhelming IP PBX.
Require strong authentication for administrative and user
account access.
infected clients to VoIP servers in monoculture (such as Windows)
Enable only user accounts required for maintenance
networks. This often results in much simpler security policies in
and correct operation to deter forced break-ins.
Implement stringent authorization policies to prevent unauthorized each compartmentalizing firewall than the policy you would have to
maintain in a single firewall.
access to VoIP service and account data.
Segmentation is a powerful security tool, so don’t stop here. The
Audit administrative and user sessions and service-related
same segmentation methods used to heighten security can be used to
activities.
Install and maintain server firewall, antimalware, and antitampering implement QoS: For example, putting SIP phones on their own VLAN
helps restrict VoIP to permitted devices and gives higher priority to
measures to deter DoS attacks.
Securely configure VoIP applications to prevent misuse; for VoIP as IP packets move from network edge to core.
Consider segregating voice user agents (hard phones) from PCs and
example, a whitelist of callable country codes can thwart certain call
forward, transfer and social-engineering exploits that might result in laptops used to access networked data applications. This may prevent
a successful attack against a data segment from spreading to and
toll fraud and unauthorized use.
Once VoIP servers and the applications they run are securely interfering with voice systems. Firewall performance may be an issue
configured, build an in-depth defense by adding layers of security when applying segmentation and policy-based compartmentalization,
around servers. Isolate VoIP servers and required infrastructure so plan carefully to avoid adding latency to paths that will transport
(for example, DNS, LDAP) from client machines (phones, PCs and media streams.
Endpoint security adds an outer layer of security in VoIP
laptops) by using separate physical or virtual LANs (VLAN) to carry
management, voice and data traffic.
deployments. IEEE 802.1X port-based network access control and
Use firewalls to limit types of traffic that may cross VLAN boundaries equivalent network admission techniques provide an additional layer
to only those protocols necessary. This compartmentalization of authorization control by blocking devices from using a LAN or
is especially effective in reducing the spread of malware from WLAN until they pass security checks.
•
•
•
•
•
•
•
•
Executive Guide 28
EXECUTIVE GUIDE
Back to TOC
VoIP security
Administrators can choose to block devices
infected with malware or that do not satisfy
other admission criteria, such as current
patches and appropriately configured
firewalls. They can redirect noncompliant
devices to an isolated LAN segment that
offers limited services or to a LAN where
softphone users can access software, patches
and malware definition updates required
to satisfy admission criteria. In many cases,
these security measures can be performed
before authentication, to prevent malware
(keystroke loggers) from capturing user
credentials.
Companies using firewalls to enforce
security policy may discover that their current
firewall is unsuited to the task of securing
voice and data. Traditional network firewalls
are designed to permit and deny traffic based
on TCP, User Datagram Protocol (UDP) and IP
header information: IP addresses, protocol
types and port numbers, for example.
VoIP protocols use a large range of UDP
ports and allocate them dynamically to
media streams. Many traditional firewalls
cannot accommodate this behavior without
leaving large swaths of port numbers
permanently open for VoIP use and other
misuses. Certain firewalls do not process
UDP efficiently. Others do not support QoS
measures to manage latency and jitter so that
VoIP calls have toll-voice quality.
IT administrators should consider firewalls
that are SIP-aware, that can detect and
counterattack against SIP signaling messages,
and that can process RTP media streams
without adding significant latency.
Application-layer
gateways
(proxies)
can play a useful role in VoIP deployment.
Incorporating SSL tunnels into SIP proxies
is becoming a popular way to improve
authentication and add confidentiality and
integrity protection on signaling messages
exchanged between user agents and SIP
proxies.
Many organizations are considering
chaining SSL connections to protect
signaling traffic between SIP proxies across
their organizations and interorganizationally
as well. RTP proxies may be appropriate if
your organization must relay media streams
among global and local RTP IP addresses
and ports. Other organizations are choosing
to take advantage of their investment in IPSec
to secure VoIP traffic between sites.
In some configurations, organizations
may try to process VoIP traffic preferentially
by creating IPSec security associations
that prioritize voice traffic over data. Some
organizations may want to filter signaling
traffic and RTP media streams through a
Session Border Controller (SBC).SBCs operate
as back-to-back user agents, concatenating
and applying policy to calls between public
and private user agents. In some respects, an
SBC behaves like a secure e-mail proxy. It can
rewrite message headers to hide details of
private networks (such as addresses), strip
unknown and undesirable header SIP fields,
and restrict called-party numbers. Because
media traffic flows through an SBC, RTP
policies can be enforced at them.
These security measures, along with a
proactive security monitoring and intrusiondetection and -prevention plan, not only
improve VoIP security, but can greatly reduce
the risks to data networks as organizations
introduces VoIP. Many of these measures will
continue to be useful in deployments even
after security enhancements are incorporated
into VoIP protocols and architecture.
Executive Guide 29
EXECUTIVE GUIDE
Back to TOC
VoIP security
Phishing leverages VoIP in new scam model
VoIP plays role in new phishing scam.
By Cara Garretson, Network World
Small businesses and consumers aren’t the only
ones enjoying the cost savings of switching to
VoIP; according to messaging security company
Cloudmark, phishers have begun using the
technology to help them steal personal and
financial information over the phone.
Cloudmark recently trapped an e-mailed
phishing attack in its security filters that appeared
to come from a small bank in a big city and
directed recipients to verify their account
information by dialing the included number (the
Cloudmark user who received the e-mail and
alerted the company knew it was a phishing scam
because he’s not a customer at the bank).
Usually phishing scams are e-mail messages
that direct unwitting recipients to a Web site to
capture their personal or financial information.
But because much of the public is learning not
to visit the Web sites these messages try to direct
them to, phishers believe asking recipients to dial
a phone number instead is novel enough that
people will do it, says Adam O’Donnell, senior
research scientist at Cloudmark.
And that’s where VoIP comes in. By simply
acquiring a VoIP account, associating it with
a phone number and backing it up with an
interactive voice recognition system and free
PBX software running on a cheap PC, phishers
can build phone systems that appear as elaborate
as those used by banks, O’Donnell says. “They’re
leveraging the same economies that make VoIP
attractive for small businesses,” he says.
Cloudmark has no proof that in this example the
phisher was using a VoIP system, but O’Donnell
says it’s the only way that staging such an attack
could make economic sense for the phisher.
The company expects to see more of this new
form of phishing. Once a phished e-mail with a
phone number is identified, Cloudmark’s security
network can filter inbound e-mail messages
and block those that contain the number, says
O’Donnell.
Executive Guide 30
EXECUTIVE GUIDE
VoIP security
Back to TOC
Secure SIP protects VoIP traffic
Security mechanism helps fill hole in Session Initiation Protocol.
By Michael Ward, Network World
Session Initiation Protocol has become
the call control protocol of choice for VoIP
networks because of its open and extensible
nature. However, the integrity of call signaling
between sites is of utmost importance, and
SIP is vulnerable to attackers when left
unprotected.
Secure SIP is a security mechanism defined
by SIP RFC 3261 for sending SIP messages
over a Transport Layer Security-encrypted
channel. Originally used for securing
HTTP sessions, TLS can be repurposed to
protect SIP session communications from
eavesdropping or tampering. By deploying
SIP-based devices that support Secure SIP,
network administrators benefit from these
increased levels of security for their VoIP
networks.
Thwarting threats
Companies are concerned about malicious
parties eavesdropping on SIP signaling
information, performing man-in-the-middle
attacks that disrupt service or gaining
unauthorized access to VoIP networks.
RFC 3261 defines mechanisms for providing
increased security for a SIP session.
The most basic level of security, required to
be implemented by all SIP user agents and
SIP proxy servers, is Message Digest (MD5)
authentication. This provides a basic level
of authentication challenge between a SIP
proxy server and SIP user agent. At the other
end of the spectrum, Secure Multipurpose
Internet Mail Extensions (S/MIME) can be
implemented to encrypt data directly within
SIP messages.
SIP support for S/MIME has not been as
widely deployed as HTTP because of the
required public-key infrastructure support
and the added complexity of managing the
security certificates. Secure SIP, running SIP
over TLS on a hop-by-hop basis, provides a
more comprehensive level of security than
that of basic MD5 authentication, without the
additional overhead imposed by S/MIME.
One key difference between the SIP and
HTTP protocols is that a SIP request may
travel across several hops before reaching
its destination. Running SIP over TLS can
provide secure connections on a hop-by-hop
basis.
For Secure SIP communications, RFC 3261
defines the SIPS Uniform Resource Identifier
(URI), used as HTTPS is used for secure
HTTP connections. The SIPS URI ensures that
SIP over TLS is used between each pair of
hops to validate and secure the connection,
and provide a secure endpoint-to-endpoint
connection.
In a Secure SIP session, the SIP user
agent client contacts the SIP proxy server
requesting a TLS session.This SIP proxy server
responds with a public certificate and the SIP
user agent then validates the certificate. Next,
the SIP user agent and the SIP proxy server
exchange session keys to encrypt or decrypt
data for a given session. From this point, the
SIP proxy server contacts the next hop and
similarly negotiates a TLS session, ensuring
that SIP over TLS is used end-to-end.
One might ask why a security protocol such
as IPsec is not used for a direct, secure, endto-end connection between SIP endpoints.
Because IPsec encrypts data end-to-end, the
SIP proxy servers between the SIP endpoints
would not be able to interpret and modify
required information in the SIP messages. TLS
is a lighter-weight and more easily managed
protocol than IPsec,and thus more appropriate
for SIP-based VoIP endpoints, which are
often processing and resource constrained.
The security mechanism between SIP proxy
servers within a network may use TLS, IPsec
or other security mechanisms, as long as the
information is decrypted at each hop.
Secure SIP is an optional item for SIP user
agents, but more SIP-based VoIP endpoints
provide it.VoIP network administrators should
take a look at implementing this technology
within their SIP-based networks to gain from
the added level of security that Secure SIP
can provide.
Executive Guide 31
EXECUTIVE GUIDE
VoIP security
Back to TOC
Researchers seek to save
VoIP from security threats
NSF awards big bucks to investigate
voice spam, other attacks.
By Bob Brown, Network World
With VoIP starting to live up to some of the hype, university
researchers are looking to ensure that the technology’s
momentum in corporate and residential markets won’t be
ruined by myriad security threats.
The National Science Foundation this week said it has
issued $600,000 to the University of North Texas to spearhead
development of a multi-university test bed to study VoIP security.
Other participants are Columbia University, Purdue University
and the University of California-Davis.
VoIP spam, denials of service, 911 services and quality of
service will be among the areas targeted for research during the
three-year project. The research will also look at vulnerabilities
that emerge from the integration of VoIP and legacy networks.
The group of schools plans to disseminate its findings widely
to technology developers, academia and others involved in
network convergence.
The project is being led by Ram Dantu, an assistant professor
at the University of North Texas in the Department of Computer
Science and Engineering. Dantu is co-chairman of an upcoming
workshop on VoIP security to be held in Washington, D.C.
VoIP security is an issue that vendors have been tackling as
well. A group of them joined forces last year to form the VoIP
Security Alliance.
Executive Guide 32