PBX Info :: Your Free PBX, PABX and Telephone Information Resource - View Single Post - IP Telephony;what you might want to know before buying Cisco
View Single Post
Old 01-01-2004, 09:19 PM   #1 (permalink)
Anonymous
Junior Member

Activity Longevity
0/20 20/20
Today Posts
0/0 ssssss289
Rep Power: 39Anonymous is on a distinguished road
Found a good review of Cisco's IP Solution:

Quote:
One of my field techs recently attended the Cisco Call Manager training
course and wrote the following summarization, which I found interesting
and thought others might like to read, to wit:

I just returned from a week long training course on the Cisco CallManager
and thought I'd share some of what I learned. Condensing five days worth
of class notes, manuals, and labs down to a brief email forces me to leave
out and/or gloss over a lot of details, so if anyone wants more info an
anything below, just let me know.

Notes from class
One thing I quickly discovered is that the CallManager is much more
complex than I had previously believed. The CallManager is a group of
software apps running on an SQL server platform. For redundant operation
(to match the redundancy we already have) a second server is required, and
although the CallManager license includes a voicemail application named
Unity, it requires yet another server of it's own. So, for a basic
CallManager install, we'll need a minimum of three new servers and only
Cisco approved server hardware may be used. The CallManager software will
not even load on unapproved servers. An important point- the CallManager
load includes a Cisco customized version of Windows 2000 Server, which
means we will not even be able to run our standard "corporate load" on
these servers. Say what you will, I think our IT guys are going to have
kittens.

As far as features go, several things we can do with our existing PBX can
also be done on the CallManager, but the user interface is very different
and somewhat limited. I was most disappointed by the user interface at the
telephone, it's actually less user friendly than the Mitel phones we have
now. Although the IP phones have a large, customizable, built-in display,
Cisco really isn't using it to it's full potential.

Installation and programming of the CallManager itself isn't too different
from the traditional Mitel PBX currently in use in our office today. It
has a different command structure, but uses similar concepts and
techniques for creating trunks, pools, routes, etc.

From the standpoint of day-to-day system administration, programming, and
maintenance, I expect the CallManager to be a noticeable **increase** in
workload over the existing PBX system. Being PC server-based also means
keeping up with things like OS patches, virus definition files, Cisco
software patches, backups, etc. Also, with the IP phones being integrated
onto the data network, troubleshooting a user complaint becomes
tremendously more complicated than the traditional analog telephone. Is
the problem in the user's phone, cabling, router, network path,
CallManager, or configuration? Is the problem caused by network overload?
Is it a Quality Of Service (QoS) issue in the router configuration? I
could go on, but you get the idea. The person responsible for maintaining
the CallManager will need to be equally proficient at telephony *AND*
networking. A good understanding of Microsoft SQL Server might be handy as
well.

There are, of course, several advantages to the CallManager system. Here
are just a few.

Plug and play phones- Once the CallManager is operational, any user can
plug an IP phone almost anywhere on our network and have access. No
special cabling or KSU configuration changes need to be made for user
relocations. Changing cubicles, desks, etc, is a simple matter of
unplugging your phone, taking it to your new work location and plugging
it in. Absolutely nothing has to be done in the CallManager. No cabling
or reprogramming needs to be done. Of course this Plug and Play capability
would be there regardless of what VOIP system we choose, so this isn't
something unique to Cisco. That's the real beauty of any IP based
telephony system; the IP phones operation can be independent from it's
physical location.

Customized phone displays- The Cisco IP telephone is basically a small,
low power PC and it can run custom applications. For example, we could
place a link on the phone to pull up the latest weather, stock quotes,
news feeds, etc. Arguably all "gee-whiz" stuff, but it's there anyway.

Wireless- Wireless IP phones are available from Cisco (and others as well)
that provide all the functionality of a desktop IP phone and will work on
our existing wireless network. Theoretically, a user in our office with a
wireless IP phone can stick the phone in their pocket, drive to the
Corporate office, or any of the other field offices and use the phone
exactly as they would here. I say "theoretically" because while that
functionality is *possible*, it still has to be configured in the
CallManager and on our network routers. Proper (and extensive) network
configuration will be crucial when implementing features like phone
portability.

Video conference- Soon to be released is a new Cisco IP phone that has
built in video conferencing. (Mitel has this capability too). The camera
is already built into the phone. This is a new feature not yet
implemented, but Cisco does have test phones currently undergoing field
trials and expects to release this feature in the next major CallManager
upgrade next year. At this time, I'm not sure if/how the Cisco video
phones will integrate into our existing Polycom video conferencing system,
but I do expect them to be compatible since both devices support the same
protocol and Polycom is the manufacturer of Cisco's IP phones.

Voice Conference phones- Cisco does sell an IP version of the Polycom
conference phones (bat phones) that we are currently using. (So does
Mitel.)

User login- Just as PC network users can now log onto another persons PC
to access their own email account, so too will users be able to log onto
any IP telephone and the phone will reconfigure itself to be their
phone. The users lines, extensions, and any customized buttons will now
be on the local phone just as they would be at that users desk. (This same
feature is also available in the Mitel IP system and is known there as
"Hotdesking". The functionality is quite similar to the way an ACD agent
can log in and out of any ACD phone.)

Notes for further research:
Cisco Unity voicemail- Still a lot of questions about integrating our
Mitel PBX into the Unity voicemail. Need to talk to Cisco rep about this.
The interface appears proprietary.

Security- Being Microsoft server based means the CallManager is open to
the same worms, viruses, Denial-Of-Service attacks, etc as all other
Windows based PCs. For security, Cisco recommends creating a separate
Firewall and VLAN for the exclusive use of IP telephones and gateways. An
additional firewall of course translates into another server. How does
this fit into our existing network address scheme?

DN plan- Need to create/integrate the IP phones DN's into our existing
numbering plan.

Bandwidth- Need to determine the number of DN's and Gateways required at
each site to estimate the impact on existing bandwidth. Looks to be
substantial.

AC Power & space- Adding additional servers to our local office Network
Operations Center may require upgrades to the UPS systems. Also need to
consider the mounting space required by these servers in a room already
cramped for space.

IP Telephony network design- Big subject, including- Distributed network
with ITS running in field routers, or central network with all field
devices/gateways reporting directly to CallManager? Different hardware
to achieve similar results, such as router internal FXS ports or
external ATA boxes. Several different ways to implement the CallManager
servers- individual or all-in-one blade servers?

Field hardware- Switches- Existing 1900 series Cisco switches can
transport IP Telephony, but do not provide phone power or optimum VLAN,
QoS, etc, for voice quality.

Routers- Existing 2500 routers at mainline field offices will need
to be replaced to support IP telephony. No expansion slots for
FXO/FXS ports and limited feature set for voice and QoS. Voice IOS loads
require more RAM and faster processors.

New hardware- need to check with Cisco on availability of new gateway
devices, such as high density FXO ports.

Alternatives to CallManager- Cisco is not the only game in town with IP
phones. In the very near future, the Corporate office Telecom Dept will be
installing a new Mitel IP Telephony system giving me the opportunity to
compare Mitel's package to CallManager.

911- The fact that an IP phone can be anywhere on the network requires
special consideration from the standpoint of emergency 911 calls. 911
calls need to be routed to the correct regional 911 response center. In
the corporate office, where they are sending physical station location
info to the PSAP, this freedom could become a nightmare to administer.
Another database/another server???

Cisco has a solution for this, but it cannot communicate station location
info to the PSAP and it too requires installation of yet another server
(if you've been counting, we're up to 5, and possibly as many as 6 servers
now).

Bottom line is it looks like letting Cisco get their foot in our door on
the voice side of the house is going to have the net result of migrating
our traditionally "five-nines-reliable" voice communications system over
to a cluster of PC based servers, each running a non-standard, proprietary
mutation of Microsoft Windows 2000.

I think it's going to behoove us to go very slowly and think this thing
all the way through before deciding to do anything. The obvious pros seem
to come with a lot of baggage.
Anonymous is offline   sendpm.gif Reply With Quote