Views

Telecom:IPT:Cisco

Contents

Navigation



Related categories

Asterisk · Nortel · Microsoft · CallCenter · QoS · Monitoring ·


About this page

We apologize for the little information we provide, this page is still under construction. Please stay tuned.
Image:Construction_worker.gif

Cisco IP telephony resources

A Cisco IP Communications solution is based on the AVVID suite of components whose flagship and core is the Cisco CallManager. The primary function of the Call Manager is to provide call routing and signaling services to the other components of the system.

CallManager History

What would eventually become nowaday's CallManager 4.1, 5.x and 6.x, started in 1994 as a point-to-point video product and was redesigned as an IP-based telephony system in 1997. It evolved such as by 2004, CallManager could already support, via multiple clusters, hundreds of thousands of users with a full suite of enterprise-class features.

1994—Multimedia Manager

The application that would become CallManager release 4.1 began in 1994 as Multimedia Manager 1.0. Multimedia Manager was the signaling controller for a point-to-point video product and was developed under HP-UX in the language SDL-88. The "Specification and Description Language" (SDL), the ITU-T Z.100 standard is a graphical and textual language that many ITU-T specifications use to describe their protocols. An SDL system consists of many independent state machines, which communicate with other state machines solely through message passing and are thus object-oriented. Because SDL is specifically designed for the modeling of real-time behavior, it is extremely suitable for modeling behavior of call processing software. Although Multimedia Manager 1.0 was developed in HP-UX, it was intended to run on Microsoft Windows NT 3.51. Each Multimedia Manager server served only as a call signaling source and destination. Multimedia Manager 1.0 managed connections by sending commands to network hubs, which contained the matrix for the video connections. Each hub contained 12 hybrid Ethernet/time-division multiplexing (TDM) ports, each one serving either a PC running videoconferencing software or a sub-hub that managed four PRI interfaces for calls across the PSTN. The hubs could be chained using hybrid Ethernet/TDM trunks. The solution was somewhat hybrid as Multimedia Manager, running on a Microsoft Windows NT Server 3.51, handled the call signaling and media control over IP like a softswitch, but the media connections were still essentially circuit-based in the network hubs.

1997—Selsius-CallManager

Although the Multimedia Manager 1.0 was a great product, by 1997 it was clear that it was not succeeding in the marketplace. Customers were reluctant to replace their Ethernet-only network infrastructure with the hybrid Ethernet/TDM hubs required to switch the bandwidth-hungry video applications. At that point, Multimedia Manager 1.0 changed from a videoconferencing solution to a system designed to route voice calls over an IP network. Unlike the hybrid solution, which required intervening hubs to connect a virtual circuit between endpoints, media signaling traveled over the IP infrastructure directly from station to station. In other words, the system became a packet-switched telephone system and the change required the development of IP phones and IP gateways. The database, which had been a software application running under Windows NT, became a set of web pages connected to a Microsoft Access database. The new interface permitted administrators to modify the network configuration from any remote machine's web browser. The call processing software changed, too. It incorporated new code to control the IP phones and gateways, using the Skinny Client Control Protocol (SCCP) and Skinny Gateway Control Protocol (SGCP) that were invented for this purpose. In addition, the software supported Microsoft NetMeeting, an application that uses the H.323 protocol to support PC-to-PC packet voice calls. At the same time, the call processing software had finally outgrown the SDL development tools. To ensure that the code base could continue to grow, the pure SDL code was ported into a C++ SDL application engine offering same functionality as the previous pure SDL implementation. This was the Selsius-CallManager 1.0, which permitted SCCP station-to-station and station-to-trunk calls, each Selsius-CallManager supporting 200-feature phones with features such as transfer and call forward.

2000—Cisco CallManager Release 3.0

The Selsius CallManager was warmly received by the marketplace and, as by 1998, Selsius-CallManager 2.0 had been released, Cisco Systems, Inc., became interested in the potential of the product. After acquiring the CallManager product as a result of its acquisition of Selsius Systems in 1998, Cisco concentrated on enhancing the product, undertaking a significant design and re-engineering effort to provide both scalability and redundancy to the system. Clustering was introduced, and the SDL engine became the Signal Distribution Layer (SDL) engine, which permits the sending of signals directly from one CallManager to another. A redundancy scheme allowed stations to connect to any CallManager in a cluster and operate as if they were connected to their primary CallManager. Support for Media Gateway Control Protocol (MGCP) was added, as was the Cisco IP Phones 7910, 7940, and 7960, which provided a large display, softkeys (virtual buttons on the phone's display), and access to voice mail, phone settings, network directories, and services. By mid-2000, Cisco CallManager release 3.0 was complete, allowing feature-rich calls between H.323 stations and gateways, MGCP gateways, and SCCP stations and gateways. Each cluster supported up to 10,000 endpoints, and multiple cluster configurations permitted the configuration of up to 100,000 endpoints.

2001 - 2002 — Cisco CallManager Release 3.x

CallManager release 3.1 built on the foundation of CallManager 3.0, adding support for more gateway devices and station devices, enhancements to serviceability, and features. Among the specific enhancements were the following:
  • Music on hold (MOH)
  • Media resource devices available to the cluster, rather than to individual CallManager servers
  • Support for digital interfaces on MGCP gateways
  • Call preservation between IP phones and MGCP gateways on server failure
  • Database support for third-party devices
  • Extension mobility
  • ISDN overlap sending and T1-CAS support in a variety of VoIP gateways
  • Support for Extensible Markup Language (XML) and HTML applications in Cisco IP Phones
  • Support for telephony applications through Telephony Application Programming Interface (TAPI) and Java TAPI (JTAPI) and JTAPI/TAPI call processing redundancy support
  • Scalability improvements, to support up to 20,000 IP phone endpoints per cluster, higher number of simultaneous H.323 calls, and simultaneous connectivity to multiple voice messaging systems
  • Language—Localization of end-user–visible interfaces, such as phones, end-user applications, gateways, and user-accessible configuration pages to U.K. English and many non-English language and tone sets
  • Support for station-oriented analog gateways such as the VG224 and VG248, as well as the Cisco IP Phone 7905
  • Auto-answer at destination IP phone for hands-free intercom service, Automated Alternate Routing (AAR) fallback on PSTN, improved conferencing, transfer, message-waiting functionality.


After many more releases, the CallManager matured in 2004 with the version 4.1 The CallManager servers can be ordered pre-installed from Cisco (Cisco MCS 7815,7825,7835 and 7845 products) or customer-installed on a number of HP and IBM compliant platforms. It runs on a Windows 2000 server platform.

The Cisco VoIP portfolio

The Cisco portfolio of VoIP and IP telephony products varied significantly over the last few years, due to market pressure. Development and support for some earlier, less succesful products, was stopped and here are some examples:
  • The Cisco BTS 10200 Softswitch [1] and the Cisco PGW 2200 Softswitch [2]
  • The Cisco SIP Proxy Server (SPS) [3]
  • The Cisco EGW 2200 Enterprise Gateway [4]


Here is a sample of the current portfolio of Cisco IP telephony products :
  • Cisco CallManager [5] and Cisco CallManager Express [6]
  • Cisco 7900 Series IP Phones [7] including the 7920 VoWLAN phone
  • Cisco IPCC Enterprise Edition [8] and Cisco IPCC Express Edition [9]
  • Cisco MeetingPlace [10]
  • Cisco Unity [11] and Cisco Unity Express [12]
  • Cisco Emergency Responder [13] [14]
  • Cisco Voice Gateways like the VG 200 series [15] or the 2800 ISR [16]
  • Switches with Inline Power (POE), like the Catalyst 6500 [17] or 3750 [18]


The "Express" versions of the CallManager, Unity and IPCC are IOS-based devices implementing a subset of the original product and they were intended as lower-cost IP telephony or contact-center solutions for SME or remote locations. The "Express" line of products might however reach the End of Life/End of Sale (EOL/EOS), due to apparently weak market demand for them, competition from Nortel and Avaya and the launch of the new "integrated" Cisco CallManager 6.0.

The Cisco IP Telephony and multimedia conferencing design blueprints

Compared to some of its competitors, Cisco goes well beyond the marketing literature and provides extremely detailed and useful technical information regarding its products and recommended designs and practices. These are the Cisco Solution Reference Network Design (SRND) documents, some of them covering the IP telephony engineering:
  • Cisco Unified Communications SRND Based on Cisco Unified CallManager 5.x [19]
  • Cisco Unified Communications SRND Based on Cisco Unified CallManager 4.x [20]
  • Cisco Unified CallManager Express Solution Reference Network Design [21]
  • Cisco Unified Contact Center Enterprise 7.x Solution Reference Network Design [22]
  • Cisco IP Contact Center Enterprise Edition Releases 5.0 and 6.0 Solution Reference Network Design [23]
  • Cisco IPCC Express 4.5 Solution Reference Network Design [24]
  • Cisco IPCC Express 4.0 Solution Reference Network Design [25]
  • Cisco Unified Customer Voice Portal (CVP) 4.0 Solution Reference Network Design [26]
  • Cisco Unified MeetingPlace 5.3 Solution Reference Network Design [27]
  • IP Video Telephony Solution Reference Network Design (SRND) for Cisco CallManager 4.1 [28]
  • IP Videoconferencing Solution Reference Network Design [29]


Cisco Call Manager (3.x and 4.x)

The Cisco Call Manager is an IP telephony signaling server, physically an Intel-CPU Windows 2000 server running the CallManager software application. The Call Manager implements a multitude of services and is the control hub for other IP telephony components. The CallManager is administered through a secure web-based interface and it maintains its configuration and call detail records in SQL Server databases. A Call Manager can be configured in a redundant, failover cluster configuration, where one of the server is, in terms of SQL Server replication, the "publisher", and the other one is the "Subscriber".

These are the main functionalities fo the Cisco CallManager (CCM)
  • Call Routing according to a predefined Dialing Plan, containing partitions and calling search spaces
    • Partitions are logical Directory Number (DN) groupings with route patterns associated to destination devices,trunks or route-lists
    • Calling Search Spaces are ordered lists of partitions that are searched for a route-pattern match in order to place a call.
    • Route plans, based on route patterns, filters, lists, route groups, etc, dictate how calls are routed internally or over PSTN, based on call information.
  • Integration and user managements, through LDAP, with Active-directory based Corporate Directory.
  • Management of media resources:
    • Annunciator resources (to play tones or pre-recorded messages, as RTP streams, to telephony devices)
    • Conference bridging resources (either hardware,DSP-based or software bridges)
    • Transcoding resources (to convert from one voice compression scheme to another)
    • Music on Hold (MOH) resources (RTP-streaming of music from a pre-recorded or "live" source)
    • Media Termination Points, which allow routing calls from a signaling technology to another (e.g. H.323 to SIP)
    • Distributed DSP resources (DSP farms on Cisco routers and Gateways), managed by the CCM using the "gateway control" Skinny (SCCP) protocol.
  • Integration with Voice-Messaging systems
    • SMDI-compliant voice-messaging systems using the Simplified Message Desk Interface (SMDI) protocol
    • Integration with the Cisco-proprietary Unity Voice-Mail system, using the Skinny protocol, through configuration of voice-mail ports on the CCM.
    • Integration with Octel voice-mail systems using Cisco DPA 7630 and 7610 Voice Mail Gateways
  • Management of MGCP-enabled Cisco Voice Gateways


Cisco CallManager deployment types

Single-site deployment

A “single-site” deployment consists usually of a central CCM cluster, with all telephony ser-vices provided over a quasi-unlimited-bandwidth IP LAN. It can serve a maximum of 30000 phones per cluster, with PSTN trunks for all external calls, using only the G.711 codec and only local-gateway media resources. Usually the CCM has all knowledge about the dialing plan (route patterns) and acts as MGCP call-agent for the PSTN and voice gateways. All information related to availability, capacity and usage of PSTN-trunk and DSP resources on the gateways is visible on the Call Manager as performance objects and counters. Agent-based monitoring tools (e.g. NetIQ APpManager or Prognosis IP Telephony Manager) can retrieve this information by periodically polling these performance objects and counters.

Multi-site WAN with centralized call processing

Such a deployment consists of a central CCM cluster with remote IP telephony sites (possibly provided with FXS/FXO gateways), connected to the central site over limited-bandwidth, QoS-enabled, IP WAN links. The voice-mail, unified-messaging, IPCC and IVR functional-ity are centralized. In such a deployment the VoIP service-level on the remote sites depends on the QoS enforced on the IP WAN links and specific QoS measuring (e.g. Cisco IP-SLA probing) and monitoring toolsets should be put in place for monitoring the QoS and alerting in case of degradation.

Multi-site WAN with centralized call processing without SRST

Usually, if no SRST functionality is provided, the CCM has all knowledge about the dialing plan (route patterns) and acts as MGCP call-agent for the PSTN and voice gateways. In this case all information related to availability, capacity and usage of PSTN-trunk and DSP re-sources on the gateways is visible on the Call Manager. This deployment scenario does not briing a need for separately monitoring (e.g. by SNMP) the remote voice gateways, except for standard trap processing.

Multi-site WAN with centralized call processing with SRST

If the SRST functionality is to be provided, there are 2 possible deployment scenarios:
  • In normal operation CCM still acts as MGCP call-agent for remote voice gateways but, in case of IP WAN connectivity loss, each remote gateway has a SRST-mode fall-back mechanism, switching from MGCP to H.323 mode, activating its local dialing plan allowing local and phone-to-PSTN communication.
  • CCM is connected to remote-site gateways through H.323 or SIP trunks, in which case, because the MGCP “audit” commands, bringing back to the CCM the gateway status information, are no longer available, the availability, capacity and usage of PSTN-trunk and DSP resources on the gateways are not visible on the CallManager.


Multi-site WAN with distributed CME call processing

In the distributed model, a remote site can be configured to have either:
  • Its own CCM, CME or other IP PBX .
  • Its own voice PSTN gateway connected to a legacy PBX


The sites are usually interconnected through H.323 or SIP trunks and the gateways register with H.323 gatekeepers (GK), providing Call Admission Control (CAC), or SIP proxy servers. Each site can be configured as a gatekeeper “zone” and provided with a GK or "Hot Standby Router Protocol" (HSRP) GK pair. A CME can support up to 120 phones. Optionally the H.450 tandem gateway features are also deployed on voice gateways, to facilitate supplementary-services signaling between the CCM (which does not support H.450) and the CME. In such a deployment the VoIP service-level on the remote sites depends on the QoS enforced on the limited-bandwidth IP WAN links. Specific QoS probing (e.g. Cisco IP-SLA probing) and monitoring toolsets should be put in place for monitoring the QoS and alerting in case of degradation.

Distributed CCM clustering over IP WAN links

In this scenario CCM clusters components are distributed among central and remote sites, all intra-cluster communication (ICCS) being over QoS-enabled IP WAN links. There are tight bandwidth and QoS requirements on these IP WAN links. The categories of intra-cluster traffic are:
  • MS-SQL database replication traffic, tagged as priority
  • LDAP traffic
  • Priority-marked, real-time "Intra Cluster Communication Signaling" (ICCS), over a fully meshed web of TCP connections between any two servers running the CallManager service.
  • CTI manager real-time traffic, marked as priority
  • CDR records, collected by each subscriber and uploaded to the publisher


Every 10000 Busy Hours Call Attempts (BHCA) between sites clustered over WAN links would take at least 900Kbps of WAN bandwidth for ICCS signaling traffic and another 644Kbps for LDAP, SQL replication, CTI traffic. In terms of QoS management requirements this means tight monitoring of QoS parameters and bandwidth consumption on inter-site WAN links.

Call Manager and Cisco IP Telephony references

Call Manager general references:
  • Cisco Unified CallManager 4.1 home page [30]
  • Cisco Unified CallManager 4.2 home page [31]
  • Cisco Unified CallManager 4.3 home page [32]
  • Cisco Unified CallManager 5.0 home page [33]
  • Cisco Unified CallManager 5.1 home page [34]
  • Cisco CallManager Serviceability System Guide [35]
  • Cisco CallManager System Guide [36]
  • Call Admission Control [37]
  • Cisco CallManager 4.1(3) Call Detail Record Definition [38]
  • Troubleshooting Guide for Cisco CallManager, Release 4.1(3) [39] and 4.2(3) [40]
  • Cisco CallManager Security Guide, Release 4.1(3) [41]
  • Cisco Telephony Design and Implementation [42] (local copy)
  • CallManager Music on Hold Frequently Asked Questions [43]
  • VoIP Signaling and Call Control - Cisco Networking Academy Program [44]
  • IP Telephony - Planning, Design, Implementation and Operation [45] (local copy)
  • Cisco CallManager 4.1 interoperability with Avaya Definity G3 MV1.3 over E1 QSIG using MGCP gateway [46]
  • Cisco CallManager 4.1 interoperability with Avaya S8500 PBX using H.323 trunks [47]
  • Cisco CallManager 4.1 interoperability with Nortel CS1000 using H.323 trunks [48]
  • Advanced Enterprise Campus/WAN IP Telephony Design and Implementation [49]
  • Tech Update - Cisco IP Communications [50]
  • Cisco Test Bed [51]
  • Cisco IOS Voice Troubleshooting and Monitoring Guide [52]
  • Cisco Interoperability Portal [53]
  • Cisco Survivable Remote Site [54]
  • Cisco SIP Portfolio (2003) [55]
  • Certification Zone - The VoIP Gateway [56]
  • Cisco Voice Systems - Study Guide [57]
  • Syngress Cisco Internetworking eBook [58] (local copy)
  • Router voice interoperability with Cisco CallManager [59]
  • Cisco Solution Architecture Reference Manual for IP Telephony [60] with an interesting chapter illustrating the call flows
  • Various resources and tools for Cisco UNity [61]
  • Cisco CallManager Fundamentals,Second Edition online [62]
  • Required Reading For Cisco IP Telephony AVVID Partners [63]
  • Developing Cisco IP IVR Applications [64]
  • Cisco VoIP Networking Design - a Cisco AVVID primer [65]
  • Cisco IOS H.323 Configuration Guide [66]
  • Understanding Dial Peer and Dial Plan Structures [67]
  • Understanding Dial Peers and Call Legs on Cisco IOS Platforms [68]
  • Cisco Press - Cisco IP Telephony (CIPT) Coursebook [69]
  • CCIE Voice notes [70]
  • Cisco CallManager 4.1 UDP and TCP port usage
  • Cisco CallManager trunks reference
  • The Cisco Press' Cisco Call Manager Fundamentals - Second Edition (2005) in eBook format
  • The Cisco Press' Taking Charge of Your VoIP Project (2004) in eBook format
  • The Cisco Press' Voice over IP First-Step (2005) in eBook format
  • Cisco Tech Notes - Understanding H.323 Gatekeepers


Cisco MGCP references:
  • Interworking of Cisco MGCP Voice Gateways and CCM [71]
  • Cisco - How to Configure MGCP with Digital PRI and Cisco CallManager [72]
  • Troubleshooting MGCP and Related Protocol Interfaces to the IP Network [73]


Cisco CallManager Application Programming Interfaces

The CallManager as well as the Cisco IP Phones allow development of third-party telephony or management applications using two technologies:
  • The SOAP-based AXL interface to the CallManager and IP Phones
  • The TAPI/JTAPI interface to the CallManager


The AXL interface to the Cisco CallManager is based on the SOAP protocol and allows external applications to:
  • Enumerate and query perfmon counters and objects and collect thereof perfmon metrics (a.k.a. Perfmonport)
  • Perform real-time device-related queries for any device managed by the CallManager (a.k.a. Risport)
  • Query for server- and cluster-related information


Cisco AXL references

  • AXL Troubleshooting in Cisco CallManager API Troubleshooting Guide [74]
  • Cisco CallManager 4.1(3) AXL Programming Guide [75]
  • Cisco CallManager 4.1(3) AXL Serviceability API Programming Guide [76]
  • Cisco Cal Manager Programming Guides [77]
  • Cisco IP Phone Service Application Development Notes for Release 4.1(3) [78]
  • Cisco presentation - developing IP Phone Applications [79]
  • Inria JTAPI and XML SOAP applications with the Cisco CallManager [80]
  • Developing Cisco IP Phone Services: A Cisco AVVID Solution [81]
  • Cisco AXL stuff from TFH Wildau HochSchule


XML pushing to Cisco 79XX phones

  • Cisco IP Phone URL reference [82]
  • Cisco 79XX XML Push [83]
  • Configuring Cisco 79xx phones [84]
  • Cisco 79XX XML Services [85]
  • XML pushing to Cisco 79XX phones [86]
  • Cisco IP Phone Services Application Development Notes [87]
  • Cisco IP Phone Development Kit [88]
  • Cisco VoIP Programming [89]


Open Source libraries for programming Cisco phones

  • Cisco::IPPhone - Perl Package for creating Cisco IPPhone XML objects [90]
  • IPPhone PHP lib API for Cisco IP Phones [91]


Cisco CallManager 5.0

The new Cisco Call Manager 5.0 is Linux-based and has native SIP support, delivering a rich set of features to Skinny- and SIP-enables phones. The Cisco Call Manager 5.0 is conceived as a Linux-based embedded appliance, requiring minimal administration and is available in 3 options
  • A pre-installed version on an MCS 7815,7825,7835 and 7845 server
  • Software installation kit for compliant IBM and HP Intel-based servers
  • Upgrade kit from CallManager 4.x (Windows based) to 5.0 (Linux based) - an 12 hour procedure
As its Windows-based counterpart, CCM 5.0 works in a redundant cluster configuration, where the Microsoft SQL Server DBMS is replaced with an Informix Dynamic Server (IDS) DBMS. The major drawback of the CallManager 5.0 compared to CallManager 4.x and 5.0 is the apparent lack of agent-based manageability, due to the appliance approach. The new appliance-style CallManager 5.0 is a "black-box", hence software extensions (agents) from third-party vendors can no longer be installed on the box and the direct access to the internal database and real-time performance data is no longer possible. Instead, a SNMP-based management interface and an AXL-based SOAP API are made available to external management applications in order to query the performance counters and to manipulate database records. The Cisco Real Time Monitoring Tool (RTMT) uses these interfaces to monitor device status, system performance, device discovery, and computer-telephony-integration (CTI) applications. The RTMT application also provides trace and log file management capabilities, including scheduling downloads of all trace and log files, user-defined events in trace and log files, and real-time monitoring of trace and log files.

References:

Cisco CallManager 6.0

In March 2007, Cisco Systems announced the release of Cisco Unified Communications System (CCM) 6.0, packaged as "Cisco Unified Communications Manager Business Edition" [93]. The new platform follows Nortel's approach (with its Business Communication Manager), being an integrated IP telephony server Single server solution that combines CCM 6.0 call control and Unity Connection voice messaging. The new CallManager 6.0 is supposed to be a all-in-one, more affordable IP Telephony solution than addresses the mid-size enterprise market with up to 200 employees and limited budgets.

References:

Other components of Cisco Unified Communications architecture

Cisco IPCC (Unified Contact Center) solution

Cisco IPCC consists of four primary components:
  • Cisco IP Telephony infrastructure based on CCM, using different deployment scenarios
  • Queuing and self-service: Cisco IP Interactive Voice Response (IP IVR) or Cisco Internet Service Node (ISN).
  • Contact center routing and agent management: Cisco Intelligent Contact Management (ICM) Software.
  • Agent desktop software: Cisco Agent Desktop or Cisco Toolkit Desktop (CTI Object Server).


Apart from the VoIP infrastructure (switches, gateways, routers), the IPCC components are software applications running on dedicated Windows-based application servers. Optionally, in distributed deployment scenarios, a gatekeeper-controlled call admission policy can be enforced, in order to administer the bandwidth utilization on the inter-site WAN links. The software components of the Unified Contact Center solution are reffered to as Cisco Intelligent Contact Management Software The typical call flow in the IPCC solution is as follows:
  1. Call delivered from PSTN to voice gateway.
  2. MGCP or H.323 Route Request sent to Cisco CallManager.
  3. JTAPI Route Request sent to ICM.
  4. ICM runs routing script. No available agent found, so IP IVR label returned from routing script.
  5. ICM instructs Cisco CallManager to transfer call to IP IVR, and Cisco CallManager does as instructed.
  6. IP IVR notifies ICM that call has arrived.
  7. ICM instructs IP IVR to play queue announcements.
  8. Agent becomes ready (completed previous call or just went ready).
  9. ICM sends call data to selected agent screen and instructs the IP IVR to transfer the call to the agent phone.
  10. IP IVR transfers the VoIP voice path to selected agent phone.
  11. Agent answers call.


Here are some resources:
  • Unified Communications Solution Reference Network Design Guides [95]
  • ICM Enterprise Edition documentation [96]
  • IPCC Enterprise Edition documentation [97]


Cisco CVP (Unified Customer Voice Portal)

Cisco CVP consists of the following main components, all running as software applications on Windows-based application servers:
  • Unified CVP server
  • Unified CVP Voice XML server
  • Unified CVP reporting server
  • Unified CVP operations console server
  • 3’rd party media servers
  • 3’rd party ASR and TTS servers
  • ICM VRU Peripheral Gateway server


The CVP documentation ia available here

Cisco Unified Presence solution

  • Cisco Unified Presence solution literature [98]
  • Cisco Unified Presence Server Deployment Guide, Release Notes [99]
  • Cisco Unified CallManager Interoperability with Microsoft Live Communication Server (LCS) 2005 [100]
  • Yankee Group - The Impact of Microsoft’s Unified Communications Launch [101]

Other components

The Cisco Unity is the Cisco unified voice-mail solution, a software application running on a Windows server and integrating with Microsoft Exchange for the “message store” functionality. The Unity application is using TAPI in order to serve calls into the mailboxes. The number of TAPI resources (lines or voice ports) in use represents a capacity metric and should be monitored as well as the “full” status of the mailboxes. The standalone “express” version of Unity (Unity Express) is running as a software option on a Cisco IOS gateway and is limited to about 100 voice mailboxes The Cisco Fax Server is a Windows-based application server with specialized fax hardware. It can be either Cisco “RightFax” or Sagem-Interstar “Xmedius” Fax Server. The Cisco Unified Meeting Place is primarily a conferencing solution, based on software applications running on Windows servers.

Cisco Golden Bridge

The "Golden Bridge" process is a nickname for a solution-certification process that was institutionalized by Cisco in 2006. The stated goal of the process is "to deliver an integrated, tested, documented suite of IPC products to the enterprise, which results in increased sales and customer satisfaction through easier ordering, system-wide licensing and pricing, and system-level support". The "Golden Bridge" is an internal Cisco process involving design validation and test coverage procedures that guarantee the coherence of particular Cisco Component versions with the solution design and the upfront solution requirements. In order to guarantee "out of the box" fully-functional deployments of IP Telephony solutions, Golden Bridge focusing on:
  • Checking component interoperability and compatibility
  • Verifying solution functionality
    • Verification of deployment models, topology and architecture
    • Verification of call flows & features
  • Testing the solution's availability / reliability / stability
    • Verification of resilience to component failures and failover capability
    • Verification against standard stress-tests
  • Testing the solution's performance / scalability / sapacity
    • Testing against Load / Volume Tests (BHCA, agents, traffic load)
  • Verifying solution for compliance to install & upgrade procedures
    • Verifying system design and testing installation and upgrade
  • Verifying solution usability
    • Specifying end-user and sysadmin necessary training
    • Specifying and verifying install and configure procedures
  • Verifying solution serviceability
    • Testing the monitoring functionality with recommended tools
    • Testing the diagnostic and troubleshooting procedures
  • Testing special problem-areas
    • Regression testing from previous release
  • Security verification and testing
    • Infrastructure security
    • Verifying and testing server hardening


The Golden Bridge results are published as "IP Communications Systems Test Release" nones and published on the Golden Bridge site The Golden Bridge does not guarantee functionality and interoperability of third-party software solutions and components. However, whenever a third-party vendor's application component has to be installed on a Cisco IP Telephonu component (e.g. monitoring agents on CallManager or Unity), the product has to be certified by Cisco for interoperability.

Cisco IP Telephony support tools

  • Cisco Voice Provisioning Tool [102],
a "wizard" tool that expedites the Move,Add & Change (MAC) operations,for mid-market IP telephony solutions based on Cisco CallManager and Cisco UNity.
  • Cisco IP Communications Operations Manager (IPCOM) [103],
an agentless CiscoWorks 2000 bundled-in feature for management and monitoring of Cisco's own IP telephony solutions (including the EXpress series and the voice gateway functionality), using SNMP, CLI commands and AXL-SOAP to communicate with the components.
  • Cisco IP Communications Service Monitor [104] (a component of IPCOM) and the companion Cisco 1040 Sensor [105],
a POE appliance connected to a "spanned" switch POE port, and monitoring (on behalf of the Service Monitor) all RTP streams going through the switch
  • Cisco IPC Express Quick Configuration Tool [106],
a GUI-based "wizard" that reduces to around 1h the time necessary to configure a SMB-size IP telephony solution based on Cisco CallManager Express and Cisco Unity Express.
a GUI tool allowing to take remote control of an IP phone, seeing its screen and being able to dial and control the keypad
  • Voip Integration PhoneRemote - free tool for Cisco IP Phone troubleshooting, similar to Berbee's Remote Phone Control
  • Other Berbee Software tools for the Cisco telephony environment [108]


An interesting testing report on these tools can be found here

Other Cisco IP Telephony resources