Hello, It's IP Telephony
IP telephony is no longer just for companies that do a lot of geographically disparate work. Our columnist gives you the long-distance view.
- By Bill Heldman
- November 01, 2002
Years ago I remember being very interested in an issue of Computer
. The cover showed a yellow brick road with text that shouted
something like "The holy grail has finally arrived!"
What they were talking about was the advent of Voice Over IP (VoIP),
a new way of packetizing telephone calls and sending them out over IP
networks. In a large environment, VoIP could potentially have been the
Why? Because if you work for a company that has a lot of geographically
distant campuses (e.g. New York, Dallas, Tokyo, Hamburg) and there's a
lot of calling going on between these campuses, the long distance (LD)
charges can become enormous. Not to mention that there's a ton of overhead
in maintaining the Post Branch Exchange (PBX), switch or key system equipment
needed to handle the phone systems because there's a lot of proprietary
gear to worry about and you need people who understand the gear and can
keep up with the required changes. But if your employees could make phone
calls over the Internet, then, with the exception of setting up some special
telephones and making sure you had robust Internet connections, the freight
would be very low cost to handle the calls.
Sounds logical, right? Problem was that in those early days, not many
companies manufactured VoIP gear; the quality of the calls was pretty
poor and as soon as the big telcos got wind of the idea, they began making
sounds like they'd tack on a surcharge to companies who tried such a thing.
On top of that, lots of companies had already negotiated long-term lease
and maintenance agreements with their telcos in order to provide not only
long distance service, but also the necessary equipment to make a functional
But the overall idea is still fundamentally sound. For example, consider
the average corporate network today. You have a data network and a telephony
network, the two of which do not talk with one another (see Figure 1).
|Figure 1. Same company, two different networks.
There are some places in this model where there is room for better economic
design. For example, if we were able to consolidate the two networks,
we wouldn't need as many technical people to handle the operation. Although
we'd still need some telephony people-folks who understand how telephone
systems operate, especially the user database-we wouldn't need as many,
instead offloading a lot of work to the server and network admins instead.
Also we could narrow down the amount of network protocols in use and we
could save money on hardware and cabling costs.
But there is a problem-applications. The PBXs and key systems have great
voicemail programs and other applications such as unified messaging (being
able to get your e-mail through your voice mail or vice-versa) that were
not readily available in the early days of VoIP.
Suppose that we wanted to mimic the way that the phone systems work in
order to get everything onto one network. What do we need? There are several
things on the list that a conventional PBX has that we'd have to bring
with us to the table.
- Switch fabric
- Some sort of mechanism to talk to the telco (called the "carrier"
in the biz). This mechanism is referred to as a "voice gateway."
- Applications (such as voicemail)
- Power supplies
If we were to come up with a network infrastructure that handled the
switching and connections to the telco we'd be able to take care of items
1 and 2 without a PBX. Then, if we could invent an application or two
we could pick up item 3. Also, we'd have to invent the telephones that
would work on our new network system and finally we'd move the whole power
supply thing onto UPS equipment. If we could do all this, we could shuck
our PBX and key system gear (or, in some cases, keep it in the background
to assist with other areas that have not yet converted). We'd dramatically
downsize our costs in terms of both physical plant and human resources.
Figure 2 shows how we've taken the guts of the PBX and offloaded its functionality
in other ways.
In Figure 2 you can see that using IP telephony products we can emulate
the functionality of the PBX. Instead of the PBX switch fabric, we use
the network infrastructure switches instead. Note that the switch ports
have to be specially powered to support voice traffic. Also we can slip
a carrier card, such as a T1 or PRI ISDN board into the routers in order
to talk to the carrier. Our conventional server room UPS gear takes the
place of the PBX UPS. Our applications are supplied by application servers
and the phone sets we use are a purchased item that is specially designed
for IP telephony.
|Figure 2. PBX functionality can be offloaded
to a PBX emulator; devices must support voice traffic.
Taking the Implementation Call
With some judicious planning, good project management, the advice
and counsel of vendors and consultants who've done this before and, of
course, a healthy budget, you can set up an IP telephony system that will
allow you to eventually unplug your expensive PBX equipment and/or augment
it until that day. Your telephony folks will continue to set up the dialing
plan and work as they might normally do, although their PBX green screens
will be replaced with Windows-based interfaces and their method of doing
things will be drag-and-drop instead of command line. Your server admins
will handle the server farm, your internetworking folks will continue
to manage the routers and switchgear and your apps team will work with
any specialized applications.
IP telephony is very standards-driven and good quality gear, such as
that sold by Cisco, travels in the standards circuit supporting such well-known
standards as C++, XML, Clustering TAPI and JTAPI, to name a few.
An IP telephony system supports good convergence of video, voice and
data. Your server farm and network infrastructure can handle the voice
load as well as data and any video work that you do (such as streaming
video for online classes).
Another issue that's of concern to telephony folks is that of Customer
Resource Management (CRM), or its brand new successor Electronic Customer
Resource Management (e-CRM). If you work for a company that has call-centers,
where customers can call in for support, to order things, to get advice
on their account and other such activities, then you're probably already
familiar with CRM solutions. A good IP telephony environment should easily
integrate with big CRM software providers such as Siebel and should support
home-grown add-ons to CRM environments by allowing the use of snap-ins
created with Visual Basic or Visual C++.
Call-center employees experience what are called "screen pops." The idea
is that a screen pops up with information about a customer's account and
order status. You can customize screen pops for a variety of things, and
they're very effective in helping call-center folks quickly and efficiently
deal with customers. A good quality IP telephony system should support
screen pop capability. (The Cisco system screen pops can be built with
a screen-pop wizard.)
Call for Help
The key to developing a good quality IP telephony solution is to
seek wise counsel regarding such an effort. You first must get buy-in
by decision-makers at high levels because the change to IP telephony can
heavily impact lots of functional areas and chew up quite a few resources
in its implementation.
Accomplish that big task and you can go to the next step: Getting all
the stakeholders in a room to plan the design and deployment. Do this
at a high level, thinking not in terms of gear at this point, but in terms
of what you hope to accomplish. What is your mission? Is it to get rid
of PBX equipment?
Next bring in a vendor. In the City of Denver's case, we chose Cisco
gear through a vendor bidding process to find the best design and lowest
cost implementation. The Cisco equipment is very high quality, comes with
the R&D investment behind it so that you know it's going to work and is
Finally, implement and deploy. Plan on several months of up-front work
before you get to this stage and several more weeks as the stuff gets
installed and set up. While this isn't rocket science, it's also not the
easiest thing in the world to do and getting it right takes time. You'll
need a parallel operation plan for your existing phone system while you
set up the new system.
Can You Hear Me Now?
What's in it for you? Well IP telephony brings with it a new paradigm.
First of all, you don't have to worry about a second set of cabling for
your phones. Everything runs through the Ethernet system. In fact, in
the City's case, the patch cable comes from the workstation jack to the
phone set, then another patch cable goes out of the phone and into the
PC! We use dual DHCP scopes, one to handle the phones, one to handle the
Also, if you go with Cisco gear, you'll have applications servers. These
can be set up to handle a variety of (either bundled or separately purchased)
applications such as unified messaging. The bare bones of the system allows
for a call plan and the Web attendant so admins can monitor and maintain
from anywhere that they can get to the private network.
The phone sets are clear in terms of their sound quality, and programmable
for a variety of custom features.
The systems are able to easily interoperate with conventional PBX equipment
With an IP Telephony system you can support a feature called Quality
of Service (QoS), dedicating portions of bandwidth to certain kinds of
activity. You may, for example, desire to give a higher priority to voice
traffic than to data.
IP telephony, no longer just VoIP, is the thing to think about when considering
a telephony system upgrade for your company.