Views |
Telecom:IPT:Cisco[edit] Navigation[edit] Related categories[edit] About this pageWe apologize for the little information we provide, this page is still under construction. Please stay tuned.
[edit] Cisco IP telephony resourcesA 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.[edit] CallManager HistoryWhat 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.[edit] 1994—Multimedia ManagerThe 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.[edit] 1997—Selsius-CallManagerAlthough 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.[edit] 2000—Cisco CallManager Release 3.0The 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.[edit] 2001 - 2002 — Cisco CallManager Release 3.xCallManager 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:
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. [edit] The Cisco VoIP portfolioThe 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:
Here is a sample of the current portfolio of Cisco IP telephony products :
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. [edit] The Cisco IP Telephony and multimedia conferencing design blueprintsCompared 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:
[edit] 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)
[edit] Cisco CallManager deployment types[edit] Single-site deploymentA “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.[edit] Multi-site WAN with centralized call processingSuch 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.[edit] Multi-site WAN with centralized call processing without SRSTUsually, 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.[edit] Multi-site WAN with centralized call processing with SRSTIf the SRST functionality is to be provided, there are 2 possible deployment scenarios:
[edit] Multi-site WAN with distributed CME call processingIn the distributed model, a remote site can be configured to have either:
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. [edit] Distributed CCM clustering over IP WAN linksIn 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:
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. [edit] Call Manager and Cisco IP Telephony referencesCall Manager general references:
Cisco MGCP references:
[edit] Cisco CallManager Application Programming InterfacesThe CallManager as well as the Cisco IP Phones allow development of third-party telephony or management applications using two technologies:
The AXL interface to the Cisco CallManager is based on the SOAP protocol and allows external applications to:
[edit] Cisco AXL references
[edit] XML pushing to Cisco 79XX phones
[edit] Open Source libraries for programming Cisco phones
[edit] Cisco CallManager 5.0The 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
References:
[edit] Cisco CallManager 6.0In 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:
[edit] Other components of Cisco Unified Communications architecture[edit] Cisco IPCC (Unified Contact Center) solutionCisco IPCC consists of four primary components:
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:
Here are some resources:
[edit] Cisco CVP (Unified Customer Voice Portal)Cisco CVP consists of the following main components, all running as software applications on Windows-based application servers:
The CVP documentation ia available here [edit] Cisco Unified Presence solution
[edit] Other componentsThe 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.[edit] Cisco Golden BridgeThe "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:
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. [edit] Cisco IP Telephony support tools
An interesting testing report on these tools can be found here [edit] Other Cisco IP Telephony resources
|
| This page was last modified 00:26, 1 November 2008. |