IP PBX Guide - Tech Republic PDF

TechRepublic Resource Guide: IP-PBX Technical Strategies
TechRepublic Resource Guide

IP-PBX Technical Strategies
Contents
Understanding IP private branch exchange (PBX)2

IP PBX systems are the next generation of Internet-based PBX communications. Here is an
overview of IP PBX systems and how you can easily make the switch.
Deploying VoIP: Weigh the pros and cons of convergence...4

To converge or not to converge -- that is the question. When deploying VoIP in your
organization, should you combine data and voice networks, or should you keep them separate?
Four obstacles to implementing VoIP..8

While VoIP's popularity continues to grow, it still has some obstacles to overcome before it
becomes ubiquitous in corporate environments.
10+ priorities for testing critical systems..11

Testing is essential to make sure that systems function as expected, but the process can be
complex and overwhelming. These testing strategies, which can be applied to any IT project,
will help you focus on whats important and make your installation and upgrades go smoothly.
Sponsored by:
Page 1 of 13
Copyright 2008 CBS Interactive, Inc. All rights reserved.
For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001-6240-0.html
Understanding IP private branch exchange (PBX)

To provide the cost savings of IP-based phone calls for small companies, a couple of
VoIP lines with a business plan from a low-cost provider such as Vonage or Lingo will
suffice. But as the organization grows, users will want to look at more sophisticated
options, the same as if using a public switched telephone network (PSTN).
Medium- to large-sized businesses have long used private branch exchange (PBX)
switchboards to route incoming calls from a number of external lines among a larger
number of internal lines. This saves money because there's no need to have a separate
line for every employee, and makes line sharing more efficient. Most systems in use
today are technically PABX, which means the call routing is automated, rather than
dependent on a human switchboard operator.
According to an article by Robert Poe in VoIP News, major research firms reported that
a majority of PBX systems sold in the first quarter of 2006 were IP-based. Slowly but
surely, companies are moving away from traditional PBXs to IP PBX solutions.
How IP PBX works
To the end user, the IP version of PBX is essentially the same. Under the hood, though,
there's a big difference. The heart of the system is the IP PBX server, which works
somewhat like a proxy server. With a Session Initiation Protocol (SIP)-based system,
the VoIP clients register their SIP addresses with the server, which maintains a
database of all the clients and their addresses. (The VoIP clients can be soft phone
software installed on a computer or self-contained hard phone devices.)
When a user places a call, the PBX server recognizes whether it's an internal or
external call. Internal calls route to the SIP address of the phone or user receiving the
call. External calls route to the VoIP gateway.
The company may have its own VoIP gateway incorporated into the system, or use the
gateway of a VoIP service provider. The purpose of the gateway is to link an IP system
with the PSTN. VoIP gateways can connect either to analog phone lines or to digital
lines (ISDN or standard multiplex T-carrier lines).
The gateway device can take the form of a dedicated appliance, or as an expansion
card in the server. Like other gateway devices, it has two or more ports to allow it to
span multiple networks. In this case, one connection is to the IP network and one is to
the PSTN. A virtual PBX refers to a card and PBX software installed on an existing PC.
Page 2 of 13
Traditional PSTN PBX lines connect to the VoIP network (or to the Internet) using an
FSX gateway. Or, going in the other direction, PSTN phone lines may connect to an IP
PBX with a foreign exchange office (FXO) gateway.
IP Centrex is a service model whereby the VoIP provider owns and hosts the PBX
equipment. Hosted IP PBX solutions are turnkey solutions that don't require
organizations to have personnel on staff capable of managing the system.
Advantages of IP PBX
Along with the cost savings of VoIP, users can get some extra features with IP PBX that
don't typically come with a traditional PBX system. PBX systems support caller ID,
three-way calling, call forwarding, voice mail, and similar features that business phone
users take for granted. The nice thing about IP-based systems is that users' voicemail
messages can be forwarded to their e-mail inboxes, so they not only get instant
notification that a call has come in, but can also play the messages from their
computers or handheld devices.
Other sophisticated automated features are available, too. "Smart" systems can be set
up to route calls differently depending on the caller ID information. Thus, a user could
have calls from his or her boss forwarded directly to a cell phone, while calls from that
pesky sales rep automatically go to voice mail.
Businesses also find the monitoring and reporting capabilities of IP systems useful in
maintaining an audit trail and keeping up with costs. The system can track usage by
phone number/SIP address, monitor performance information and Quality of Service
(QoS), and detect security breaches.
Why not IP PBX?
What are the disadvantages of transitioning to an IP-based PBX system? There can be
a large upfront cost. In addition to the IP PBX hardware and/or software, IP phones may
need to replace traditional handsetsor adapters used to allow them on the VoIP
network.
Even worse, if the IP network is an outdated one, an upgrade to the entire network may
be necessary to support high quality voice transmissions, which require more bandwidth
than many data transmissions.
Finally, implementing an IP PBX system on-site (as opposed to using a hosted service)
requires personnel with knowledge and experience in VoIP. It's an IT specialty area with
which many systems administrators are unfamiliar.
Page 3 of 13
Deploying VoIP: Weigh the pros and cons of convergence

As the lower cost of calls -- particularly long distance and international calls -- attracts
more and more companies, VoIP's popularity in the business world continues to grow.
According to iLocus Research's annual report on the VoIP industry (which the company
has been tracking since the late 1990s), the IP PBX market grew 52 percent from 2005
to 2006, and the number of worldwide voice over broadband (VoBB) subscribers (both
consumer and business) almost doubled.
Those growth statistics are impressive, but a look at actual percentages tells a different
story. Less than half of businesses use VoIP and less than a quarter of small
businesses do so. If cost savings are so dramatic, why haven't more companies -especially small ones that don't have millions invested in their traditional phone systems
-- made the switch?
In 2006, VoIP Magazine predicted that half of all small businesses and two-thirds of
large businesses would be using VoIP by 2010 -- although not necessarily exclusively
for all their telecommunications needs. To get there, VoIP providers are going to have to
overcome the obstacles that have so far prevented many businesses from cutting the
telco cord and moving to IP-based phone services. Let's explore some of these
obstacles.
Reliability concerns
The performance of the long-established public switched telephone network (PSTN) has
"spoiled" telephone users. While consumers and employees accept that computers
sometimes go down, their expectations of the phone system are much higher. When
they pick up the phone, they expect to get a dial tone. Users won't tolerate less than
rock-solid reliability from their telephone systems.
Companies depend on the phones to stay in contact with customers, partners, and
vendors -- as well as within the company for communication between employees. A
phone outage can bring business to a halt -- or, at the least, slow it down considerably
and cost the company big bucks.
VoIP is far more reliable than it was just a few years ago. However, there's still a
perception of unreliability that providers must overcome before cautious managers will
take the plunge.
And there's another aspect to reliability. The regular phone jacks in a building don't
require electric service to work (although equipment such as PBX does). That means
you can still have phone service during a power outage.
Page 4 of 13
VoIP depends on both electrical power and Internet service. Interruption of either means
losing phone service. You can ameliorate the problem by having redundant Internet
connections and power backup such as a generator, but this adds to the cost.
Network quality of service
VoIP is far more sensitive to network "glitches" than data transmission is. If the network
drops data packets, it just resends them. If the dropped packet results in an e-mail
delayed by a few minutes, users likely won't even notice.
But if delays in transmission or dropped packets cause a disrupted phone call, you can
bet the call participants will notice -- and complain. The data transmission process is
much more transparent; because phone calls are real-time communications, problems
are "in the face" of the users.
IP networks are subject to many variables, including:
* Packet loss due to network congestion or corruption of the data
* Variation in the amount of delay of packet delivery, which can result in poor voice
quality
* Packets arriving out of sequence, which can result in discarded packets and cause
more delay and disruption
In addition, the analog-to-digital conversion process can affect VoIP call quality, causing
users to experience unpleasant distortion or echo effects. Another culprit is signal level
problems, which can cause excessive background noise that interferes with
conversations.
To help prevent such problems, the IP network must support quality-of-service (QoS)
mechanisms that allow administrators to give priority to VoIP packets. This means a
VoIP network is more trouble to manage than a data network, and it requires a higher
level of expertise -- or at least an additional skill set -- on the part of network
administrators.
VoIP monitoring and management solutions are available that make it easier to optimize
voice services, but that adds to the cost of deployment. It also negates some of the cost
savings that motivate the move to VoIP in the first place.
Page 5 of 13
Complexity and confusion

The complexity and unfamiliar terrain of VoIP communications presents another big
obstacle for many companies. Network administrators well-versed in running a data
network may not know much about how VoIP works, what equipment is necessary, or
how to set up and maintain that equipment.
In addition, VoIP terminology quickly gets confusing -- media gateways, analog
telephone adapter (ATA), audio response unit (ARU), interactive voice response (IVR),
etc. Company managers and IT personnel hear about different VoIP protocols -- H.323,
SIP, IAX -- and don't understand the differences or know which one they need.
Already overworked IT staffs may not be eager to undertake the task of learning a
whole new specialty nor the added burden of ongoing maintenance of the components
of a VoIP system. They may not be sure how to integrate the VoIP network into the
existing data network.
Of course, there are answers to these problems. Consultants with the requisite
knowledge can help set up a VoIP network, or companies can use hosted VoIP services
to reduce both the complication and the upfront expenses of buying VoIP servers.
However, once again, this ups the price tag of going to VoIP and eats into the cost
savings that are one of VoIP's main advantages.
Security
Finally, reports on the security vulnerabilities of IP networks have bombarded
companies, and the risk of intercepted calls and eavesdropping are a concern. In
addition, providing another layer of vulnerability to a data network integrated with the
VoIP network is also a worry.
While malicious users can tap traditional telephones, it's a fairly difficult process that
usually requires physical access -- at least for anyone other than a government agency.
Traditional phone communications travel over dedicated circuits controlled by one entity
-- the phone company. But when VoIP packets go out there into the "Internet cloud,"
they go through numerous routers and servers at many different points.
Encryption and other security mechanisms can make VoIP as secure or even more
secure than PSTN. But once again, it's perception that matters. (And, of course, extra
security mechanisms mean extra cost.)
Summary
VoIP is gaining ground steadily. However, before it becomes ubiquitous, the technology
needs to overcome some obstacles. VoIP providers must not only address the problems
Page 6 of 13
of reliability and quality of service, but they must also reduce the complexity and
confusion inherent in implementing VoIP and address security concerns. And, at the
same time, they must keep VoIP costs lower than the costs associated with traditional
phone service.
Page 7 of 13
Four obstacles to implementing VoIP

If your organization is currently contemplating a VoIP implementation, one big decision
you'll have to make is whether to keep the VoIP network separate from the data network
or if convergence is the way to go. Convergence is one of the popular IT buzzwords
right now, and the connotation is generally positive.
While there are certainly advantages to "putting it all together," there are also good
reasons to keep the networks separated. Let's weigh the pros and cons of each option.
Should you deploy VoIP on an existing network?
There are obvious cost benefits to deploying VoIP on an existing network and using the
same Internet connection used for data. However, prior to deploying VoIP, your
organization needs to make an assessment of the network to determine how well it will
support the addition of VoIP.
Network issues such as packet loss, latency, and jitter (i.e., variation in time between
the arrival of packets) impact VoIP call quality much more than they affect data transfer.
That's why it's important to know the extent of these factors on your network beforehand
rather than making assumptions and being subject to unpleasant surprises later.
More bandwidth is often the solution to network problems, but just adding more
bandwidth doesn't necessarily solve VoIP problems. Remember, it's the quality of the
connection -- not the speed -- that poses many of the problems with dropped calls, poor
voice quality, and so forth. In fact, because of its sensitivity, VoIP can be the first
indicator of network problems you didn't know you had.
A number of vendors offer network testing products and services that specialize in
conducting pre-deployment baseline assessments to simulate voice traffic on the
network. These offerings can help determine whether deficiencies exist that you'll need
to address before deploying VoIP. Here are three examples:
* PROGNOSIS
* NetAlly LifeCycle Manager
* VoIP Supply VoIP Network Assessment
The assessment may show that your network is ready for VoIP or that you need to
change a few key components. In some cases, companies find that they need to
completely redesign the network to support VoIP.
Page 8 of 13
Along with determining whether the network can handle the extra bandwidth needed for
VoIP (which can be considerable in a large company with many employees who make a
lot of calls), you need to ensure that the network supports Quality of Service (QoS). Are
your network's routers and switches VoIP-compatible? Do you need software updates
for network devices to use QoS effectively?
Remember that users won't be as tolerant of outages or problems with their telephone
service as they are of data network downtime. PSTN performance has trained users to
expect almost 100 percent reliability from phone systems.
A converged network allows you to manage voice and data communications as one,
and it can save equipment and personnel costs -- if you do it right. It also makes for
easier deployment of unified communications; users can access messages of all types - including e-mail, voice mail, faxes, and so forth -- from a single repository through a
single interface. You may enjoy a greater return on investment by using much of your
equipment for both voice and data -- and have fewer devices to maintain and manage.
Or should you maintain separate networks?
The other option is to deploy a separate network dedicated to VoIP components. You
can either create an entirely separate physical network, or you can use virtual local area
network (VLAN) technology to logically separate the networks.
The primary reason for separating networks is security. VoIP is vulnerable to many of
the same attacks, intrusions, and other security threats as data networks. If you have
VoIP and data traffic combined on the same network, an attack on one can bring down
the other.
It's annoying enough to users if their e-mail is inaccessible because the network is down
due to a virus or denial-of-service (DoS) attack. But if both e-mail and telephone
communications are unavailable, business may come to a halt, and the company loses
money.
Regulatory compliance issues may also come into play. If you're in a business in which
industry or government mandate determines how to secure the data on your network,
separating the networks provides higher security and thus a greater level of compliance.
Bandwidth considerations provide another reason for separating voice and data
networks. If your existing network doesn't have the bandwidth to support VoIP, installing
a separate network for VoIP is one solution. You have more control over the quality of
service, and you don't have to worry about other applications getting priority and
causing problems for VoIP users. In fact, Cisco and other vendors recommend VLANs
to separate VoIP and data in its best practices for securing VoIP networks.
Page 9 of 13
However, separating the networks -- whether completely or by setting up VLANs -- can

be expensive, and there are other alternatives to secure voice traffic, such as
encryption. And with separate networks, you may have wasted bandwidth on both.
Summary
To converge or not to converge, that is the question. But the answer isn't as clear-cut as
we'd like. There are many advantages to convergence, and it appears to be the wave of
the future, especially in budget-conscious environments.
However, separating voice and data transmissions can provide better security for both.
In addition, it may be a more cost-effective alternative -- at least in the short run -- if the
existing network would require a complete redesign to support VoIP.
A single network can make management and troubleshooting easier if IT personnel
have the proper training
Page 10 of 13
10+ priorities for testing critical systems

IT folks grumble at arduous inventories of test plans and scenarios, but the fact is that
testing should be made a priority for critical systems. So what can we do to make
testing effective and through? Here are 10 things to stress for your test environments to
save surprises and present credible test results.
#1: Make your test environment represent the live environment
Having a test environment thats quite different from the real environment is not
effective. A good example is a Windows Active Directory domain. A domain with highly
customized Group Policy configurations, complex DNS configurations, multiple domain
trusts, many group memberships, and a large number of account objects is not
representative of a separate domain that is empty and has no real configuration.
Virtualization is a good option here: You can promote a domain controller on a virtual
machine, move it to an isolated network for the testing, and then remove it from the live
domain.
#2: Have multiple disciplines of the test achieve the same result
In outlining the steps of a test, identify components that can be tested two different ways
to obtain the same result. For example, if you are considering going to a new version of
Windows Active directory, within the test environment perform an Active Directory
authoritative restore and a system backup restore to ensure that they both bring the
system back to a workable state. This can be beneficial if, in the real world, one
mechanism fails. Another strategy is to have one person prepare the test plan and
another person implement to ensure that the plan is clear and that nothing is taken for
granted or assumed in the testing.
#3: Test the rollback!
For test plans that revolve around an upgrade or enhancement to an existing system,
you should test the reversion process. You can also test this multiple ways depending
on the context of the upgrade. Some strategies include removing a hard drive in RAID 1
configurations (the removed hard drive would be unchanged), a full restore from a
backup, uninstall functionality of the upgrade, database backups, or simply using new
equipment only, with the current system turned off during the upgrade.
#4: Dont proceed without the testing
Page 11 of 13
If situations arise that cut into the test phase, take a stance that the testing is an
important part of the overall project. Depending on the situation, this may be a difficult
case to make or it may have political consequences. If it boils down to someone else
deciding you cant do the testing but youll have to take the blame if it does not work,
raise the red flag!
#5: Remember the goal of testing: No surprises during a go-live
Surprises are the last thing you want during a go-live. Thorough (representative) testing
helps prevent any learning experiences when the new system is in use. Of course
testing cant be 100 percent like the actual environment, so there is always the risk of
something new arising. For example, if you are testing a new version of a software
product with a simple security model that may have every user configured with more
permissions than required, when you go live, the security model will need adjustments
to meet operational requirements. This can cost valuable time and introduce risk.
Thorough testing would have a documented procedure for the security configuration or
scripts to run to configure the live system as used in the test environment.
#6: Use pre-existing resources and testing standards
We may not all be certified testers, but we can leverage existing resources to deliver a
credible test for our IT environments. Some good starting points include the Standard
Performance Evaluation Corporation and a quick Internet search for sample test plans.
If you do not have rigid requirements for testing, you will have some freedom in
developing your test plan. Be sure to give the plan much thought and be
comprehensive. The Sara Ford blog on MSDN gives a good perspective on how to
develop a test specification, which is slightly different from a test plan.
#7: Assume nothing
Sure, your testing will provide an exercise in the rudimentary tasks associated with your
environment but some small pieces of functionality may be affected by an upgrade.
Depending on your project, this can include extra options, permissions changes, and log
file changes. This can come into play if you have built monitoring around a systems log
file behavior. If there is slight a change in the way the log is written after an upgrade, the
monitoring system may need a review. By going through the steps, even for the
elementary tasks, the risk of little things getting in the way with the project as a whole
are reduced.
#8: Use project management to coordinate testing
Having project management and a management sponsor will give credibility to your
testing. It will allow other areas in the organization to understand that the testing is
Page 12 of 13
essential, and your management will have a better idea of the testing steps. Simply
saying that youre testing the new version of XYZ is not as effective as engaging the
project plan with management, sharing the status of the test plan, and collaborating on
the testing with multiple parties. Ensure that the test plan document is available to the
project management or management sponsor for an ongoing view into the progress;
this will enable them to have a good idea of the work and challenges related to the
testing you have laid out.
#9: Ensure that test failures are repeatable
Almost every test plan will incur some part of a test that results in a failure. With test
systems, many administrators may be testing at once or changing configuration, which
may effect the testing. Should a failure occur within the testing, note it and attempt to
repeat it. Further, seek other testers to perform the test to see if it fails for them as well.
If the failure or issue is critical to the overall success of the project, engage support
resources of the product to identify the issue if possible. Depending on the scope of the
failure, the overall project may not need to be stopped, and this identification process
can get expectations in line to the end-state.
#10: Test with a different environment
If youre making the effort to provide quality testing, think ahead to some of the
challenges you may face. This may include lesser systems running more roles, doubling
or halving your workload, integrating another company, or changing a core part of your
IT environment. This may be perceived as scope creep in the test process, but if you
engage project management and your direct management, you may be able to make
the case to allocate time and resources to test other scenarios.
#11: Hold onto your test environment
If youve gone to all the effort of creating a full test environment, why not hang onto it for
ongoing testing? This could be a test environment that is used to test version updates
and core functionality changes or to provide a training environment. Just be aware that
there may be licensing considerations with a test environment for continued use.
Summary
There are many ways to approach test environments, but incorporating these tips into
creating your testing strategies will help equip you for successful installations and
upgrades.
Page 13 of 13

IP PBX Guide - Tech Republic PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IP PBX Guide - Tech Republic PDF

Uploaded by

Copyright:

Available Formats

TechRepublic Resource Guide: IP-PBX Technical Strategies

TechRepublic Resource Guide

Understanding IP private branch exchange (PBX)2

Deploying VoIP: Weigh the pros and cons of convergence...4

Four obstacles to implementing VoIP..8

10+ priorities for testing critical systems..11

TechRepublic Resource Guide: IP-PBX Technical Strategies

Understanding IP private branch exchange (PBX)

TechRepublic Resource Guide: IP-PBX Technical Strategies

TechRepublic Resource Guide: IP-PBX Technical Strategies

Deploying VoIP: Weigh the pros and cons of convergence

TechRepublic Resource Guide: IP-PBX Technical Strategies

TechRepublic Resource Guide: IP-PBX Technical Strategies

Complexity and confusion

TechRepublic Resource Guide: IP-PBX Technical Strategies

TechRepublic Resource Guide: IP-PBX Technical Strategies

Four obstacles to implementing VoIP

TechRepublic Resource Guide: IP-PBX Technical Strategies

TechRepublic Resource Guide: IP-PBX Technical Strategies

However, separating the networks -- whether completely or by setting up VLANs -- can

TechRepublic Resource Guide: IP-PBX Technical Strategies

10+ priorities for testing critical systems

TechRepublic Resource Guide: IP-PBX Technical Strategies

TechRepublic Resource Guide: IP-PBX Technical Strategies

You might also like