macVoIP.com
the web home of Ted Wallingford

Cisco Versus the World
Succeeding with Cisco IP Telephony
from a Customer's Perspective

© Ted Wallingford 2003 - 2004

Table of Contents:

i. Background
1. Inability to perform overhead paging using Cisco SCCP phones.
2. Insecurity of Win32 platform on main Cisco softPBX imposes great overhead.
3. Meet-me paging applications are primitive.
4. Cisco's IP phones are too expensive.
5. Cisco's E911 responder servers add risk to a critical aspect of telephony.
6. The exclusively-distributed approach to telephony switching adds unnecessary failure points.
7. There's no program for 24x7 system monitoring provided by Cisco.
8. There's a hug feature gap between CallManager and CallManager Express, making large system design more difficult.
9. Cisco's legacy of non-support for 802.3af is hurting its customers in the long-term.
10. SIP endpoints can't be supported by the CallManager, making Cisco's softPBX a poor choice for service providers.
ii. Conclusion and Recommendations

1. Inability to perform overhead paging using Cisco phones
In many offices, receptionists and managers use an overhead paging, a technique that broadcasts the voices of the pager through ceiling speakers and telephones. Cisco's SCCP phones don't permit their speakers to be used for broadcasting of over pages. Cisco hasn't made this feature available yet, and there is no plan to do so. Using Cisco CallManager out of the box, users are forced to give up their
conventional overhead paging feature.

There are two ways around this problem: One is to place an overhead ceiling speaker in every office and pull a speaker cable to it, thereby eliminating the need to use the phones for overhead paging. This is a wasteful method (think of all the overhead amplifiers and ceiling-tile removal!) that is counterproductive to the idea of using Cisco phones, or even VoIP, at all.

The second way is a solution proposed by Cisco as an added-cost option to be implemented by a reseller: the addition of a custom-made XML application on each SCCP phone that will allow synchronization of paging zones between the overhead speakers in the hallways, vestibules, and shop areas with the SCCP phones themselves. The approach uses IP multicast to simulate a group of synchronized broadcast endpoints. The net effect of such an application would be that the pager's voice could be heard simultaneously on both types of endpoints (speakers and phones).

This functionality exists in Avaya Communication Manager and in Nortel
Meridian out of the box.

Cisco's Response: When confronted with this, Cisco suggested implementing the third-party XML application, which is delivered via TFP and enabled in CallManager. So, supporting this feature, while not exactly a bear, isn't a seamless support function, and is therefore a turn-off to integration-obsessed implementers like myself.