Cisco CallManager Express 3.0 Design Guide
Available Languages
Table Of Contents
Cisco CallManager Express (CME) 3.0 Design Guide
Hardware and Software System Requirements
Supported Platforms, IP Phones, DNs, and Memory Requirements
Cisco IOS Images, Cisco CME Releases, and Cisco CME Files
Supported IP Phones and Phone Loads
Cisco CME Upgrade from Version 2.1 to Version 3.0
Deployment Scenarios and Design Considerations
Standalone Cisco CME—Cisco CME with PSTN Interfaces
Cisco CME Registration with the Gatekeeper
Call Transfer and Call Forward
H.450.2 Call Transfer Configuration
Call Transfer/Forward Scenarios
H.450.2 and H.450.3 Deployment Issues
Cisco CME Integration with Cisco CallManager
Cisco CME Migration to Cisco CallManager and Cisco SRST
SCCP Integration with Cisco Unity Server
Analog DTMF Integration with Active Voice Reception and Octel Voice-Mail System
Analog DTMF Integration with Active Voice Reception
In-Band DTMF Integration with Octel
H.323 Integration with SAS and SSAM
SIP Integration with Cisco Unity Express
Voice-Mail Integration in a Centralized Environment
Provisioning and Network Management for Cisco CME
AXL/SOAP APIs for Network Monitoring and Configuration Changes
Poll AXL and SOAP Requests from a Network Management Station
Deploying Cisco CME into Managed Service Providers
Cisco CME with NAT/Cisco IOS Firewall
Cisco CME with Cisco IOS Firewall
Problems on Cisco CME with Cisco IOS Firewall
Troubleshooting Cisco CME Features
Troubleshooting Cisco CME Commands
Appendix: XML Test Program APIs
Cisco CallManager Express (CME) 3.0 Design Guide
This design guide provides Cisco system engineers, partners, and customers with a series of guidelines and best practices to deploy Cisco CME 3.0, formerly known as Cisco IOS Telephony Services (ITS), as a standalone router in small/branch offices, to add a Cisco CME (CME) router to an H.323 network with call transfer/forward support in H.450, to add a Cisco CME router in a Session Initiation Protocol (SIP) network, and so forth. This document covers the system requirements and specifications for Cisco CME 3.0, deployment scenarios, and design considerations for the call transfer/forward, voice-mail integration options, network management capabilities, Cisco CME with Network Address Translation (NAT), and firewalls. It also includes troubleshooting commands and Cisco CME known issues and caveats.
Contents
•
Deployment Scenarios and Design Considerations
•
•
•
•
About Cisco CME
This section contains overview information about Cisco CME that includes the following:
•
•
Cisco CME is an optional Cisco IOS software feature that enables Cisco routers to deliver key system or hybrid PBX functionality for enterprise branch offices or small businesses. Cisco CME is ideal for customers for data connectivity requirements that also have a need for a telephony solution for that office. Whether offered through a service provider's managed services, or purchased directly by a corporation, Cisco CME offers many of the core telephony features required in the small office and many advanced features not available on traditional telephony solutions. Being able to deliver IP telephony and data routing on a single converged solution allows customers to optimize their operations and maintenance costs, resulting in a very cost effective solution to meet the office needs.
Cisco CME supports all the existing features in Cisco IOS routers acting as voice gateways. In addition, the Cisco CME provides the call processing capability for supporting up to 120 users by using the Skinny Client Control Protocol (SCCP). The Cisco CME supports the Cisco 7902, Cisco7905G, Cisco 7910, Cisco 7912G, Cisco 7914 Expansion Module, Cisco 7920, Cisco 7935 polycom, Cisco 7940, and Cisco 7960, and can be integrated with the ATA 186/188 with two analog phone endpoints for cost effective SCCP-based call processing. The router first loads IP phone images to the phones and configures and manages the IP phones. Cisco CME also provides capabilities for call forward and call transfer to other phone numbers or devices such as voice-mail systems. Cisco CME routers are mainly deployed in the two scenarios shown in Figure 1 and Figure 2.
Figure 1 Deploying of Cisco CME in a Small Medium Business (SMB) or Small Enterprise Offices (Retail Stores)
Figure 2 Deploying Cisco CME in a Small Medium Business (Cisco 7905G) Offered Through a Service Provider Managed Service
Cisco CME 3.0 Features
Cisco CME 3.0 is available in Cisco IOS Release 12.2(15)ZJ and has the following new features since the Cisco CME 2.1 release. Note that the latest software with 120 phone support is in Cisco IOS Release 12.2(15)ZJ3.
Phone Features
•
•
•
•
•
•
•
•
•
•
•
•
•
Manageability Improvements
•
•
•
•
•
•
•
•
System Features
•
•
•
•
•
•
•
•
•
•
•
•
Trunk Features
•
•
Note
Cisco CME 1.0 Features
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Cisco CME 2.0 Features
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Cisco CME 2.1 Features
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Hardware and Software System Requirements
This section includes information about the following:
•
•
•
Supported Platforms, IP Phones, DNs, and Memory Requirements
Cisco CME uses the terms ephone, ephone-dn, and virtual voice ports for IP phones. A virtual voice port is similar to a physical voice port, but it is not tied with physical resources. Virtual voice ports can be considered as "lines" to allow multiple lines per physical IP phone. A virtual voice port is equivalent to the IP phone extension and ephone directory number (ephone-dn). Ephone-dns or virtual voice ports are used for line appearances, intercom, paging, conferencing, voice-mail pilot number, voice-mail ports, and voice-mail MWI. Cisco CME automatically creates a POTS dial peer when each ephone-dn is configured. If an ephone-dn is configured with a secondary number as below, Cisco CME will create two POTS dial peers, one for 0100, and another for 408-555-0100:
ephone-dn 1number 0100 secondary 408-555-0100While continuing support of most of the platforms supported in Cisco CME 2.1, Cisco CME 3.0 adds support for the Cisco IAD 243x series,1760-V, and Cisco Catalyst 4500 AGM. Note that Cisco CME 3.0 is not supported on the Cisco IAD 2420 series, Cisco 3620, and Cisco 2600 series (non-XM series). Table 1 shows IP phone, DN, and memory requirements for all supported platforms with Cisco IOS Release 12.2(15)ZJ3.
Note
Table 1 Cisco CME in 12.2(15)ZJ3
IAD2420
—
—
—
—
—
—
—
—
IAD 2430-24FXS
24
120
32/64
32/96
32/64
32/96
32/64
32/96
IAD 2431-1T1E1
24
120
32/64
32/96
32/64
32/96
32/64
32/96
IAD 2431-8FXS
24
120
32/64
32/96
32/64
32/96
32/64
32/96
IAD 2431-16FXS
24
120
32/64
32/96
32/64
32/96
32/64
32/96
IAD 2431-24FXS
24
120
32/64
32/96
32/64
32/96
32/64
32/96
17512
24
120
16/64
16/96
—
—
—
—
1751-V2
24
120
32/96
32/96
—
—
—
—
1760/1760-V2
24
120
32/96
32/96
—
—
—
—
2600 classic/3620
—
—
—
—
—
—
—
—
261xXM
36
144
32/96
32/128
—
—
32/96
32/128
262xXM
36
144
32/96
32/128
—
—
32/96
32/128
265xXM
48
192
32/96
32/128
—
—
32/96
32/128
2691
72
432
32/128
32/128
—
—
32/128
32/128
3640/3640A
48
288
32/96
32/128
—
—
32/96
32/128
3660
96
576
32/96
32/128
—
—
32/96
32/128
3725
96
576
32/128
32/128
—
—
32/128
32/128
3745
120
720
32/128
32/128
—
—
32/128
32/128
Cisco Catalyst 4500 AGM3
24
48
32/64
32/64
32/64
32/64
32/64
32/64
Cisco Catalyst 4500 AGM3
96
576
32/128
32/128
32/128
32/128
32/128
32/128
1 Recommended flash memory/DRAM ready for the next mainline release.
2 Cisco CME is available only with Cisco IOS release IP/VOX PLUS images for the 1751-V and 1760/1760-V Cisco CME with 1751 is available only with the IP/VOX PLUS sv8y image.
3 These are the same model, but each supports a different number of IP phones and DNs based on the amount of memory available on the system. Support on the Cisco Catalyst 4500 AGM will not be in 12.2(15)ZJ, but in 12.3(4)T.
Table 2 shows IP phone, DN, and memory requirements for all supported platforms with Cisco IOS Release 12.2(15)ZJ.
Table 2 Cisco CME in 12.2(15)ZJ3
IAD2420
—
—
—
—
—
—
—
—
IAD 243x
24
120
32/64
32/96
32/64
32/96
32/64
32/96
1751
24
120
16/96
16/96
—
—
—
—
1751-V
24
120
32/96
32/96
—
—
—
—
1760/1760-V
24
120
32/96
32/96
—
—
—
—
2600XM
24
120
32/96
32/128
—
—
32/96
32/128
265x
—
—
—
—
—
—
—
—
265xXM
48
192
32/96
32/128
—
—
32/96
32/128
2691
48
288
32/128
32/128
—
—
32/128
32/128
3640/3640A
48
288
32/96
32/128
—
—
32/96
32/128
3660
48
288
32/96
32/128
—
—
32/96
32/128
3725
48
288
32/128
32/128
—
—
32/128
32/128
3745
48
288
32/128
32/128
—
—
32/128
32/128
2600 classic/3620
—
—
—
—
—
—
—
—
Cat 4500 AGM2
24
48
32/64
32/64
32/64
32/64
32/64
32/64
Cat 4500 AGM2
48
192
32/128
32/128
32/128
32/128
32/128
32/128
1 Recommended flash memory/DRAM ready for the next mainline release.
2 These are the same model, but each supports a different number of IP phones and DNs based on the amount of memory available on the system. Support on the Cisco Catalyst 4500 AGM will not be in 12.2(15)ZJ, but in 12.3(4)T.
Memory Requirements
Each dial peer requires approximately 35 KB, or 50 to be more conservative. Table 3 shows the memory calculation based on 48, 120, 192 DNs and each DN requires about 50k bytes.
Table 3 Memory Per Ephone and Number of DNs
24
120
6,000
36
144
7,200
48
288
14,400
120
432
21,600
192
576
28,800
288
720
36,000
Memory requirement is not based only on the amount required for all the ephone-dns; it also depends on the router's configuration, features, routing protocols, processes, traffic types, and so on. In addition, the Cisco CME router will always need to keep some space for other processes to prevent further ephone-dns from being created if the router's memory is below some certain limit.
Minimum memory is the amount needed to load the Cisco IOS Cisco CME image; the recommended memory is what is needed to run all the features with traffic. Flash memory and DRAM requirements are not only dependent on Cisco CME increased features, but also on the image size and other features in Cisco IOS routers when Cisco CME software is merged with the T train or mainline images.
As always, the more features are added, the more memory is needed. In addition to the minimum memory requirement, we encourage customers to get more memory up front if the router is fully loaded and configured with a lot of features, protocols, and traffic.
Cisco IOS Images, Cisco CME Releases, and Cisco CME Files
Cisco 2600, Cisco 3600, and Cisco 3700 series running Cisco CME 3.0 require a minimum of an IP Plus image. The Cisco 1751 and Cisco 1760 series require a VOX PLUS image or greater. All systems require CME files that shipped are with Cisco CME and copied to the flash memory of the router. Cisco CME 3.0 files can be downloaded from CCO as well.
Cisco CME files can be copied individually or in bulk from the following CCO download pages:
•
•
The following is list of files contained in cme-gui-3.0.3.tar, cme-basic-3.0.3.tar, and cme-3.0.3.zip/tar:
Note
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
The following is a list of files contained in cme-basic-3.0.3.tar:
•
•
•
•
•
•
•
•
•
•
•
The following is a list of files contained in cme-3.0.3.zip/tar:
•
•
•
Table 4 shows a list of information for Cisco IOS images and Cisco CME files.
Note
Supported IP Phones and Phone Loads
Cisco CME allows the Cisco CME router to plug and unplug the Cisco IP phones without requiring a router reboot or manual status reset. If the Cisco CME router is configured properly and has required phone loads in flash memory, IP phone registration with the Cisco CME router is an automatic process. When powered on or connected to the Cisco CME router, the IP phone sends a DHCP client request to Cisco CME for an IP address, IP phone load/firmware, and phone configuration details. As a DHCP and TFTP server, Cisco CME responds with an IP address and phone load and configures the IP phone according to the configuration entered in the router.
The new IP phones supported in Cisco CME 3.0 are the Cisco 7902, 7905G, and 7912G IP phones. Support for Cisco IP Phone 7920 will be added in a later release.
Table 5 shows all the phones and phone loads supported in Cisco CME releases.
Cisco CME Licenses
You must purchase a Cisco CME feature license and phone seat licenses (also called user licenses) prior to using the Cisco CME feature in any production network. Table 6 and Table 7 list platforms and IP phones supported by Cisco CME 3.0 and their part numbers.
Note
Cisco CME 3.0 Installation
Before configuring Cisco CME features, make sure that you get the Cisco CME 3.0 files from CCO at http://www.cisco.com/cgi-bin/tablebuild.pl/ip-key or http://www.cisco.com/cgi-bin/tablebuild.pl/ip-iostsp and then copy and extract the files onto flash memory or slot 0 of the Cisco CME router. For ease of installation, you may download the cme-basic-3.0.3.tar file which includes all of the supported phone loads, Cisco CME GUI files, and MOH file to install and set up supported IP phones. See the file list in the "Cisco IOS Images, Cisco CME Releases, and Cisco CME Files" section. If this is not a new installation, but an upgrade from a previous installation with a zj1 or a zj2 image, you must copy and install the CME GUI files (cme-gui-3.0.3.tar) into flash memory only, as all the supported phone loads and MOH files are already on the flash memory and are still valid for zj3 installation.
Note
For advanced users, you may download only those needed files to the router's flash memory.
The following steps allow you to extract contents of the tar file to router flash memory using the archive command.
Step 1
•
•
Step 2
Step 3
Router# archive tar /xtract tftp://ip-address/filename flash:•
Router# archive tar /xtract tftp://192.168.1.1/cme-basic-3.0.3.tar flash:•
Router# archive tar /xtract tftp://192.168.1.1/cme-gui-3.0.0.tar flash:Note that if you have already copied .tar file to flash memory, you should use flash memory instead of tftp://192.168.1.1.
Step 4
Cisco CME Upgrade from Version 2.1 to Version 3.0
The following steps allow you to upgrade a Cisco CME router from Cisco CME 2.1 to Cisco CME 3.0.
Step 1
Step 2
Step 3
tftp-server flash:P00303020214.bintftp-server flash:P00303020214.bintelephony-serviceload 7910 P00403020214load 7960-7940 P00303020214Step 4
telephony-serviceno application appnameapplication nameIf you configured "application bator" manually for the ephone-dns, configure the following:
telephony-serviceapplication appnameno application appnameStep 5
Deployment Scenarios and Design Considerations
This section provides information about the following:
•
•
•
•
PBX Versus Key-Switch Mode
Cisco CME can be set up or deployed as systems similar to a PBX or a key switch. If you use the Cisco CME setup tool, you will be asked to choose PBX or key-switch mode so that the Cisco CME setup tool will install one button per call or two calls per button on the IP phones, respectively. Both PBX and key-switch modes can be mixed and combined on the same types of the phones.
Cisco CME in PBX Mode
IP phones have only one line displayed on a single button, and each button is associated with two channels to support call waiting, call transfer, and conference. You will usually select PBX mode for Cisco IP Phone 7905G or Cisco IP Phone 7910. The following features can be used for, but are not limited to, the PBX mode:
•
•
•
•
Cisco CME in Key Switch Mode
When key-switch mode is selected, IP phones are linked directly to one or more PSTN trunk lines, and this requires manual configuration in addition to using the Cisco CME setup tool. In key-switch mode, each button is associated with one channel; you will need to create two buttons for the same line or extension to support for call waiting, call transfer, and conference. The following features can be used for, but are not limited to, the key-switch mode:
•
•
•
•
•
•
•
Standalone Cisco CME—Cisco CME with PSTN Interfaces
In a small branch office with a limit of 120 users where a data router exists with PSTN interfaces, the router can be turned on with Cisco CME features to provide calling capability for the phones locally as shown in Figure 3.
Figure 3 Standalone Cisco CME in a 7905G—Branch Offices
Connection types include the following:
•
•
•
Call types include the following:
•
–
–
•
–
–
•
•
Note
•
The two options for fax support are the following:
•
•
Dial-Plan Management
This section includes information about the following topics:
•
•
Dial-Plan Pattern Enhancement
The Cisco CME router allows calls to be dialed with an extension number for both internal and external calls. While local IP-phone-to-IP-phone calls can use the extension number to dial directly, Cisco CME allows external calls to be made by extension numbers by appending or stripping of the prefix as configured in the dialplan-pattern command.
The dialplan-pattern command is used to create a global prefix that can be used to expand the abbreviated extension numbers into fully qualified E.164 numbers. You can configure dialplan-pattern 1 for extension numbers 5001 to 5099 with the telephone prefix starting with 408555. In the following example, the router sees that 4085555044 matches dialplan-pattern 1 and uses the extension-length keyword to extract the last four digits of the number (5044), and presents this number as the caller ID for the incoming call.
For the following configuration example, when the PSTN connects a Direct Inward Dialing (DID) call for "4085551234" to the Cisco CME system, it also forwards the extension digits "1234" to allow the Cisco CME system to route the call.
Router(config)# telephony-serviceRouter(config-telephony-service)# dialplan-pattern 1 4085551.. extension-length 4 no-regYou can also use the following command to allow the extension numbers with leading zeros to be converted to nonzero leading digits from 400 to 499:
Router(config-telephony-service)# dialplan-pattern 1 40855500.. extension-length 3 extension-pattern 4..
Note
Cisco CME Registration with the Gatekeeper
In an H.323 network, a gatekeeper can be used to register with the Cisco CME router and IP phones. IP phones can select to register or not to register with the gatekeeper. If IP phones are to register with the gatekeeper, the extension numbers need to be registered as the E.164 numbers. This can be done by assigning the E.164 numbers as the secondary numbers for the ephone-dn and not registering to the primary extension number.
Ephone-dn 1number 0100 secondary 4085550100 no-reg primary
Note
Call Transfer and Call Forward
Call transfer and call forward are supported in phases. Cisco CME 2.0 supports only blind transfer using a Cisco CME proprietary mechanism (H.323 nonstandard IE). Cisco CME 2.1 provides call transfer with consultation (also known as supervised or attended transfer) for H.323 calls with H.450.2 standard support using a special TCL script configured on all dial peers. This TCL script is supported with TCL IVR 2.0 in Cisco IOS Release 12.2(11)YT or later. Cisco IOS Release 12.3T also supports hookflash transfer on the analog FXS phones.
H.450.2 is an ITU standard call-transfer supplementary service for H.323 VoIP. However, current third-party H.323 products do not support H.450.x because peer-to-peer call transfers are not generally implemented.
This section contains information about the following:
•
•
•
H.450.2 Call Transfer
The H.450.2 call flow is as follows:
•
•
•
•
•
The consultation ID is a central component of the H.450.2 mechanism that helps route the transferred call to the right physical line by ensuring that the A-to-C call goes to the correct destination, and it resolves issues where multiple phone lines have the same telephone number.
The advantages of the H.450.2 call flow include the following:
•
•
•
•
The disadvantages of the H.450.2 call flow include the following:
•
•
•
•
•
•
•
H.450.2 billing issues include the following:
•
•
H.450.2 Call Transfer Configuration
Note
dial-peer voice 100 potsdestination-pattern 9.Tport 1/0/0dial-peer voice 4000 voipdestination-pattern 4...session-target ipv4:1.1.1.1telephony-servicetransfer-pattern 4...transfer-system full-consultAll transfers on an individual Cisco CME router use either H.450.2 or the Cisco CME proprietary mechanism.
The transfer-system command syntax is the following:
transfer-system blind {local-consult | full-consult | full-blind}
•
•
•
•
Local Consult
For a transfer from one local IP phone to another local IP phone, local consult emulates a transfer with consult by allowing the transferor to independently call the transfer-to party and then trigger a call-pickup-on-hold (of the transferee) by the transfer-to destination phone. There is no consultation ID mechanism, so the transfer-to number must be unique for local consult to work correctly.
In ephone-dn configuration mode, the transfer-mode command allows you to override the system default transfer-system command setting (full-consult or full-blind) for an individual ephone-dn or line.
Restrictions and Limitations
•
•
H.450.3 Call Forward
H.450.3 call forward is an ITU standards based alternative to Cisco CME proprietary H.323 nonstandard IE forwarding for busy, no-answer, and call-forward all. H.450.3 does not require the H.450 call transfer script in Cisco CME 3.0.
Cisco CME proprietary forwarding attempts to resolve forwarding for the local forward-to destination within the router first; for example, local call hunting. However, H.450.3 always returns the call to the originator gateway, even if the forwarder and forward-to numbers are on the same Cisco CME. H.450.3 is an optimal method for forwarding to PSTN numbers, where the destination PSTN number, best accessed locally, is the call originator; for example, forward to 1-800.
telephony-servicesforward-pattern 4...If forward pattern is specified or configured, calls from the pattern, such as 4001 (the calling number, not the called number), will be forwarded using H.450.3, while all other calling parties will be forwarded using Cisco CME proprietary forwarding for backwards compatibility unless "forward-pattern.T" is configured to forward all calls using H.450.3.
Call Transfer/Forward Scenarios
Figure 4, Figure 5, Figure 6, Figure 7, and Figure 8 show the five typical scenarios for PSTN, H.323, and VoIP calls to transfer/forward the calls from one system to another.
Figure 4 shows extension 1001 calling 6001 and being transferred to 6001. There is no H.323 or H.450.
Figure 4 Scenario 1
Figure 5 shows a local hairpin transfer. Extension 7001 calls 5002 and is transferred to 5001 using H.450. Extension 7001 calls 5002 and uses the consultation ID sent by extension 5002 to call 5001.
Figure 5 Scenario 2
Figure 6 shows an on-net hairpin transfer. Extension 7001 calls 5002 and is transferred to 6002 using H.450. Extension 7001 calls 5002 and uses the consultation ID sent by extension 5002 to call 6002.
Figure 6 Scenario 3
Figure 7 shows on-net and local-hairpin transfer. Extension 7001 calls 5002 and is transferred to 6002, and then to 6001 using H.450. Extension 7001 calls 5002, uses the consultation ID from 5002 to call 6002, and gets a consultation ID for 6001 to call 6001.
Figure 7 Scenario 4
Figure 8 shows on-net call forward. Extension 7001 calls 5002 and is forwarded to 6001 using H.450.
Figure 8 Scenario 5
H.450.2 and H.450.3 Deployment Issues
The following are issues to consider when deploying H.450.2 and H.450.3:
Built-In Support for H.450.2/H.450.3
Cisco CME 3.0 has built-in support for call transfer/forward in H.450.2/H.450.3 for IP phones. The new default session application introduced in Cisco CME 3.0 is an Application Framework Session application that includes support for call transfer requests. Thus, you will not need to download or configure the H.450 call transfer script manually as in Cisco CME 2.1. However, this new default session application does not support analog hookflash transfer using phones connected to the FXS ports of the Cisco CME router. Call transfer/forward for analog phones still requires the H.450 call transfer script.
Though you will not need to configure the H.450 call transfer script for all dial peers as in Cisco CME 2.1, configuration on call transfer types is still needed. The following is a consultative transfer configuration:
telephony-service...transfer-system full-consulttransfer-pattern ...........ephone-dn 1transfer-mode consultBuilt-In Support for H.450.2/H.450.3 Versus Existing Auto-Attendant Script
The Auto-Attendant script shipped with Cisco CME 2.0 and 2.1 does not work with Cisco CME 3.0. If the Auto-Attendant script takes a call, the script either cannot hand off the call to the H.450 call transfer script or will hand off the call to the Cisco CME 3.0 code with built-in H.450 support; thus call transfer or call forward will fail. You can only run the Auto-Attendant feature or H.450 call transfer, but you cannot run both features together. For Auto-Attendant feature support with the Cisco CME 3.0 default session application infrastructure, changes will be needed for the AA script to hand off the call to the H.450 call transfer script and/or the built-in default session application in Cisco IOS software, and changes are also needed for the H.450 call transfer script and the built-in default session application in Cisco IOS software to receive or accept the call using handoff.
H.450 Everywhere in the Network
Call transfer and call forward support in Cisco CME 3.0 requires that all voice routers in the network have appropriate call transfer support for transfer to work correctly. When H.450.2 and H.450.3 are deployed in H.323/VoIP networks, all voice routers need to be upgraded to understand H.450.2/H.450.3 messages. H.450.3 forwarding will allow for staged upgrade, but routers need to be configured to explicitly identify which calling party numbers support H.450.3 and which do not. H.450.2 and H.450.3 can be enabled independently.
In case some voice gateways/routers in the network do not understand H.450.2 and H.450.3, the workaround is to use local consult by upgrading all routers to Cisco CME 2.0 software with Cisco IOS Release 12.2(8)T or Cisco IOS Release 12.2(11)T. However, local consult does not work with the Cisco AS5300, Cisco AS5400, or Cisco AS5800 in which only blind transfer is supported.
Another alternative for call transfer/forward on H.323/VoIP endpoints of non-Cisco CME routers or third-party gateways is to use a pair of loopback-dns on the Cisco CME router to terminate and regenerate a call locally.
Loopback-dn Support for Call Transfer and Call Forwarding on Cisco and Third-Party Gateways
Before starting on this session, think hard and make up your mind if you do need to use loopback-dns and be aware that it is nontrivial to configure loopback-dns and that loopback-dns have many issues. It is recommended that you upgrade all the routers for H.450 transfer support. If you cannot have H.450 across the network, upgrade all routers with Cisco IOS Release 12.2(8)T or Cisco IOS Release 12.2(11)T to use local consult; if you cannot and still really need the call transfer support, the alternative of using loopback-dn is a last choice for the following reasons:
•
•
•
•
•
•
•
When IP phones are connected to the same standalone Cisco CME router, call transfer call forward does not need any loopback-dn support because there is no VoIP or incompatible endpoints involved. However, the five scenarios shown in Figure 4, Figure 5, Figure 6, Figure 7, and Figure 8 in the "H.450.3 Call Forward" section will require loopback-dn support if Site A, B, and/or C do not use all Cisco CME routers or support H.450.
Cisco CME in SIP Networks
When a Cisco CME router is deployed in SIP networks, Cisco CME integration with SIP is via SIP gateway trunks to support basic calls. SIP Redirect and SIP Refer can be used for call transfers and call forwarding. Consultative transfer should work. Because IP phones do not support in-band DTMF (RFC 2833) in SIP networks (note that Cisco CME integration with H.323 networks uses DTMF relay: H.245-alphanumeric), Cisco CME 3.0 has added Cisco proprietary Notify-based Out-of-band DTMF relay for IP phones in SIP networks. Cisco CME integration with SIP networks uses unsolicited Notify for DTMF relay. Unsolicited Notify is Cisco proprietary and is symmetrical DTMF relay that has to be negotiated during the call setup.
Figure 9 shows how Cisco CME can be deployed in a SIP network.
Figure 9 Deploying Cisco CME in SIP Networks
Note
The following SIP gateway enhancement features are added:
•
–
–
•
–
–
–
–
•
–
–
–
–
Cisco CME Integration with Cisco CallManager
Cisco CallManager uses Empty Capability Set (ECS), a nonstandard protocol, which does not easily support multiple transfers of same call but adds signaling delay for each transfer. Cisco CME does support incoming ECS requests from other voice gateways, but Cisco CME will not initiate an ECS transfer request. Figure 10 illustrates when a Cisco CME router is integrated with Cisco CallManager through PSTN and H.323.
Figure 10 Cisco CME Router Integrated with Cisco CallManager Through PSTN and H.323
Cisco CME integration with Cisco CallManager through PSTN does work; however, Cisco CME integration with Cisco CallManager through H.323 has some interoperability issues, such as lack of ring-back tones, dropping of calls when transferred calls are initiated from the Cisco CME site, one-way voice path, and lack of supplementary services. The workaround for Cisco CME integration with Cisco CallManager through H.323 is to use the loopback-dns. However, loopback-dn is quite complex because configuration for loopback-dns is nontrivial and there are many issues to be aware of. Please set your expectations appropriately.
Note
Cisco CME Migration to Cisco CallManager and Cisco SRST
The Cisco CME deployment solution is designed to fully protect your investment if you decide to migrate to a Cisco CallManager and Cisco SRST solution because of some specific feature needs and/or they outgrow the 120-user limit. The full-featured data router providing Cisco CME functionality can be transitioned into a high-availability gateway in a centralized Cisco CallManager and Cisco SRST design with only some configuration changes. The Cisco CME feature license and phone seat licenses (also called user licenses) can be converted to Cisco CallManager and Cisco SRST licenses. There will be no additional upgrade issues that customers will have to deal with.
Voice Mail
Cisco CME can be integrated with voice-mail systems using SCCP, analog DTMF, H.323, and SIP protocols. This section contains information about the following:
•
•
•
•
•
SCCP Integration with Cisco Unity Server
Figure 11 shows the architecture of how Cisco CME and Cisco Unity are connected in the network for voice-mail integration.
Figure 11 Cisco CME Voice-Mail Integration with Cisco Unity Server
The Cisco CME router registers Cisco Unity ports (vm-device-id CiscoUM-VI2) as SCCP devices/ephones where the voice-mail pilot number is configured as an ephone-dn, and the vm-device as an ephone. For a four-port Cisco Unity server integration, you must configure four ephone-dns and four ephones for the four voice-mail ports and four voice-mail device IDs accordingly. Cisco CME voice-mail integration with Cisco Unity supports the following:
•
•
•
•
Configuration
Configuration includes the following tasks:
•
•
Configure the "Messages" Button to Access the Voice-Mail System (Pilot Number) Directly
You may configure "voicemail 52222" in telephony-service configuration mode:
telephony-servicevoicemail 52222Pressing the messages button on the IP phone or dialing 52222 will let you access the Cisco Unity voice-mail system.
Configure and Bind the Voice-Mail Ports
Configuring and binding the voice-mail ports consists of the following tasks:
•
ephone-dn 32number 52222name "VOICEMAIL1"preference 0ephone-dn 33number 52222name "VOICEMAIL2"preference 1ephone-dn 34number 52222name "VOICEMAIL3"preference 2ephone-dn 35number 52222name "VOICEMAIL4"preference 3! Or configure a dedicated port for MWI only.! ephone-dn 35! number 52223! name "MWI ONLY"•
ephone 5vm-device-id CiscoUM-VI1button 1:32ephone 6vm-device-id CiscoUM-VI2button 1:33ephone 7vm-device-id CiscoUM-VI3button 1:34ephone 8vm-device-id CiscoUM-VI4button 1:35•
ephone-dn 1number 1011call-forward busy 52222call-forward noan 52222 timeout 10! or! call-forward all 52222ephone-dn 2number 1012call-forward busy 52222call-forward noan 52222 timeout 10! or! call-forward all 52222•
Note
ephone-dn 30number 8000mwi onephone-dn 31number 8001mwi offCalls to 8000 will turn the MWI on, and calls to 8001 will turn the MWI off for the extension indicated by the calling-party information supplied through caller ID.
Configuration Example
Note
Cisco CME registers Cisco Unity ports as SCCP devices and ephones.•
•
...telephony-servicevoicemail 52222ephone-dn 30number 8000mwi onephone-dn 31number 8001mwi offephone-dn 32number 52222name "VOICEMAIL1"preference 0ephone-dn 33number 52222name "VOICEMAIL2"preference 1ephone-dn 34number 52222name "VOICEMAIL3"preference 2ephone-dn 35number 52222name "VOICEMAIL4"preference 3! or! ephone-dn 35! number 52223! name "MWI ONLY"...ephone 5vm-device-id CiscoUM-VI1button 1:32ephone 6vm-device-id CiscoUM-VI2button 1:33ephone 7vm-device-id CiscoUM-VI3button 1:34ephone 8vm-device-id CiscoUM-VI4button 1:35Analog DTMF Integration with Active Voice Reception and Octel Voice-Mail System
This section contains information about the following:
•
•
Analog DTMF Integration with Active Voice Reception
Figure 12 shows that the connection between Cisco CME and active voice reception/Octel voice-mail system is through FXS using analog DTMF.
Figure 12 Cisco CME Voice-Mail Integration Through Analog DTMF
The voice-mail system is connected to the FXS port of the router and is treated as a normal extension for the Cisco CME router. For DTMF integrations, information on how to route incoming or forwarded calls in the form of DTMF digits is sent by the Cisco CME router, and message waiting lamp codes are sent from the voice-mail system in the form of DTMF packets. Voice-mail systems are designed to respond to DTMF after the system has answered the incoming calls.
DTMF integrations support the following features:
•
•
Call forward scenario includes the following two scenarios:
–
–
•
The DTMF integration configuration on the Cisco CME router works with any analog voice-mail system. Configuration includes the following tasks:
•
•
•
Configure the "Messages" Button to Access the Voice-Mail System (Pilot Number) Directly
You may configure "voicemail 33333" in telephony-service configuration mode as shown in the following example:
telephony-servicevoicemail 33333Pressing the messages button on the IP phone or dialing 33333 will let you access the voice-mail system.
Configure Call Forwarding to the Voice-Mail System
The Cisco CME router communicates with the analog voice-mail system by sending DTMF patterns. The following voice-mail integration configuration includes four call forward scenarios when call forward to the voice-mail system is configured with DTMF patterns set to 4, 5, 6, and 7, respectively. This also requires that the active voice reception system be accordingly configured with correct patterns.
pattern ext-to-ext no-answer
The Cisco CME router sends 5 to notify the voice-mail system to play personal greetings for no answer when a call coming from one extension to another is forwarded with an answer.
pattern ext-to-ext busy
The Cisco CME router sends 7 to notify the voice-mail system to play personal greetings for busy when a call coming from one extension to another is forwarded with busy.
pattern trunk-to-ext no-answer
The Cisco CME router sends 4 to notify the voice-mail system to play personal greetings for no answer when a call coming from FXO to an extension is forwarded with no answer.
pattern trunk-to-ext busy
The Cisco CME router sends 6 to notify the voice-mail system to play personal greetings for busy when a call coming from FXO to an extension is forwarded with busy.
...telephony-serviceload 7960-7940 P00303020209max-ephones 48max-dn 100ip source-address 10.10.10.199 port 2000create cnf-filesapplication batormax-conferences 6transfer-pattern .Tvoicemail 33333transfer-system full-consultvm-integrationpattern direct 2 CGN *pattern ext-to-ext no-answer 5 FDN * CGN *pattern ext-to-ext busy 7 FDN * CGN *pattern trunk-to-ext no-answer 4 FDN * CGN *pattern trunk-to-ext busy 6 FDN * CGN *ephone-dn 2number 30002description CME-VM-Deptname User#30002call-forward busy 33333call-forward noan 33333 timeout 10application batortranslate called 2ephone-dn 4number 30001description CME-VM-Deptname User#30001call-forward busy 33333call-forward noan 33333 timeout 10application batortranslate called 2ephone-dn 14number 31002name User#ATA-3call-forward busy 33333call-forward noan 33333 timeout 10application batorephone-dn 15number 31003name User#ATA-4call-forward busy 33333call-forward noan 33333 timeout 10application batorConfigure Message Waiting Indication (MWI)
The following is an example MWI configuration:
ephone-dn 25number A1.....*mwi onephone-dn 26number A2.....*mwi offIn-Band DTMF Integration with Octel
Configuration for Octel integration is very similar to the active voice reception integration. The Cisco CME configuration recommendations specific to Octel systems are listed below:
•
•
•
•
–
–
–
–
–
–
The following is a sample of Cisco CME DTMF integration settings. Voice port 1/0/0 is dedicated to voice traffic. All settings relevant to DTMF integration have been highlighted.
...dial-peer voice 5000 potsapplication batordestination-pattern 5000.....port 1/0/0telephony-serviceload 7960-7940 P00303020209max-ephones 48max-dn 192ip source-address 10.4.28.5 port 2000create cnf-filesapplication batortransfer-pattern 2...transfer-pattern 5...voicemail 5000transfer-system full-consultvm-integrationpattern direct 2 CGNpattern ext-to-ext no-answer 5 CGN * FDNpattern ext-to-ext busy 7 CGN * FDNpattern trunk-to-ext no-answer 5 CGN * FDNpattern trunk-to-ext busy 7 CGN * FDNephone-dn 1number 1000description octeltestname test1call-forward noan 5000 timeout 5application batorno huntstop...ephone-dn 4number 1001name test2preference 1call-forward busy 5000call-forward noan 5000 timeout 5application batorephone-dn 100number 3000*....*mwi onephone-dn 101number 3001*....*mwi offephone 1mac-address 0030.94C2.9852button 1:1 2:2ephone 2mac-address 00D0.59E1.F0C8button 1:3 2:4...H.323 Integration with SAS and SSAM
H.323 can be integrated with Stonevoice Application Suite (SAS) and Soft Switch Answering Machine (SSAM). SAS is a common web-based environment running on Windows that allows management of service system parameters and user database shared by all available Stonevoice applications for Cisco CME. SSAM is a unified messaging solution built to integrate and extend the functionality of Cisco CME. SSAM version 2.0 for Cisco CME is fully integrated with SAS.
Figure 13 shows the architecture of how Cisco CME and SAS/SSAM are connected in the network.
Figure 13 Cisco CME Voice-Mail Integration with SAS and SSAM via H.323
The Cisco CME router can be integrated with SAS/SSAM software-based voice-messaging system to provide a voice-mail solution. Each directory number (extension) configured on Cisco CME must also have an associated voice-mail number to forward the calls based on the "call-forward ephone-dn" statement within Cisco CME. All voice-mail numbers are managed by the SAS/SSAM system. Communication between the Cisco CME router and the SAS/SSAM system is via H.323.
Cisco CME voice-mail integration with SAS/SSAM supports the following:
•
•
Cisco CME communicates with the SSAM system via H.323. Cisco CME must have a VoIP dial peer to route the calls to the SSAM system. Extension 1011 (or 1012) must have a unique voice-mail number (for example, 9001 or 9002) created on the SSAM system so that the caller can be put into extension 1011 (or 1012)'s voice-mail number 9001 (or 9002) when 1011 (or 1012) is busy or not answered because the called number 1011 (or 1012) is not passed with the voice-mail number in the H.323 messages.
•
Configuration
Configuration on Cisco CME includes the following tasks:
•
•
•
Note
Configure a VoIP Dial Peer to Access the Voice-Mail System
To enable access to the voice-mail system, configure a VoIP dial peer with a destination pattern matching the voice-mail extension and route the calls to the voice-mail system. The following shows that all calls to a number 9... will be routed to 172.19.153.120, the SSAM service.
dial-peer voice 100 voipdestination-pattern 9...session target ipv4:172.19.153.120dtmf-relay h245-alphanumericcodec g711ulawConfigure the "Messages" Button to Access the Voice Mail Directly
telephony-servicevoicemail 9999Pressing the messages button on the IP phone or dialing the voice-mail number will let you access the SSAM voice-mail system. You may configure "voicemail 9999" in telephony-service configuration mode.
Note
Configure Call Forwarding to Voice Mail
ephone-dn 1number 1011call-forward busy 9001call-forward noan 9001 timeout 10call-forward all 9002ephone-dn 2number 1012call-forward busy 9002call-forward noan 9002 timeout 10! or! call-forward all 9002In this example 1011 is forwarded to 9001, and 1012 to 9002 when busy/noan/all.
Configure MWI
The SAS/SSAM voice mail is able to communicate MWI status with the Cisco CME router so that the Cisco CME router can signal the IP phone to turn the MWI lamp on and off. The MWI information is embedded in the called party's telephone number 8000*....*1 or 8000*....*2. The target extension number is extracted from the called number digits that correspond to the "." wildcard digits in the ephone-dn primary/secondary numbers.
ephone-dn 11number 8000*....*1 secondary 8000*....*2mwi on-offIn the above example, a call to 8000*1011*1 will turn MWI on for extension 1011, and a call to 8000*1011*2 will turn MWI off for extension 1011.
It is recommended that you configure 2, 4, 8 ephone-dns for MWI on and off if a 2-, 4-, 8-port SSAM is installed, respectively.
Configuration Example
The following example shows how to configure Cisco CME 3.0 to enable call forward (no answer/busy), direct access to the SSAM and MWI for a 4-port SSAM:
dial-peer voice 100 voipdestination-pattern 9...session target ipv4:172.19.153.120dtmf-relay h245-alphanumericcodec g711ulawtelephony-service...ip source-address 10.1.1.1 port 2000create cnf-filesvoicemail 9999ephone-dn 1number 1011call-forward busy 9001call-forward noan 9001 timeout 10...ephone-dn 11number 8000*....*1 secondary 8000*....*2mwi on-offephone-dn 12number 8000*....*1 secondary 8000*....*2mwi on-offephone-dn 13number 8000*....*1 secondary 8000*....*2mwi on-offephone-dn 14number 8000*....*1 secondary 8000*....*2mwi on-offephone 1username "user1" password user1mac-address 000A.8A21.4EBEbutton 1:1 2:2ephone 2username "user2" password user2mac-address 000A.8A2C.8C9Ebutton 1:1 2:2SIP Integration with Cisco Unity Express
Cisco CME also supports an integrated voice mail and auto attendant on a network module running Cisco Unity Express for Cisco 2600XM, Cisco 2691 and Cisco 3700 platforms as a solution for small offices. For design guidelines and configuration details, see the appropriate Cisco Unity Express design guides.
Voice-Mail Integration in a Centralized Environment
You can share a single Cisco Unity server located at a centralized environment in which multiple Cisco CME routers are deployed in the branch offices. This is a cost-effective way of providing voice-mail service by eliminating the need of having one voice-mail system for each Cisco CME system. However, in the Cisco Unity case where overlapping dial plans are not supported, the network dial plan needs to be carefully designed because the call setup is across multiple Cisco CME routers and voice-mail servers through H.323. The Cisco CME router co-located with the Cisco Unity at the central site communicates with the Cisco Unity server through SCCP and serves as an MWI-delay server and a SIP-MWI notifier, while the other Cisco CME routers in the branch offices serve as MWI clients, sending subscribe messages and receiving notify messages to/from the MWI-relay server. Once the message is stored in the voice-mail system, the voice-mail system sends an MWI indication using SCCP by spoofing an IP phone appearance. If the extension is local, the Cisco CME attached to the voice-mail system sends an SCCP message to the lamp on the extension directly. If the extension is nonlocal, the Cisco CME system attached to the voice-mail system will relay it by using the SIP-MWI relay mechanism.
MWI Relay
The MWI relay method applies to a centralized environment in which a single voice-mail system is shared among multiple Cisco CME routers in remote branch offices. The SIP-MWI relay server running on the Cisco CME in the central site can act as a notifier to the other Cisco CME routers running as SIP-MWI relay clients and subscribers. The SIP-MWI relay server and clients communicate with each other through notify and subscribe messages. The Cisco CME running as the SIP MWI relay server can also be visualized as a proxy of a voice-mail system using SIP-MWI notify support. The central Cisco CME communicates with the Cisco Unity voice-mail system using SCCP messages. This is a cost-effective way of eliminating the need of having one voice-mail system for each Cisco CME.
Figure 14 shows how a Cisco Unity voice-mail system in the central site can be shared by multiple Cisco CME systems.
Figure 14 Cisco CME Voice-Mail Integration with Cisco Unity Server Using MWI Relay
The Cisco Unity voice-mail system sends the MWI status for an extension to Cisco CME Router 1. Cisco CME Router 1 does not find the extension locally so it sends a SIP Notify message, and the other Cisco CME Router 2 or 3 subscribing to the SIP messages can then signal the IP phone to turn the MWI lamp on/off upon receiving the messages for the phones connected locally.
The following is a configuration example for Cisco CME Router 1 shown in Figure 14:
...telephony-serviceip source-address a.b.c.dmwi relay ! Enables the router to relay the MWI information to the remote IP phones.mwi expires 99999 ! Sets the expire timer for registration for either the client! or the server.voicemail 52222The following is an example configuration on Cisco CME Router 2 and Cisco CME Router 3 shown in Figure 14:
...telephony-service...ip source-address e.f.g.hmwi sip-server a.b.c.d ! Subscribe to the SIP server on Cisco CME Router 1....ephone-dn 1number 1000mwi sip ! Needed for all the ephone-dns for MWI.call-forward noan 52222 time 10 ! 52222 is the Cisco Unity DN configured on! the CME-MWI server.call-forward busy 52222The following configuration adds a VoIP dial peer on the Cisco CME SIP clients to reach 52222:
dial-peer voice xxxx voipdestination-pattern xxxxsession target ipv4:a.b.c.dcodec g711udtmf-relay h245-alpha
Note
Figure 15 provides an overall illustration of this solution.
Figure 15 Cisco CME Voice-Mail Integration with a Cisco Unity Server (SIP MWI Server and Clients)
Note
•
•
•
Provisioning and Network Management for Cisco CME
This section provides information about the following topics:
•
Auto Registration
Cisco CME 3.0 can automatically detect and register the new IP phones added to the network. You no longer need to configure or assign a MAC address to an IP phone. The newly added or installed IP phones will automatically get registered and perhaps get an assigned extension number if there is a pool of extension numbers preconfigured and available to use on a first come first serve basis. The following example configuration shows the setup of a pool of extension numbers for new phones:
telephony-serviceauto assign 1 to 8 type 7960 call-forward 59000 timeout 10create cnf-filesephone-dn 1number 59001ephone-dn 8number 59008If the above is not configured in Cisco CME, the newly added IP phones will complete the boot and registration process without having any buttons associated with extension numbers (ephone-dns), and they will be unable to start making or receiving a call.
Use the above configuration when you need IP phones to be automatically registered or configured.
Note
Setup Utility
The Cisco CME setup tool provides a question-and-answer interface that allows you to set up an entire Cisco CME system at one time. This tool is extremely useful when you set up or install Cisco CME for the first time. You will be asked a series of questions, and based on your answers and selections, Cisco CME will automatically build a configuration file. If a previous Cisco CME configuration exists, you must configure the no telephony-service command to remove the existing configuration details, and then the setup tool can create a new set of commands for you. The following is a list of fields in the questions. You must answer all of the questions before the Cisco CME system can automatically build a configuration.
•
•
•
•
•
•
•
•
•
•
•
Cisco CME GUI
You may use the Cisco CME GUI to configure the phones, ephone-dns, and some of the Cisco CME 3.0 features. The Cisco CME 3.0 GUI enhances the existing GUI with a consistent look and feel with Cisco Unity Express.The Cisco CME 3.0 GUI also adds some drop-down menus and provides several performance and usability enhancements. The Cisco CME GUI can be used for system administration or customer administration to create/modify/delete an extension or IP phone, phone lines, and speed dials. See the Cisco CallManager Express 3.0 System Administrator Guide for information about how to set up and configure the Cisco CME GUI and how to configure features for customer administration users.
Cisco CME 3.0 also supports HTTP 1.1 by using the pop-up box for authentication (see Figure 16). "Logon for Admin" and "system admin users" uses Authentication, Authorization, and Accounting (AAA), while normal user logon is still clear-text based.
Figure 16 Cisco IOS Telephony Services Engine Window
Syslog Messages and MIBs
Another network management feature that Cisco CME 3.0 has introduced is type 6 syslog messages, as shown below for IP phone registration and registration removal. The following syslog messages are useful for the central network management systems to manage Cisco CME and IP phones:
•
•
•
•
•
You can enable Cisco IOS software to log all the syslog events into the buffer of the Cisco CME router and send syslog messages to a syslog server for management:
Router (config)# service timestamps log datetime msec localtimeRouter (config)# aaa new-modelRouter (config)# aaa authentication login default noneRouter (config)# aaa accounting connection H.323 start-stop radiusRouter (config)# gw-accounting syslogRouter (config)# logging 172.19.153.129 ! 172.19.153.129 is the ip address of the syslog! server; multiple servers may also be specified.To synchronize the Cisco CME to an external NTP server, configure the following, where the ip-address argument is that of the time server, which provides the clock synchronization:
Router (config)# ntp server ip-addressIf there is no external NTP time source, use the internal clock as the time source using the following configuration:
Router (config)# ntp masterTo ensure that the time stamps are correct, the router clock should be set to the correct time; an example configuration:
Router (config)# clock set 15:15:00 May 31 2001Multiple syslog servers can be specified for redundancy on a heavily used network because syslog uses UDP as the underlying transport mechanism and data packets are unsequenced and unacknowledged.
Network management systems can also retrieve CDR and call history information from the following MIBs that Cisco CME leverages from Cisco IOS software:
•
•
•
Billing Support
Cisco CME 3.0 adds an Account Code field into the CDR records that can then be used by a RADIUS server or customer billing server for billing process. A soft key "Acct" is added to the Cisco IP Phone 7940 and Cisco IP Phone 7960, so that users can enter account codes from an IP phone during call alerting or connected state. This account code is also added into Cisco-VOICE-DIAL-CONTROL-MIB.
The following Account Code can be viewed in show call active voice command log:
Router# show call active voice...Telephony call-legs: 2SIP call-legs: 0H.323 call-legs: 0MGCP call-legs: 0Total call-legs: 2GENERIC:SetupTime=97147870 msIndex=1PeerAddress=2001...TELE:...AccountCode 0100...
Note
AXL/SOAP APIs for Network Monitoring and Configuration Changes
This section provides information on the following topics:
•
•
About AXL and SOAP
The Cisco AVVID XML Layer (AXL) application programming interface (API) provides a mechanism for inserting, retrieving, updating, and removing data from the database using an XML Simple Object Access Protocol (SOAP) interface. The AXL API allows a programmer to access Cisco CallManager data using XML and receive the data in XML form, instead of using a binary library or DLL. The AXL API methods, known as "requests," are performed using a combination of HTTP and SOAP. SOAP is an XML remote procedure-call protocol. Users perform requests by sending XML data to the Cisco CallManager server. The server then returns the AXL response, which is also a SOAP message.
Cisco CME 3.0 provides the XML APIs for IP phone and extension monitoring and configuration changes by extending the AXL/SOAP capabilities. AXL/SOAP APIs are used to poll the Cisco CME network elements that are the IP phones and ephone-dns/extensions from a network management system. Similar to AXL, communication between a network management system and a Cisco CME system is based on HTTP, and data exchange can only be initiated by polling from the network management system. However, Cisco CME can enable or disable the sending of data and configure control polling intervals.
The following is a list of XML APIs supported by Cisco CME 3.0 for monitoring:
•
–
–
–
•
–
–
–
The following is a list of configuration commands supported by Cisco CME 3.0
•
•
•
•
•
•
•
Test AXL and SOAP Interface
Cisco CME 3.0 provides a test program, xml-test.html (see Appendix: XML Test Program APIs), for users to verify if the Cisco CME router is set up correctly to respond to the AXL and SOAP requests. The following are the steps:
Step 1
Step 2
•
•
•
•
•
Step 3
Step 4
•
•
Step 5
Step 6
•
•
Poll AXL and SOAP Requests from a Network Management Station
The xml-test.html test program checks if the Cisco CME router can respond the AXL and SOAP requests. If you have it enabled, and if you are polling from an application of a network management station, you must disable the test program.
telephony-serviceno xmltest
Note
Deploying Cisco CME into Managed Service Providers
Configuring or provisioning Cisco CME for a large number of Cisco CME routers is possible with the use of Cisco IE 2100, a network appliance. To do this, you put the configuration templates into the IE 2100 server, which will push the configuration templates to the Cisco CME servers globally.
AA with TCL and VxML
This section provides information on the following topics:
AA with Tcl IVR
Cisco CME supports an AA using the Cisco IOS Tcl IVR 2.0 infrastructure. With AA configured and enabled on the Cisco CME router, inbound/outbound callers to the phones connected to the Cisco CME router can hear prompts, enter digits, and place calls. The AA mechanism is supported in the following scenarios:
•
•
•
•
Note
•
Requirements
Supported Platforms
The IVR AA is supported on the following platforms:
•
•
•
•
Prerequisites
•
•
•
•
•
–
–
•
Note
•
•
•
Configuring AA
The required tasks for configuring an AA include the following:
•
call application voice appname tftp://dirt/lxia/ivr/CME_Cisco.2.0.0.0.tclcall application voice appname operator 52222call application voice appname aa-pilot 10228call application voice appname language 1 encall application voice appname set-location en 0 tftp://dirt/sanantha/GrandSlam/vespa2/If the script and prompts are in flash memory, replace tftp://dirt/sanantha/GrandSlam/vespa2/ with flash memory:CME_Cisco.2.0.0.0.tcl.
call application voice vespa flash:CME_Cisco.2.0.0.0.tclcall application voice vespa operator 52222call application voice vespa aa-pilot 10228call application voice vespa language 1 encall application voice vespa set-location en 0 flash:•
dial-peer voice 5001 potsapplication appnameincoming called-number 10228port 2/1:23 ! For PRI port 2/1forward-digits all•
dial-peer voice 5002 potsapplication appnameport 2/0/0 ! For FXO port 2/0/0•
dial-peer voice 3001 pots ! For an analog phoneapplication appnamedestination-pattern 3001port 3/1/1•
dial-peer voice 4001 voipapplication appnamedestination-pattern 41..session target ipv4:10.1.1.2dtmf-relay h245-alphanumeric codec g711ulaw•
ephone-dn 1number 2493ephone-dn 3 ! For an IP phonenumber 2493name "2493"application appnameephone 1button 1:1 2:3 ! To hear the prompt when lifting up the handset and pressing button 3•
Router# call application voice load appname ! To reload the selected TCL script
Note
Tcl Developer Support
Cisco CME is shipped with a sample Tcl script and some prerecorded prompts for some basic AA functionality.
The sample script and prompts are packaged in a Cisco CME file and are downloadable from CCO at http://www.cisco.com/cgi-bin/tablebuild.pl/ip-key.
For script customization, join the Cisco Developer Support Program. This program was created to provide you with a consistent level of support that you can depend on while leveraging Cisco interfaces in your development projects. A signed Developer Support Agreement is required to participate in this program. For more details, and to access this agreement, go to http://www.cisco.com/go/developersupport or contact developer-support@cisco.com.
See also the Cisco TCL IVR and VoiceXML Application Guide at http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/ivrapp/index.htm.
AA with VoiceXML
Cisco CME can leverage the Cisco IOS VoiceXML infrastructure to provide IVR AA features and call-control functionality such as call forwarding and conference calling.
Note
Requirements
VoiceXML is supported on the Cisco CME supported platforms Cisco 3640 and Cisco 3660 with Cisco IOS Release 12.2(11)T, and with 96 MB and 256 MB of DRAM, respectively.
Configuring AA with VoiceXML
To configure the Cisco CME router to run the script, you may do the following:
call application voice vxml_aa flash:simpleCall.vxmldial-peer voice 11111 voipapplication vxml_aaincoming called-number 11111destination-pattern 11111session target ipv4:172.19.153.110dtmf-relay h245-signalcodec g711ulawYou may dial 11111 to hear the prompts and then enter digits.
VxML Developer Support
For information about VxML developer support, see http://www.cisco.com/cgi-bin/dev_support/access_level/products.cgi?product=VOICE_XML_GATEWAY.
Cisco CME with NAT/Cisco IOS Firewall
This section provides information on the following topics:
•
Cisco CME with NAT
The Cisco CME router's LAN interface (Ethernet interface) is used as a source IP address that IP phones and the Cisco CME router communicate with. The IP addresses of the IP phones are internal addresses to the Cisco CME router and are in a different segment that is not visible by the external devices or callers. Other devices, including Cisco IOS gateways or gatekeeper, use the Cisco CME router's IP address to communicate instead of directly communicating with the IP phones. The Cisco CME router translates IP addresses back and forth for the traffic to route to the IP phones or outside of the network area. Therefore, no Network Address Translation (NAT) configuration is needed when talking to the IP phones locally attached to the Cisco CME router. However, when IP phones need to talk to other devices outside the firewall of the Cisco CME network, you must to configure NAT on the Cisco CME router.
Cisco CME with Cisco IOS Firewall
The Cisco IOS firewall, running on Cisco IOS routers, provides a network-based firewall solution with the functionality of context-based access control (CBAC), Intrusion Detection System (IDS), authentication proxy, and URL filtering. A firewall provides access-control between internal and external networks. It identifies networks as "inside" (private) or "outside" (public) in which packets can get from inside to outside, blocked by default from outside to inside, and packets associated with an inside-originated connection are allowed to pass in. Many firewalls work only if all outside traffic originates from well-known sockets and do not handle asymmetric traffic, such as UDP media. Cisco IOS firewalls allow the packets/traffic to pass through on the basis of their source and destination IP addresses and the configured firewall policy.
Cisco CME is a software feature added to the Cisco IOS routers that provides call processing for IP phones using SCCP for branch and SMB in a managed service provider environment. There will be cases in SMB and branch offices where only one router is available to provide Internet access and IP telephony service. Cisco CME requires that all IP phones attach to the Cisco CME router locally. Thus SCCP support on the Cisco IOS firewall is needed for locally generated SCCP traffic.
Problems on Cisco CME with Cisco IOS Firewall
SCCP is a Cisco-proprietary small version of H.323. H.323 traffic can be classified into call signaling, call control, and media communication. H.323 uses Q.931, H.225, and H.245 to set up, manage and control, and tear down calls. When Cisco CME with H.323 and SCCP protocols are run, you must consider how signaling and media streams are affected by the Cisco IOS firewall.
Signaling Stream
An H.323 call requires a TCP connection for H.245 signaling that does not have a well-known port associated with it. The H.245 port is dynamically assigned. Because this port is not known ahead of time and cannot be configured when defining firewall policy, the Cisco IOS firewall will block the H.245 message and the call signaling procedure will fail. When NAT is used in the H.323 signaling path, an inside IP address (behind NAT), not known to the rest of the world, will be used as the "calling party" information element in the H.225 signaling stream; thus an incoming call that attempts to make an H.225 connection back to that address will fail.
Media Streams (RTP Streams)
Real-time transport protocol (RTP) streams run on top of User Datagram Protocol (UDP) and do not have any associated fixed ports. Each type of media stream has one or more channels with dynamically assigned source/destination/port numbers, which are neither known ahead of time nor able to be preconfigured in the firewall policy. For the media stream to traverse the firewall, the firewall needs to open many UDP ports with source and destination pairs for each call session, thus inducing vulnerabilities to the network behind the firewall.
Because the Cisco IOS firewall does not allow outside traffic to transverse to the inside, VoIP calls (inbound calls) will fail. Furthermore, dynamic RTP/RTCP ports used by the endpoints are not automatically opened and allowed without modification of the security policy. The problems are summarized as follows:
•
•
–
–
–
•
–
–
–
The caveat CSCdx39135 was opened to track and resolve the problem.
Current Status
Currently, the Cisco IOS firewall does not support SCCP inspection because outgoing packets will be converted to H.323 or SIP, and thus there is no need for SCCP inspection. However for incoming SCCP packets inspection, you can use access control lists (ACLs) to filter out unwanted packets or traffic. However, the Cisco IOS firewall will add inspection support for any locally generated traffic as a fix for caveat CSCdx39135.
Workaround
The following are four alternative solutions to provide security to Cisco CME users:
•
•
•
•
Troubleshooting Cisco CME Features
This section provides information on the following topics:
•
Troubleshooting Cisco CME Commands
•
–
–
–
–
–
–
–
–
–
–
–
–
•
–
–
–
–
–
–
–
–
–
•
–
–
–
–
–
–
–
–
–
–
–
–
•
–
–
–
•
–
–
–
–
–
–
–
–
–
•
–
–
Cisco CME Caveats
•
•
•
•
•
Additional References
•
•
Related Documents
Cisco CME 3.0 configuration and IP phone user and quick reference cards
•
Cisco SRST 3.0 configuration and IP phone quick reference cards
•
Cisco IP phones administration, installation, and regulatory information
Cisco Unity Express technical documentation
Cisco Unity Express integration
•
Cisco Unity integration
•
XML guidelines for Cisco IP phone services
XML application programming interface (API)
TAPI development
Default session application
•
Domain management with Cisco Packet Telephony Center - Virtual Switch (Cisco PTC - VS)
•
Dynamic Host Configuration Protocol (DHCP)
•
Dial peers, DID, and other dialing issues
•
•
•
•
H.323
SIP
•
•
ATAs
Additional Cisco IOS Voice Configuration Library documents, including library preface and glossary
•
Cisco IOS command references
•
•
Cisco IOS troubleshooting information
Cisco IOS configuration examples
•
Note
Additional configuration guides
•
•
•
•
•
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
MIB CISCO-VOICE-DIAL-CONTROL-MIB
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
RFCs
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
—
Appendix: XML Test Program APIs
The following are XML test program (xml-test.html) APIs:
ISgetGlobal [View XML]
Top of Form
Global
Bottom of Form
ISgetDevice [View XML]
Top of Form
DeviceID
DeviceName
Bottom of Form
ISgetExtension [View XML]
Top of Form
ExtensionID
ExtensionName
Bottom of Form
ISgetEvtCounts [View XML]
Top of Form
Events Count
Bottom of Form
ISgetDevEvts [View XML]
Top of Form
Dev Event ID
Dev ID
Dev Name
Bottom of Form
ISgetExtEvts [View XML]
Top of Form
Ext Event ID
Ext ID
Ext Name
Bottom of Form
ISsetKeyPhones [View XML]
Top of Form
Phone Name
Bottom of Form
ISexecCLI [View XML]
Top of Form
CLI-1
CLI-2
CLI-3
CLI-4
CLI-5
CLI-6
CLI-7
CLI-8
CLI-9
CLI-10
Bottom of Form
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)