|
Table Of Contents
Release Notes for Cisco CallManager Release 4.0(1)
Determining the Software Version
Compatibility Matrix and Supported Upgrades
Installation and Backup Enhancements
Disabling RIS Data Collector Prior to Upgrading to Cisco CallManager Release 4.0 and Above
Support for New Cisco IP Phones
Multiple Calls on Directory Numbers (lines)
Conference and Transfer Enhancements
Configurable Call Forward Information Displayed
Configuring Service URL on Phone Buttons
Barge and Privacy Enhancements
Multilevel Precedence and Preemption
Attendant Console Enhancements
Cisco CallManager Extension Mobility Enhancements
Cisco IP Manager Assistant (IPMA) Enhancement
Cisco Unity Voice-Mail Port Adjustments
Additional Media Resources Support
Multilevel Administration Access Enhancements
Session Initiation Protocol (SIP) Trunk
Bulk Administration Tool Enhancements
Tool for Auto-Registered Phone Support Enhancements
CDR Analysis and Reporting (CAR) Enhancements
New and Changed Information for Cisco CallManager Serviceability
Cisco CallManager Trace Collection Tool
Real-Time Monitoring Tool (RTMT) as Standalone Plugin
Serviceability Reports Archive
SNMP and Performance Counter Enhancements
New and Changed Information for Third-Party and SDK Applications
Cisco CallManager Call Detail Record Definition
Cisco CallManager Extension Mobility API Developer Guide Release 4.0(1)
Cisco IP Phone Services Application Development Notes
Cisco JTAPI Developer Guide for Cisco CallManager 4.0(1)
Cisco JTAPI Installation Guide for Cisco CallManager 4.0(1)
Cisco TAPI Developer and Installation Guides for Cisco CallManager 4.0(1)
Changes From CiscoTSP 3.3 to CiscoTSP 4.0
CSCso79248 Do Not Run installxml.vbs in Unified CM Release 3.3 and Later
Uninstall CDR Analysis and Reporting Plugin Before Upgrading to Cisco CallManager 4.0(1)
Locale Installer for Cisco CallManager
Using TAPS to Configure Shared-line Phones
Survivable Remote Site Telephony (SRST) Support
Uninstalling Backup and Restore (BARS) Version 4.0(1)
Adding Cisco CallManager Servers
Softkey Support for Cisco IP Phone Models 7905 and 7912
Resolved Caveats for Cisco CallManager - Release 4.0(1)
Open Caveats for Cisco CallManager - Release 4.0(1)
Installation and Upgrade Document References Incorrect Version of Backup and Restore (BARS)
Route Pattern/Hunt Pilot Configuration
Fax and Modem Connectivity with Cisco CallManager
Cisco Unity Voice-Mail Port Changes
Obtaining Technical Assistance
Obtaining Additional Publications and Information
Release Notes for Cisco CallManager Release 4.0(1)
Updated June 23, 2008
These release notes describe the new features and caveats for Cisco CallManager Release 4.0(1).
Before you install Cisco CallManager, we recommend that you review the "Important Notes" section for information on issues that may affect your system.
For a list of the open and resolved caveats for Cisco CallManager Release 4.0(1), see "Resolved Caveats for Cisco CallManager - Release 4.0(1)" section and "Open Caveats for Cisco CallManager - Release 4.0(1)" section. Updates for these release notes occur with every maintenance and major release.
To access the documentation suite for voice products, refer to
http://www.cisco.com/univercd/cc/td/doc/product/voice/
Access the latest software upgrades and release notes for Cisco CallManager 4.0 on Cisco Connection Online (CCO) at
http://www.cisco.com/public/sw-center/sw-voice.shtml
Contents
These release notes discuss the following topics:
•Compatibility Matrix and Supported Upgrades
•New and Changed Information for Cisco CallManager Serviceability
•New and Changed Information for Third-Party and SDK Applications
•Resolved Caveats for Cisco CallManager - Release 4.0(1)
•Open Caveats for Cisco CallManager - Release 4.0(1)
•Obtaining Technical Assistance
Introduction
Cisco CallManager, a network business communication system, provides high-quality telephony over IP networks. Cisco CallManager enables the conversion of conventional, proprietary, circuit-switched PBXs to multiservice, open LAN systems.
System Requirements
Make sure that you install and configure Cisco CallManager Release 4.0 on a Cisco Media Convergence Server (MCS). For information about installing Cisco CallManager Release 4.0 on a Cisco Integrated Communications System (ICS) 7750, go to http://www.cisco.com/public/sw-center/telephony/ics-7750/ics-compatibility.shtml
You may also install Cisco CallManager on a Cisco-approved HP server configuration or a Cisco-approved IBM server configuration.
Caution The installation does not complete if you do not have the exact configuration.
Access the correct Cisco-approved server configuration for IBM server or HP server at
http://www.cisco.com/en/US/products/hw/voiceapp/ps378/prod_brochure_list.html
For system hardware component information and system requirements, refer to Installing Cisco CallManager Release 4.0.
Determining the Software Version
To determine the software version of Cisco CallManager, open Cisco CallManager Administration; then, click Details on the main Cisco CallManager Administration window. The following information displays:
•Cisco CallManager System version
•Cisco CallManager Administration version
•Database information and database DLL versions
Compatibility Matrix and Supported Upgrades
You can find which application versions are compatible with Cisco CallManager Release 4.0(1) and which previous release of Cisco CallManager has upgrade support at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/ccmcomp.htm
Note Be aware that the release of Cisco IP telephony products does not always coincide with Cisco CallManager releases. If a product proves to be incompatible with Cisco CallManager, you need to wait until a compatible version of the product becomes available before you upgrade to Cisco CallManager Release 4.0(1). For the most current compatibility combinations and defects, refer to the documentation that is distributed with the Cisco IP telephony products.
Related Documentation
Refer to the Cisco CallManager Document Guide for a list of documents that are related to Cisco CallManager Release 4.0 at
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/4_0/doc_gd
Along with the documents listed in the Cisco CallManager Document Guide, the following list gives other related documents for Cisco CallManager Release 4.0.
•Skinny Client Control Protocol Messaging Guide
•Cisco CallManager Call Detail Record Definition
•Cisco IP Phone Services Application Development Notes
•Cisco JTAPI Installation Guide for Cisco CallManager 4.0(1)
•Cisco JTAPI Developer's Guide for Cisco CallManager 4.0(1)
•Cisco TAPI Installation Guide for Cisco CallManager 4.0(1
•Cisco TAPI Developer's Guide for Cisco CallManager 4.0(1)
•Cisco CallManager Extension Mobility API Developer's Guide Release 4.0(1)
•System Error Message
•Cisco CallManager 4.0(1) AXL Programming Guide
•Cisco CallManager 4.0(1) AXL Serviceability Programming Interface Guide
•Cisco CallManager Dialed Number Analyzer Guide
•Cisco WebDialer API Reference
New and Changed Information
This following sections describe new features and changes that are pertinent to this release of Cisco CallManager. The sections include configuration tips for the administrator, information about users, and where to find more information.
•Installation and Backup Enhancements
•Disabling RIS Data Collector Prior to Upgrading to Cisco CallManager Release 4.0 and Above
•Support for New Cisco IP Phones
•Multiple Calls on Directory Numbers (lines)
•Conference and Transfer Enhancements
•Configurable Call Forward Information Displayed
•Configuring Service URL on Phone Buttons
•Barge and Privacy Enhancements
•Malicious Call Identification
•Multilevel Precedence and Preemption
•Attendant Console Enhancements
•Cisco CallManager Extension Mobility Enhancements
•Cisco IP Manager Assistant (IPMA) Enhancement
•Cisco Unity Voice-Mail Port Adjustments
•Additional Media Resources Support
•Multilevel Administration Access Enhancements
•Session Initiation Protocol (SIP) Trunk
•Removing a Deleted Subscriber
•Bulk Administration Tool Enhancements
•Tool for Auto-Registered Phone Support Enhancements
•CDR Analysis and Reporting (CAR) Enhancements
•New and Changed Information for Cisco CallManager Serviceability
•New and Changed Information for Third-Party and SDK Applications
Installation and Backup Enhancements
Cisco implemented the following changes for Cisco CallManager 4.0(1) release.
Backup Changes
Cisco provides two backup utilities:
•Cisco IP Telephony Backup Utility
•Cisco IP Telephony Backup Restore System (BARS)
You use the Cisco IP Telephony Backup utility version 3.5.53 (or later) for servers that are running Cisco CallManager 3.2(x). You use BARS 4.0(2) or later for servers that are running Cisco CallManager 3.3(x) or later.
Both backup utilities support CER 1.2(1) or later and all CRA/CRS and Cisco CAR releases that are compatible with Cisco CallManager.
Changes That Apply to Cisco CallManager 4.0(1) Installations and Upgrades
The following changes apply to all Cisco CallManager 4.0(1) installations and upgrades:
•Cisco CallManager 4.0(1) requires Cisco-provided operating system version 2000.2.5 (or later) and the service release 2000-2-5sr2 (or later.)
•Cisco CallManager 4.0(1) uses two installation disks:
–Cisco CallManager 4.0(1) Installation, Upgrade, and Recovery Disk 1
–Cisco CallManager 4.0(1) Installation, Upgrade, and Recovery Disk 2
You are prompted to insert the appropriate disk during the installation process.
•The Cisco CallManager installation contains additional and more meaningful error messages.
New Installation Changes
The following changes apply to all Cisco CallManager 4.0(1) installations:
•The installation program requires that you have 2.0 gigabytes of available disk space on your server.
•SQL 2000 SP3a installs automatically during the Cisco CallManager installation.
•To back up your system, install and configure the Cisco IP Telephony Backup and Restore System (BARS), version 4.0(2) or later. For more information, refer to the Cisco IP Telephony Backup and Restore System (BARS) Administration Guide, Version 4.0(2) (or later). To obtain the most recent version of this document, go to http://www.cisco.com/univercd/cc/td/doc/product/voice/backup/index.htm.
Important Notes Regarding Upgrades from Cisco CallManager 3.2(x)
The following important notes apply to upgrades from Cisco CallManager 3.2(x) to Cisco CallManager 4.0(1):
•The upgrade program requires that you have 3.0 gigabytes of available disk space on your server.
•You must use Cisco IP Telephony Backup utility version 3.5.53 (or later) to back up your system before you upgrade.
•Cisco CallManager 4.0(1) requires Cisco-provided operating system version 2000.2.5 (or later) and the service release 2000-2-5sr2 (or later.) You must install OS version 2000.2.4 (or later) by using the Same Server Recovery method, upgrade to OS version 2000.2.5 (or later), and then upgrade to the latest service release.
Important Notes Regarding Upgrades from Cisco CallManager 3.3(x)
The following important notes apply to upgrades from Cisco CallManager 3.2(x) to Cisco CallManager 4.0(1):
•The upgrade program requires that you have 3.0 gigabytes of available disk space on your server
•Cisco CallManager 4.0(1) requires Cisco-provided operating system version 2000.2.5 (or later) and the service release 2000-2-5sr2 (or later.) You can upgrade the operating system from version 2000.2.3 (or later.)
•You must install Microsoft SQL Server 2000 Service Pack 3a (or later) before you upgrade to Cisco CallManager 4.0(1).
To back up your system, install and configure the Cisco IP Telephony Backup and Restore System (BARS), version 4.0(2) or later. For more information, refer to the Cisco IP Telephony Backup and Restore System (BARS) Administration Guide, Version 4.0(2) (or later). To obtain the most recent version of this document, go to http://www.cisco.com/univercd/cc/td/doc/product/voice/backup/index.htm.
Upgrade Tips
Clicking the Cancel button during the Cisco CallManager installation/upgrade process causes Cisco CallManager to become nonfunctional. If you click Cancel during the installation process, you must restart the installation from the beginning before you can use Cisco CallManager.
You can increase the system performance on servers with four drives by configuring a drive to collect trace files. The Cisco CallManager documentation instructs you to configure the F: drive to collect trace files; however, you need to configure the drive that is labeled Trace. To determine which drive is labeled Trace, log in to the system by using the local Administrator account and double-click My Computer on the system Desktop. Note the drive letter of the drive that is labeled Trace. Use this drive letter when configuring a drive to collect trace files.
Disabling RIS Data Collector Prior to Upgrading to Cisco CallManager Release 4.0 and Above
Before upgrading to Cisco CallManager Release 4.0 and above, Cisco recommends that the administrator disables the RIS Data Collector to minimize system problems and prevent false alerts. The following procedure describes how to disable the RIS Data Collector.
Procedure
Step 1 From Cisco CallManager Administration, choose Service > Service Parameters.
The Service Parameters Configuration window displays.
Step 2 From the Server pull-down menu, choose any server.
Step 3 From the Service pull-down menu, choose RIS Data Collector.
Step 4 In the Data Collection Enabled field, choose False.
Step 5 Click Update.
You can now perform the upgrade to Cisco CallManager 4.0 and above.
Note After you complete the Cisco CallManager upgrade, be sure to reset the parameter to "True" in the Data Collection Enabled field from the Service Parameters Configuration window to enable RIS data collection.
Related Documentation
•Cisco CallManager Serviceability System Guide
•Cisco CallManager Serviceability Administration Guide
Support for New Cisco IP Phones
Cisco CallManager Release 4.0(1) includes support for Cisco Wireless IP Phone model 7920, the Cisco IP Conference Station 7936, and the Cisco IP Phone model 7970.
Where to Find More Information
•Cisco Wireless IP Phone 7920 Administration Guide
•Cisco IP Conference Station 7936 Administration Guide
•Cisco IP Phone 7970 Administration Guide for Cisco CallManager
Menu Changes
In Cisco CallManager Release 4.0(1), the Automated Alternate Routing (AAR) Group menu option moves from the System menu to the Route Plan menu.
Where to Find More Information
•"Automated Alternate Routing Group Configuration," Cisco CallManager Administration Guide
Multiple Calls on Directory Numbers (lines)
In previous releases of Cisco CallManager, a maximum of 2 calls could exist on a single line (one active and one on hold). In Cisco CallManager release 4.0, multiple calls can exist on the same line. (Depending on the phone model, some phones can display up to 200 calls on a single line. The user scrolls to view each call.) This capability eliminates the need to create multiple instances of the same directory number in different partitions to allow users to share a line and still be able to receive and place multiple calls out of the same line. To easily manage more than one call on the line and to view calling name and number of the calls on the line, a new user-interaction model exists on the phone display.
You can configure up to 200 calls for a line on a device in a cluster, with the limiting factor being the device. As you configure the number of calls for one line, the calls that are available for another line decrease. Cisco IP Phones that support the multicall display (such as a Cisco IP Phone 7960) support up to 200 calls per DN and 2 calls per DN for non-multicall display devices (such as Cisco IP Phone 7905).
Phones that are capable of supporting multiple calls display information for all concurrent calls. For each call, the phone displays a unique call identifier, the selected call status, call information, and the call state.
Note Only the Cisco IP Phone models 7940 and 7960 support multiple calls on directory numbers in release 4.0(1).
Configuration Tips
Using Directory Number Configuration, administrators configure the following multiple call/call waiting line parameters on each phone that is capable of supporting multiple calls:
•No Answer Ring Duration—Used in conjunction with Call Forward No Answer Destination, this field sets the timer for how long the phone will ring before it gets forwarded. Leave this setting blank to use the value that is set in the Cisco CallManager service parameter, Forward No Answer Timer.
•Maximum Number of Calls—You can configure up to 200 calls for a line on a device, with the limiting factor being the total number of calls that are configured on the device. As you configure the number of calls for one line, the calls that are available for another line decrease.
•Call Forward No Answer—This field forwards calls when the phone is not answered after the configured no answer ring duration.
•Busy Trigger—This setting, which works in conjunction with Maximum Number of Calls and Call Forward Busy, determines the maximum number of calls that can be presented at the line.
Example
Max number of calls = 50
Busy trigger = 40
If no calls are present on the line, this line can receive a maximum of 40 calls. If this line originated 40 calls, the line can originate 10 more calls but cannot receive any additional calls. The following formula decides the number of calls that this line can receive: Busy Trigger minus the number of calls that are currently present on this line. So, with 40 calls present on this line, new incoming call 41 gets rejected with a busy cause (and will get forwarded if Call Forward Busy is set). If this line is shared, all the lines must be busy before the incoming calls get rejected. The call initiates alerts on all lines with that DN until the configured No Answer Ring Duration timer value is exceeded. Once the timer value is exceeded, the call diverts to the configured Call Forward No Answer target. To disable call waiting, set the busy trigger to 1. If this line is shared and you want to disable call waiting, set the busy trigger to 1 on all shared DNs.
Configuration Comparisons
Table 1 illustrates the multicall display line configuration differences between Cisco CallManager release 4.0 and release 3.3.
Table 2 illustrates the single line display configuration differences between Cisco CallManager release 4.0 and release 3.3.
How this Feature Affects the User
•In previous releases, the user could have only two calls on the same line. Improved display text provides information for managing multiple calls on the same line. The display shows whether a call is holding, alerting or connected. The user can select a call to connect with by navigating between calls in the list.
Where to Find More Information
•"Cisco IP Phone Configuration," Cisco CallManager Administration Guide
•"Cisco IP Phones," Cisco CallManager System Guide
Shared-Line Enhancements
Cisco CallManager supports the following enhancements to shared lines:
•Administrators can now configure devices that are sharing a line to support multiple calls. This allows users on shared-line phones to make or receive a call while the remote phone is in use.
•Call information (such as calling party or called party) displays on all devices that are sharing a line. If the Privacy feature is turned on by one of the devices, other devices that are sharing the line will not see outbound calls made from the device that turned privacy on. All devices will still see inbound calls to the shared line.
•Devices with shared-line appearance support the Call Forward Busy Trigger and the Maximum Number of Calls settings. You can configure Call Forward Busy Trigger per line appearance, but the configuration cannot exceed the maximum number call setting for that directory number.
•Cisco IPMA with shared-line support allows managers and assistants to share lines (refer to the Cisco CallManager Features and Services Guide).
Configuration Tip
•Cisco IP Phones without pixel-based displays (such as the Cisco IP Phone model 7910) cannot manage more than two calls (one inbound, one outbound) per line.
How this Feature Affects the User
•Users that have shared lines can manage multiple calls for the same line appearance. For example, when one user answers a call for the shared line appearance, another user can answer the next incoming for that line appearance. New call display information helps users manage calls on shared lines.
Where to Find More Information
•"Cisco IP Phone Configuration," Cisco CallManager Administration Guide
•"Cisco IP Phones," Cisco CallManager System Guide
Unassigned Directory Numbers
Directory numbers get associated with devices such as phones, route points, CTI ports, and H.323 clients. Administrators manage directory numbers from the Directory Number Configuration and Route Plan Report windows in Cisco CallManager Administration.
When you remove a directory number from a phone, the number still exists within Cisco CallManager. To see a list of directory numbers that are not associated with phones, use the Route Plan Report menu option.
Unassigned DNs allow customers to continue forwarding to voice messaging or another destination for DNs that are no longer assigned to devices. This can happen when employees are reassigned or terminated.
Previous to release 4.0, the system automatically deleted directory numbers when a device was deleted. Because line group support is a feature of release 4.0, you must now keep unassigned DNs.
Configuration Tips
To permanently remove a directory number, you must perform a two-step procedure:
1. Use the Directory Number Configuration window to add, update, and remove directory numbers from a device, route point, or port.
2. Use the Route Plan Report window to delete or update unassigned directory numbers from Cisco CallManager database.
Where to Find More Information
•"Cisco IP Phone Configuration," Cisco CallManager Administration Guide
•"Route Plan Report," Cisco CallManager Administration Guide
•"Line Group Configuration," Cisco CallManager Administration Guide
Phone Button Template Consolidation for Cisco IP Phone Model 7960 and Cisco Expansion Module Model 7914
The standard phone button template for the Cisco IP Phone Model 7960, which supports the Cisco IP Phone Model 7914 Expansion Module, includes buttons for both devices (up to 34 buttons). The template uses buttons 1 and 2 for lines and assigns buttons 3 through 34 as speed dials or lines or for the features privacy and service URL.
If you are upgrading from an earlier release of Cisco CallManager and you have separate templates for the Cisco IP Phone Expansion Module model 7914 and Cisco IP Phone model 7960, Cisco CallManager automatically creates a consolidated phone button template.
The following reasons explain why the Cisco IP Phone model 7960 and Cisco Expansion Module model 7914 phone button templates were updated in release 4.0:
•Make all phone button templates for a model dependent on the maximum number of buttons that are possible for base plus expansion modules.
•Remove the phone button template for the expansion module
•Limit the appearance of features across the base and expansion modules
Configuration Tips
•To create a consolidated phone button template for new users, use the following procedure:
–From the Phone Button Template Configuration window, choose a standard 7960 phone button template.
–Copy the 7960 phone button template, rename it; for example, 7960 with expansion buttons, and click Update. The new phone button template displays with all 34 buttons available for configuring features such as speed dial, service URL, and Privacy.
–Make the applicable feature configurations and click Update.
–Find the phone button template that is available for all Cisco IP Phone models 7960 in the Phone Configuration window, phone button template field.
•After an upgrade to Cisco CallManager release 4.0(1), verify the following phone configuration:
–The field, Phone Button Template, should contain the information, ConsolidatedPhoneTemplate_x, where x is a number that Cisco CallManager assigns.
–The field, Module 1 (and Module 2, if applicable), should contain the information, 7914 14-Button Expansion Module.
How This Feature Affects the User
•Users will now see up to 99 speed dials on the User Options page. To view the speed dials, the user chooses the Add/Update Your Speed Dials link.
Where to Find More Information
•"Cisco IP Phone Configuration," Cisco CallManager Administration Guide
•"Phone Button Template Configuration," Cisco CallManager Administration Guide
•"Cisco IP Phones," Cisco CallManager System Guide
•Customizing Your Cisco IP Phone on the Web
•Cisco IP Phone Guide
Conference and Transfer Enhancements
Cisco CallManager release 4.0 supports several conference and transfer enhancements. The system tears down ad hoc conferences when only two conference participants remain in the conference. This release supports Call Join (join multiple parties on a line into an ad hoc conference) and Direct Transfer (directly transfer two parties on a line to each other without joining the user invoking the Direct Transfer). Participants in an ad hoc conference can list the participants of the conference call, and the originator can selectively drop any participant.
Cisco CallManager supports the following conference call enhancements:
•Join—Using the Join softkey, a user can join up to 15 established calls (for a total of 16) to create an ad hoc conference call.
•Direct Transfer—This enhancement allows a user to transfer two callers on the same line to each other.
•Ad hoc conference—Ad hoc conferences now support multiple concurrent conferences on the same device. When only two participants remain in a conference, Cisco CallManager frees up conference resources and reconnects the two participants in a point-point call.
Note This release does not support Conference bridge chaining for ad hoc conference and barged calls that are created within the cluster.
•Conference List—The conference list feature provides a list of participant directory numbers that are in an ad hoc conference. The name of the participant displays if it is configured in Cisco CallManager Administration. Any participant can invoke the conference list feature on the phone by pressing the ConfList softkey and can view the participants. The conference controller can invoke the conference list feature and can view and remove any participant in the conference by using the Remove softkey.
Note Only the conference initiator can drop any conference party. Any participant in the ad hoc conference can display the list of conference participants if their IP phone has display capabilities. When the ConfList softkey gets pressed, the list of conference participants remains static. The user must press the Update softkey to get the latest list. The list does not update automatically if any participant ends the call or a new participant is added.
Configuration Tips
•To make the conference features available for the user, perform the following procedures:
–Add the Join, RmConf, and Select softkeys by using the Softkey Configuration window.
–Assign the softkey template to the user phone by using the Phone Configuration window.
•Using the Join operation requires conference bridge resources. This release does not support Join across different lines. The total number of participants in the joined call must be less than the configured setting in the Maximum Ad-hoc Conference service parameter. You can configure the number from a default of 4 calls to a maximum of 64 calls depending on the number of calls that the network conference resource can support.
How this Feature Affects the User
•Direct Transfer—When a user has two calls on the same line, the user can transfer the callers to each other. The user highlights the two calls and presses the Select softkey, or when already connected to one call, selects the other call. A check mark appears adjacent to selected calls. After selecting only two calls, the user presses the DirTrfr softkey. The two callers then connect and the user that initiated the direct transfer gets dropped.
•Join—Users can easily join several calls in an ad hoc conference call. With all calls holding on the same line, the user chooses each call for the conference by highlighting the call and pressing the Select softkey. After choosing all calls for the conference, the user presses the Join softkey to establish the ad hoc conference call. A check mark appears adjacent to selected calls. The ad hoc conference remains connected until only two parties remain, and then the conference call reverts to a two-party call.
•List of Conference Participants—Ad hoc conference members can see a list of conference participants by pressing the ConfList softkey. The conference initiator can select a conference participant in the conference list and press Remove to drop the participant from the conference.
Where to Find More Information
•Cisco IP Phones, Cisco CallManager System Guide
•"Softkey Template Configuration," Cisco CallManager Administration Guide
•"Cisco IP Phone Configuration," Cisco CallManager Administration Guide
•Cisco IP Phone Guide
Configurable Call Forward Information Displayed
An administrator can now configure each line on a phone to display the following information for a forwarded call:
•Original Dialed Number (ODN)—This feature, which is enabled by default, causes the original dialed number to display upon call forward.
•Redirected Dialed Number (RDN)—This feature, which is disabled by default, causes the number that was redirected to display upon call forward.
•Calling Line ID (CLID)—This feature, which is enabled by default, causes the caller number to display upon call forward.
•Calling Name ID (CNID)—This feature, which is disabled by default, causes the caller name to display upon call forward.
Configuration Tip
•Configure these fields in the Directory Number Configuration window.
How This Feature Affects the User
•Incoming Call Displays—The Cisco IP Phone can now display both the name and number of the calling party. In addition, if the incoming call was forwarded from a another phone, the phone can display the original called number.
•Outgoing Call Displays—When a user dials a number on the network, the Cisco IP Phone can now display both the called party name and number. If an outgoing call forwards to another phone, the display can provide the "forwarded to" information.
Information might not display for all calls because some network facilities do not support calling and called party displays. Administrators can restrict the use of display information for some calls.
Where to Find More Information
•"Cisco IP Phone Configuration," Cisco CallManager Administration Guide.
Abbreviated Dialing
Abbreviated dialing allows users to quickly access up to 99 speed-dial numbers. While the phone is onhook, users can access the additional speed-dial numbers that are not assigned to speed-dial buttons by using the AbbrDial softkey and an index number.
Configuration Tip
•Administrators configure speed-dial numbers for users in the Phone Configuration window by using the Add/Update Speed Dial link.
How This Feature Affects the User
•Users configure their own speed-dial list by accessing the User Options Menu web page and choosing the Add/Update Your Speed Dials link.
•The user can assign some speed-dial numbers to unused line buttons. The remaining speed dials get assigned to index numbers. Assign these numbers by using the Add/Update Your Speed Dials link in the section called "Speed dials not associated with a phone button."
•To access these speed-dial numbers, the user dials the index number with the phone on-hook and then presses the AbbrDial softkey. The system receives the speed-dial index and dials the associated number.
Where to Find More Information
•"Cisco IP Phone Configuration," Cisco CallManager Administration Guide
•"Cisco IP Phones," Cisco CallManager System Guide
•Cisco IP Phone Guide
Configuring Service URL on Phone Buttons
You can now program phone buttons that are used for lines or speed dial for access to phone services. Use Cisco CallManager Administration to configure the programmable buttons as Service URL buttons for the users phone.
Configuration Tips
•Creating Service URL buttons requires a six-step process:
1. Create an IP Phone service.
2. Create a phone button template to include the service.
3. Add the new phone button template to all phones that require access to the Service URL.
4. Subscribe to the service.
5. Add the Service URL button.
6. Notify users to use the Add/Update Your Service URL Button link on the User Options Menu web page.
How This Feature Affects the User
•Users can program special phone buttons to access a service URL such as FastDials or a weather service. The user accesses the Cisco CallManager User Options Menu web page to subscribe to the phone service and then assigns the service to a Service URL button on the phone.
Where to Find More Information
•"Cisco IP Phones," Cisco CallManager System Guide
•Customizing Your Cisco IP Phone on the Web
Immediate Divert
The Immediate Divert feature immediately diverts a call to a voice-messaging system. Managers and assistants, or anyone who shares lines, use this feature. When the call gets diverted, the line becomes available to make or receive new calls. Both the caller and the called party can use Immediate Divert.
Important Configuration Tips
•Configure this softkey by using the Softkey Template Configuration window of Cisco CallManager Administration.
•The softkey template gets assigned to phones that are in the Cisco CallManager system.
•Feature interaction with route/hunt lists: all calls distributed by a line group will not be diverted to voice messaging.
•No support for immediate divert for inbound calls extended through a Q.SIG trunk.
•No support for immediate divert invocation at hunt list members when the original call is received directly from other than the hunt list.
How This Feature Affects the User
•Users access the Immediate Divert feature by using the iDivert softkey.
•When an incoming call displays on the users phone, the user can choose to answer the call or press the iDivert softkey to send the incoming call to a voice messaging system mail box.
•The called party can divert the incoming call while the call is ringing, after answering the call, or when the call is on hold.
•The calling party can also divert the call to a voice messaging system mail box after the call is connected or when the call is on hold.
Where to Find More Information
•"Immediate Divert," Cisco CallManager Features and Services Guide
Barge and Privacy Enhancements
The Barge and Privacy features work together. Both features work with shared lines only.
Barge and cBarge
Barge adds a user to a call that is in progress. Pressing the Barge or cBarge softkey automatically adds the user (initiator) to the shared-line call (target), and the users currently on the call receive a tone.
Phones support Barge in two conference modes:
•Built-in conference bridge at the target device (the phone that is being barged). This mode uses the Barge softkey.
•Shared (network) conference bridge. This mode uses the cBarge softkey.
Barge supports the following features:
•Three-way barge maximum
•G.711 only
•When the barge target hangs up, the call reverts to a two-way call between the original connected caller and barge initiator, and Cisco CallManager releases the barge resources on the targeted phone.
cBarge includes the following features:
•Creates an ad hoc conference by using network conference resources.
•Maximum number of parties that is supported is based on the Maximum AdHoc Conference service parameter and the maximum number of conference participants that conference bridge resources support.
•Supports all codecs that are available on the conference bridge.
•The conference controller acts as the barge target.
•When two parties are left, Cisco CallManager releases networked conference resources, and the call reverts to a two-party call.
Configuration Tips
•System administrators should not configure both the Barge and cBarge softkeys on one phone.
•cBarge requires availability of network conferencing resource (DSP resource card for bridging media streams during the barge).
•The Party Entrance Tone service parameter has a global effect on Barge, cBarge, Conference, Join, and Meet-Me conference.
•JTAPI and TSP applications do not support barge.
How This Feature Affects the User
•Barge—Users can enter a two-party call on a shared line by pressing the Barge softkey. A party entrance tone alerts the barge targets that a user entered the call.
•Conference Barge—Users can enter a call on a shared line by pressing the cBarge softkey to establish an ad hoc conference call.
Privacy
Privacy lets a user allow or disallow other users of shared-line devices to view its call information or to allow another user to barge into its active calls.
Administrators enable privacy for each device that is sharing a line. Users toggle the Privacy button to enable or disable privacy on their phone. When privacy is enabled, the remote phone that is sharing the line does not display the calling name and number, and remote users cannot barge into a call. Default specifies that Privacy is disabled.
Configuration Tips
•Privacy does not affect call history (missed, placed, received) display on phones with shared-line appearances. If privacy is enabled on phone A and user at phone A places a call on the shared-line appearance, the real-time call information will not display on the other phones; however, the placed call history will show call information on the other phones.
•Cisco CallManager APIs such as JTAP and TSP do not support privacy.
How This Feature Affects the User
•Users can place the phone in privacy mode.
•Users that share lines with a phone in privacy mode cannot barge in to a call.
•Calling name and number do not display on other shared-line phones.
•The administrator assigns the Privacy feature button to a phone, and this affects all lines on the phone. To enable the feature, press the Privacy button. A privacy status icon displays next to the Privacy button and indicates that the Privacy feature is enabled. When Privacy feature is enabled, the user can press Privacy again to disable the feature.
Where to Find More Information
•"Barge and Privacy," Cisco CallManager Features and Services Guide.
Malicious Call Identification
System administrators enable malicious call identification (MCID) service, so a user can identify a suspicious call. While the malicious call is in progress, the user presses the MCID softkey to start the following sequence of events:
•Immediately notifies the Cisco CallManager system administrator by setting an alarm.
•Flags the Cisco CallManager cluster CDR as a malicious call.
•Notifies off-net resources such as the Public Switched Telephone Network (PSTN) of the malicious call, so off-net resources can to take action.
The following devices and features support MCID:
•All SCCP gateways
•MGCP PRI-Backhaul network interface for E1(ETSI) and standard T1(NI2)
•H.323 trunks and gateways
•Extension Mobility
•Conference calls
The system sends notifications of malicious calls through facility information element (IE) messages by using the following protocol standards:
•Q.932-Digital Subscriber Signaling System 1 (DSS 1)—Generic Procedures for the Control of ISDN Supplementary Services
•Q.951.7—Stage 3 description for number identification supplementary service using DSS 1: Malicious Call Identification (MCID)
•EN 300 130-1—ISDN Malicious Call Identification (MCID)
Configuration Tips
•To configure MCID, the administrator must set a service parameter, configure an alarm, add a softkey to a template, and assign the softkey template to the user phone.
•Because QSIG has no standard for MCID the feature does not work on a QSIG connection.
•Intercluster trunks do not support MCID because Cisco CallManager does not support the MCID-T component. MCID-T, a terminating function, accepts an MCID invocation and responds with a success or failure to perform the action.
How This Feature Affects the User
•When the user has access to the MCID feature and is connected to a suspicious call, the user presses the MCID softkey and receives a tone and display (if a display is available) to confirm the action. This action alerts the administrator by setting an alarm and by creating a special CDR record.
Where to Find More Information
•"Malicious Call Identification," Cisco CallManager Features and Services Guide
Annunciator
An annunciator, a Skinny Client Control Protocol (SCCP) device that uses the Cisco IP Voice Media Streaming Application service, enables Cisco CallManager to play prerecorded announcements (.wav files) and tones to Cisco IP Phones, gateways, and other configurable devices. The annunciator, which works with Cisco CallManager Multilevel Precedence Preemption (MLPP), enables Cisco CallManager to alert callers as to why the call fails. Annunciator can also play tones for some transferred calls and some conferences.
Annunciator includes the following features:
•You can use up to two recorded audio WAV files for an announcement.
•Announcements can play once or can repeat at regular intervals.
•The annunciator.xml defines announcements and tones.
•The annunciator device reads the database for service parameters, device settings, user locales, and network (country) locales.
•Annunciator supports Wideband, G.711 mu-law, G.711 a-law, and G.729a codecs.
•Annunciator supports multiple user locales and multiple network (country) locales.
•Annunciator supports up to 400 simultaneous announcements, depending on your network configuration and server capability. The default setting equals 48.
•A single annunciator device gets inserted into the database when you activate Cisco IP Voice Media Streaming Application service in Cisco CallManager Administration.
Where to Find More Information
•"Annunciator," Cisco CallManager System Guide
•"Annunciator Configuration," Cisco CallManager Administration Guide
Multilevel Precedence and Preemption
The Multilevel Precedence and Preemption (MLPP) service, introduced in Cisco CallManager 4.0, allows properly validated users to complete higher-priority calls by preempting lower-priority calls. Higher-priority calls take precedence over lower-priority calls. MLPP complies with ANSI T1.619/T1.619a and Generic Switching Center Requirements (GSCR).
MLPP plays a tone to indicate to users on an IP-to-IP phone call that their call is being preempted. A user with higher precedence can also preempt a call with lower precedence that is made through a gateway. MLPP also provides Alternate Party Diversion (APD), which allows Cisco CallManager to route the priority call to a different phone if the target party does not answer the call.
The following terms pertain to MLPP service:
•Precedence—Priority level that is associated with a call
•Preemption—Process of terminating lower-precedence calls that are currently using the target device such that a call of higher precedence can be extended to or through the device.
•Domain—Subscription option of the originating user determines the domain. Only higher-precedence calls in the same domain can preempt connections that calls in one domain are using.
Administrators configure the MLPP indication, preemption, and domain ID at the device and device pool level. Administrators can configure five precedence levels: Flash Override (highest), Flash, Immediate, Priority, and Routine (lowest). Administrators configure precedence patterns within route patterns and translation patterns.
Users can only preempt lower-priority calls on devices that are in the same domain ID. Predefined audio tones and announcement messages that are sent by the annunciator device notify users of the higher-precedence call.
The following devices currently support MLPP: Cisco IP Phone models 7905, 7912, 7940, and 7960,7970, Cisco IP SoftPhone that uses SCCP, and MGCP-controlled TDM trunks that are using PRI/CAS.
MLPP service exhibits the following features:
•PRI signals MLPP messages. T1-CAS signals via DTMF tones.
•Calling search spaces (CSS) control user permissions to dial a precedence pattern.
•MLPP service does not restrict the construction of route patterns. Typically, a route pattern or translation pattern contains a precedence digit.
•Alternate party target and Ring No Answer (RNA) timer can be configured per line.
•MLPP settings can be configured by using the Bulk Administration Tool (BAT).
From Cisco IP Phone to Cisco IP Phone, a user initiates a precedence call by dialing a well-known route pattern or translation pattern with embedded precedence selectors as part of the pattern. The device's calling search space determines whether the user is authorized for the specified precedence. If the precedence is not authorized, the call does not get extended.
The target of the precedence call receives appropriate visual and/or audible notification of a precedence call, depending upon the relative precedence of the existing calls in progress. If the target user acknowledges the precedence call attempt, the precedence call gets extended to the target.
Provision exists for optional configuration of precedence alternate party diversion target in the event that the target does not acknowledge the precedence call request. If no alternate party target is defined, normal Call Forward No Answer (CFNA) and Call Forward Busy (CFB) paths get followed. Preempted parties on Cisco IP Phones receive a tone until they hang up. Gateway parties simply get disconnected. The system does not permit modifying the precedence level of a call in midcall.
From Cisco IP Phone to trunk, MLPP service first authenticates precedence call setup through an MLPP-enabled gateway that is configured in the Cisco CallManager cluster. If the target gateway is fully subscribed (that is, all DS0s are in use), the precedence of other calls on the route group gets sampled for precedence level. A call with lower precedence gets selected, all participants in the call receive audible notification of the imminent call preemption, and the selected lower-precedence call gets terminated. The selected channel gets reserved, and a precedence call gets extended across the trunk to the destination. Precedence level gets passed over a gateway trunk, but not the domain ID, which should be configured on the trunk.
Configuration Tips
•No support exists for precedence and preemption of ad hoc conference calls.
•MLPP supports single-site deployments. No provision exists for extending a precedence calls and preempting existing calls across an IP trunk.
•MLPP does not support the Lookahead For Busy (LFB) option.
•Annunciator supports only MLPP announcements. The annunciator is not available as a general-purpose annunciator.
How This Feature Affects the User
•When the administrator enables MLPP for a phone, users can perform the following tasks:
–Users can choose a priority (precedence) level for an outgoing call.
–Users can make a priority call.
–Users can receive a priority call.
–Users can accept a higher priority call (preemption).
•When a user makes or receives an MLPP-enabled call, special ring tones, call waiting tones, and icons identify the type of call.
Where to Find More Information
•"Multilevel Precedence and Preemption," Cisco CallManager Features and Services Guide
•"Device Pool Configuration," Cisco CallManager Administration Guide
•"Enterprise Parameters Configuration," Cisco CallManager Administration Guide
•"Associated Alternate Routing Group Configuration," Cisco CallManager Administration Guide
•"Partition Configuration," Cisco CallManager Administration Guide
•"Calling Search Space Configuration," Cisco CallManager Administration Guide
•"Route Pattern/Hunt Pilot Configuration," Cisco CallManager Administration Guide
•"Translation Pattern Configuration," Cisco CallManager Administration Guide
•"Annunciator," Cisco CallManager System Guide
•"Annunciator Configuration," Cisco CallManager Administration Guide
•"Gateway Configuration," Cisco CallManager Administration Guide
•"Cisco IP Phone Configuration," Cisco CallManager Administration Guide
•"Device Profile Configuration," Cisco CallManager Administration Guide
•"Device Profile Defaults Configuration," Cisco CallManager Administration Guide
•Cisco IP Phone administration guide that matches your phone model
•Firmware release notes for your phone model
Attendant Console Enhancements
Cisco CallManager Attendant Console, Release 1.3(1) is compatible with Cisco CallManager, Release 4.0(1). The following list gives Cisco CallManager Attendant Console enhancements:
•Support for Call Queuing—When a call comes in to a pilot point and all hunt groups members are busy, Cisco CallManager answers the call and inserts it into the queue when the queue is not full. If the queue is full, the call gets redirected to "AlwaysRoute" member. If the "AlwaysRoute" member is not configured, the call gets dropped. While the call is in the queue, the call gets put on hold, and MOH plays to the caller. Cisco CallManager redirects the call to the next available hunt group member. When the call is in the queue for longer than the configured HoldTime, the call gets redirected to the "AlwaysRoute" member. If the "AlwaysRoute" member is not configured, no action gets taken. Attendants cannot see calls in the queue.
•Support for broadcast calls—When a call arrives at the broadcast hunting pilot point, Cisco CallManager answers the call and inserts it into the queue if the queue is not full. Cisco CallManager Attendant Console broadcasts the call to all available attendants. If the queue is full, the call gets redirected to "AlwaysRoute" member. If the "AlwaysRoute" member is not configured, the call gets dropped. While the call is in the queue, the call gets put on hold and MOH plays to the caller. Cisco CallManager redirects the call to the attendant who answers the call.
•Support for shared lines—Calls to a pilot point get routed to a shared-line phone only when the shared line is not in use on another remote phone. Attendant phones can share lines with other attendants or non-attendants.
•Multiple calls on a single line—Cisco CallManager Attendant Console supports multiple calls on a single line based on the line setting configuration in Cisco CallManager Administration.
•Support for direct transfer and Join—Direct transfer merges two independent calls into one single call. Join merges a group of calls, including the attendant, into a conference call.
•A configuration tool that enables you to set the JTAPI user name and password, set directory values, enable call queuing for a pilot point, set the queue parameters (such as the queue size and hold time), and configure circular hunt groups and broadcast hunt groups.
Configuration Tips
•You enable queuing for a pilot point by using the Attendant Console Configuration Tool.
•You enable queuing for a pilot point by using the Attendant Console Configuration Tool.
•To configure the number of calls on a line, enter the appropriate value in the Maximum Number of Calls on the Directory Number Configuration window.
•This release reimplements Transfer to Voicemail with JTAPI support. Administrators no longer need to edit the VoiceMailProfiles.xml property file to enable users to access voice messaging system from the Cisco CallManager Attendant Console.
How this Feature Affects the User
•From the Broadcast Calls window in the Attendant Console application, users can view and answer calls.
Where to Find More Information
•"Cisco CallManager Attendant Console," Cisco CallManager System Guide
•"Cisco CallManager Attendant Console Configuration," Cisco CallManager Administration Guide
•"Configuring IP Phones," Cisco CallManager Administration Guide
Cisco CallManager Extension Mobility Enhancements
Cisco CallManager 4.0(1) extends extension mobility functionality to most Cisco IP Phone models. Using Cisco CallManager Administration, you configure a device profile default for each Cisco IP Phone model that you want to support Cisco CallManager Extension Mobility. That phone model then takes on the device profile default whenever a user logs in to a phone model for which the user does not have a user device profile. For example, you can configure a device profile default for the Cisco IP Phone 7905 to allow a user with a user device profile for a Cisco IP Phone 7960 to use Cisco CallManager Extension Mobility on a Cisco IP Phone 7905. The extension mobility functionality has not changed.
Note Check the Cisco IP Phone model documentation to verify that Cisco CallManager Extension Mobility is supported.
Other changes include:
•The service architecture now uses Cisco Tomcat.
•Cisco Extension Mobility designates the renamed extension mobility service.
•The service URL follows:
http://<IP address of server>/emapp/EMAppServlet?device=
#DEVICENAME#•You use Cisco CallManager Serviceability to control the service.
The following access URLs have changed:
•The URL to access Request and Query follows:
http://<IP address of server>/emservice/EMServiceServlet
•The URL to access tools by application follows:
http://<IP address of server>/emservice/jsp/Tools/sampleloginapp.jsp
•The URL to access tools by XML follows:
http://<IP address of server>/emservice/jsp/Tools/XMLFormRequest.html
Where to Find More Information
•"Cisco CallManager Extension Mobility," Cisco CallManager Features and Services Guide
•Device Profile Configuration, Cisco CallManager Administration Guide
•Device Profile Default Configuration, Cisco CallManager Administration Guide
Cisco IP Manager Assistant (IPMA) Enhancement
With Cisco CallManager Release 4.0, an assistant can now support up to 33 different lines. The assistant console supports the new Join and direct transfer feature as well as the sending of DTMF digits from the assistant console. Assistants have the option to automatically launch the assistant console application when they start up their computers. Administrators have the option of not configuring an intercom line for the manager and assistant.
Cisco CallManager release 4.0 supports the use of shared lines between managers and assistants. The assistant shares the manager primary line. New phone button templates and softkey templates support phones in shared-line mode. Cisco IPMA in shared-line mode does not support call routing, and calls to a manager primary line will ring on both the manager and assistant phone.
Configuration Tips for IPMA That Is Using Shared Line
•Manager phone—The manager phone includes a new softkey template called Standard IPMA Shared Mode Manager. This template includes the following softkeys:
–DND—Do Not Disturb (turn ringer off)
–ImmDiv—Immediate Divert (divert the selected call to a preconfigured target)
–TransferToVM—Transfer To Voice Mail (redirect the selected call to the manager voice-messaging mail box)
•IP Phone Service for managers—No IP Phone service for managers exists in shared-line mode
•Assistant Desktop supports the following capabilities:
–Handle calls for managers—When the assistant receives a call on the shared line, the calls show up on the My Calls window under the Manager Lines tree and also on the My Managers window.
–Assistant can view the call state, caller ID, and time in call.
–Assistant can handle calls by using context sensitive buttons or various menus and shortcuts.
–Assistant can also handle calls from the phone, and the state will be reflected on the console
–Assistant can search for people in the corporate/Cisco CallManager directory:
Search on the corporate directory or the Cisco CallManager directory.
Displays up to 25 entries at a time.
Provides call features such as dial, transfer, and conference.
Drag and drop a call to an entry to transfer the call.
Cisco CallManager directory search requires no extra work; however, for corporate directory, the ldapconfig.ini file needs to be updated on the IPMA server.
Configure Dial Rules by using Cisco CallManager Administration.
•Assistant phone
–Two new softkeys added
TrnsfVM—Transfer To Voice Mail (redirect the selected call to the corresponding manager voice-messaging mail box)
ImmDiv—Immediate Divert (redirects the selected call to a preconfigured target)
–Softkeys activated after the assistant logs in from the desktop
–No login required from the phone. Unified login from the desktop
•Release supports Barge and allows invoking barge on a call on a shared line.
•Privacy Release is supported. The call events that have privacy enabled will not display on the console.
Configuration Tips for Both Modes of IPMA
•Multiple calls per line—IPMA supports multiple calls per line, which enables assistants to have multiple calls on the same line and see those calls on the console.
•System supports the Direct Transfer feature from the assistant console.
•System supports the Join feature from the assistant console.
•Dial Digits—The ability exists to send DTMF digits from the console on connected calls.
•Message Waiting Indicator—The assistant console displays the MWI status of the manager phone.
•Auto Start Console on Computer Startup—The assistant preferences have an option to auto start console on computer startup.
Configuration Tips for IPMA That Is Using Proxy Mode
•Call filtering mode—Call filtering mode refers to the operational mode of IPMA where the Assistant Console is configured with a manager proxy line. This proxy line represents s a line appearance that represents the manager line. This line does not get configured with a common DN with that of the manager. In this mode, the system allows call filtering, but Barge and Privacy are not offered.
•Because support for multiple calls per line appearance removes the need to support multiple line appearances on same phone with common DNs, the system does not support common directory number support for multiple lines on same device (manager phone, assistant phone, assistant console). Therefore, the system does not support call rollover from one line to another as configured in Cisco CallManager release 3.3 and earlier in IPMA.
Where to Find More Information
•"Cisco IPMA with Proxy Line Support," Cisco CallManager Features and Services Guide
•"Cisco IPMA with Shared Line Support," Cisco CallManager Features and Services Guide
•Cisco IPMA User Guide
Static Digit Analysis
Prior to Release 4.0 of Cisco CallManager, unregistered devices without configured forwarding got removed from the digit analysis (DA) table and required dynamic digit analysis. Prior to Release 4.0, when a phone unregistered, call processing allowed a call to pass to the next closest match in the Calling Search Space (CSS) list. With the introduction of static DA in Release 4.0, whether a phone is registered or not, the device remains in the DA table, and the directory number intercepts the call.
Configuration Tips
•Administrators should note that the IPMA and PA applications can no longer use translation patterns for failover. Instead, administrators must set up Call Forward No Answer (CFNA) with the data that was in the translation pattern for all IPMA and PA failed route points, and these route points must be removed.
Where to Find More Information
Directory Enhancements
This release of Cisco CallManager includes the following directory enhancements:
•Personal Address Book (PAB)—You cannot search for PAB using a default directory query from Active Directory or other third-party tools.
•DCD reconfiguration scripts are now written in Perl.
•CCMRegbrowser—a new tool to check the DCD version, install status, etc.
•CCMPwrdChanger—a new tool to change the password for special Cisco CallManager users.
Routing Enhancements
Cisco CallManager Release 4.0 supports new routing functionality. A hunt list can contain line groups and route groups.
Note Administrators still use the Hunt Group Configuration window to configure routing for Cisco CallManager Attendant Console.
This release of Cisco CallManager supports the new concept of line groups. Cisco CallManager defines a line group as an ordered list containing one or more valid directory number members and identifies each line group by a unique group name. Administrators can configure the following line group properties:
•Line Group Name
•Ring No Answer (RNA) Reversion Timeout
•Distribution Algorithm
–Top Down (default)
–Circular
–Longest Idle Time
–Broadcast—Cisco CallManager alerts all idle members about the call.
•Hunt Options—Administrators can configure the behavior of the line group to have the following behaviors when the line group receives a no answer, busy, or not available signal:
–Try next member, then try next group in hunt list. This is the default option.
–Try next member, but do not go to the next group.
–Skip remaining members and go directly to next group.
–Stop hunting.
•List of valid directory numbers
Note CTI route points and ports are not allowed.
Route groups function as designed in earlier releases. Support of route groups within a hunt list allows outbound call distribution through VoIP gateways, gatekeepers, H.323 logical trunks, and SIP logical trunks. Route groups do not support RNAR. Route groups support the Top Down and Circular call distribution algorithms.
Route lists have been renamed Route/Hunt List with the following expanded functionality and properties:
•Configurable name and description
•Associated hunt pilot number that is a route pattern. A caller can reach someone by dialing the hunt pilot number.
•Associated line groups. Multiple line groups can be configured in a route/hunt list to create a variety of different hunt possibilities.
•Associated route groups
Note No line groups can follow a route group once a route group is inserted into a route/hunt list.
Route/hunt lists have associated Perfmon counters to track hunt list performance. Performance enhancements support 1500 hunt lists with ten members each with broadcast hunting on an MCS-7835-1400.
Route/hunt lists replace voice-mail forwarding chains in Unity configuration. To effect this change, place voice-mail ports in a line group. For redundant Unity systems, add additional line groups. Set the No Answer Hunt option to "Skip remaining members and go directly to next group."
Configuration Tips
The following caveats exist for line groups, route groups, route/hunt lists, and route patterns/hunt pilots:
•No voice-mail profile exists for a hunt pilot number. Immediate Divert and Call Forwarding to voice mail are not allowed.
•No forwarding is allowed for a hunt pilot number.
•Call pickup is not allowed for a hunt pilot number.
•A caller/application only sees the hunt pilot number as a destination and not the actual number of a person with whom the caller is talking.
•When a parked call reverts to the original caller, the reversion goes back to the hunt pilot and therefore may not go back to the phone that parked the call.
•A hunt list can contain line groups only, route groups only, or line groups followed by route groups only. A line group cannot follow a route group in the same hunt list.
•No call queuing engine is provided with native Cisco CallManager hunt group mechanisms in this release. The Attendant Console hunt groups do have a queuing capability that the TCD service implements.
•No support exists for CTI route points or ports in line groups.
•No support exists for multiple chaining of multiple hunt lists.
•Cisco Call Back is not functional for lines/DNs configured as line group members.
•The iDivert feature is not functional for lines/DNs configured as line group members.
Where to Find More Information
•"Understanding Route Plans," Cisco CallManager System Guide
•"Line Group Configuration," Cisco CallManager Administration Guide
•"Route Group Configuration," Cisco CallManager Administration Guide
•"Route/Hunt List Configuration," Cisco CallManager Administration Guide
•"Route Pattern/Hunt Pilot Configuration," Cisco CallManager Administration Guide
•"Voice Mail Connectivity to Cisco CallManager," Cisco CallManager System Guide
•"Cisco Voice-Mail Port Configuration," Cisco CallManager Administration Guide
•"Cisco Voice Mail Port Wizard," Cisco CallManager Administration Guide
Cisco Unity Voice-Mail Port Adjustments
Migration from Cisco CallManager 3.3(3) to Cisco CallManager 4.0(1) requires adjustments to the voice-mail port settings.
Where to Find More Information
•Refer to the "Cisco Unity Voice-Mail Port Changes" section
Additional Media Resources Support
Cisco CallManager 4.0(1) includes the following new media resource enhancements or features:
•Cisco CallManager provides support for Annunciator, as described in the "Annunciator" section.
•Cisco CallManager supports DTMF relay based on RFC-2833 for Session Initiation Protocol (SIP) trunks.
•Cisco CallManager provides MTP, transcoding, and conferencing support for NM-HD on Cisco 2600XM, Cisco 2691, Cisco 3725, Cisco 3745, and Cisco 3660 gateways.
The following list represents the maximum number of sessions that are available for conferences, transcoding, and MTP with the NM-HD:
–G.711 only conference—24
–G.729 conference—6
–GSM FR conference—2
–GSM EFR conference—1
Tip Maximum number of participants per conference equals 8.
–Transcoding for G.711 to G.729a/G.729ab/GSMFR—24
–Transcoding for G.711 to G.729/G.729b/GSM EFR—18
–For a software MTP (DSP-less with same packetization period for both devices that support G.711 to G.711 or G.729 to G.729 codecs), 500 sessions can occur per gateway; for a hardware MTP (with DSP, using G.711 codec only), 48 sessions can occur per NM-HD.
•Cisco CallManager adds a new type of conference bridge, the Cisco Video Conference Bridge (IPVC-35xx).
Where to Find More Information
•"Cisco DSP Resources for Transcoding, Conferencing, and MTP," Cisco CallManager System Guide
•"Media Termination Points," Cisco CallManager System Guide
•"Transcoders," Cisco CallManager System Guide
•"Conference Bridges," Cisco CallManager System Guide
•"Conference Bridge Configuration," Cisco CallManager Administration Guide
•Cisco IP/VC 3511 MCU and Cisco IP/VC 3540 MCU Module Administrator Guide
Multilevel Administration Access Enhancements
In Release 4.0 of Cisco CallManager, Multilevel Administration (MLA) functions as follows:
•MLA no longer requires separate installation: Cisco CallManager comes with an integrated MLA component. Find MLA functions under the User > Access Rights menu item.
•By default, MLA remains disabled except in the following case: if an upgrade from Cisco CallManager 3.3 with MLA 1.2 takes place, data migrates to the Cisco CallManager 4.0 database, and MLA 1.2 gets uninstalled.
•If a previous Cisco CallManager release had MLA installed, MLA migrates data, enables MLA, and preserves the CCMAdministrator password.
Important Login and Configuration Tips
•Without MLA, login authentication uses the local NT administrative account. If MLA is disabled, log in as the NT administrator.
•With MLA, login authentication changes to use LDAP authentication. The CCMAdministrator or an LDAP user in an MLA user group performs login. If access takes place to virtual directories that are set with basic authentication that MLA does not support, a dialog pop-up window asks for the NT Administrator and password.
•To enable MLA, use the MLA Enterprise Parameters Configuration window under menu item User > Access Rights > Configure MLA Parameters. Set the Enable MultiLevelAdmin field to True and perform an update to the window.
•If MLA is enabled, log in for the first time as the CCMAdministrator. The special login user, CCMAdministrator, represents the only user that can access Cisco CallManager Administration and Serviceability when MLA gets enabled for the first time. This user also represents the only user that can log in even if LDAP is down. This user has full access to all windows.
•Set up the CCMAdministrator password upon enabling MLA. In the case of an upgrade from Cisco CallManager 3.3, the existing CCMAdministrator password remains in effect after installation of Cisco CallManager 4.0.
Where to Find More Information
•"Multilevel Administration Access," Cisco CallManager System Guide
•"Multilevel Administration Access Configuration," Cisco CallManager Administration Guide
QSIG Protocol
Cisco CallManager supports the ISO variant of QSIG that provides connections and some feature transparency between these tested QSIG PBXs:
•Avaya Definity
•Nortel Meridian
•Alcatel 4400
•Siemens Hicom
•Ericsson MD110
•IPC IPMX trading turret key system
•BT Syntegra trading turret system
This release supports the following QSIG supplementary services:
•Configure calling display information on the gateway or on a call-by-call basis by using route patterns and translation patterns. Restrictions for calling name display information include Calling Name Identification Restriction (CNIR) and Connected Name Identification Restriction (CONR).
•Enable the Message Waiting Indicator (MWI) and disable the MWI through application protocol data unit (APDU) messages. Cisco CallManager can send MWI and receive MWI over connections with QSIG PBXs.
•Cisco CallManager implements call diversion by using forward switching and protects calls from going into forwarding loops by using Call Diversion Counters. APDUs carry the call diversion information. Cisco CallManager supports the following supplementary services:
–Call Forward Unconditional (SS-CFU)
–Call Forward Busy (SS-CFB)
–Call Forward No Reply (SS-CFNR)
•Calls transfers to QSIG PBXs by using join, not by reroute. When a call transfers to another PBX, the system synchronizes post-transaction line identification and called or connected identification. Release does not support QSIG path replacement.
Where to Find More Information
•"Understanding IP Telephony Protocols," Cisco CallManager System Guide
•"Gateway Configuration," Cisco CallManager Administration Guide
Session Initiation Protocol (SIP) Trunk
Cisco CallManager Release 4.0 fully supports SIP as it is defined in RFC 2543 bis4 and partially supports the protocol as it is defined in RFC 3261. Administrators can configure SIP trunks to support communication to a SIP network and to support intercluster communication. For calls through a SIP trunk, Cisco CallManager supports initiating the following supplementary services from SCCP devices after the completion of call setup:
•Hold
•Transfer
•Ad hoc conference
•Call Forward (All, Busy, and No Answer)
•Call Pickup
•Call Park
•Join
SIP-initiated supplementary services include the following capabilities:
•Hold when the SIP endpoint initiates it
•Call Forward (Busy/All/No answer)
•Not supported: SIP-initiated Transfer, both blind and consultation transfer
Cisco CallManager supports bidirectional identification for the following services:
•Calling Line Identification (CLID)/Calling Line Identification Restriction (CLIR)
•Calling Party Name Identification (CNID)/Calling Party Name Identification Restriction (CNIR)
•Connected Party Line Identification (COLD)/Connected Party Line Identification Restriction (COLR)
•Connected Party Name Identification (COND)/Connected Party Name Identification Restriction (CONR)
•Redirected Dial Number ID Service (RDNIS) information for voice-messaging support
In addition, Cisco CallManager supports domain name system (DNS) Server (SRV) Resource Record (RR) lookup as specified in RFC 2782, "A DNS RR for Specifying the Location of Services (DNS SRV)."
Cisco CallManager includes session description protocol (SDP) port information to support early media cut-through and faster call setup.
Configuration Tips
•Administrators can restrict the calling or connected party information on the SIP trunk level or on a call-by-call basis by using route patterns, with trunk level restriction taking precedence.
•Currently, the system defines no SIP standard for connected party identification services. Cisco CallManager uses IETF Remote-Party-Id draft to implement these functionalities. If this draft is not implemented by networked SIP devices, connected party identification may not be synchronized with Cisco CallManager controlled devices after supplementary services such as call transfer are invoked.
•Cisco CallManager also supports the RFC 2833, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals." Administrators configure Cisco CallManager to support dynamic payload type for DTMF tones by setting the SIPTelephonyEventPayloadType service parameter.
•Although SIP trunk performance is the same as that of H.323 trunks, all SIP calls require a Media Termination Point (MTP); therefore, sustained calls are limited to the number of available MTP resources that are configured in the Media Resource List. Administrators can configure multiple SIP logical trunks similar to the use of H.323 logical trunks.
•SIP interoperability testing included the following items:
–Cisco SIP-enabled IP Phones
–Cisco SIP-enabled VoIP gateways
–Microsoft Messenger
–G.711 pass-through fax
–Clusters that run Cisco CallManager 4.0(1)
Where to Find More Information
•"Understanding Session Initiation Protocol," Cisco CallManager System Guide
•"Trunk Configuration," Cisco CallManager Administration Guide
•"A DNS RR for Specifying the Location of Services (DNS SRV)," RFC 2782
•"RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals," RFC 2833
Support for Video Calls
This release adds support for video calls. Cisco CallManager Release 4.0 overcomes the high cost of video and the difficulty of use by providing user-friendly access to video calls, including a single number for voice and audio, video calls that are dialed like voice calls, and a single point of administration. Cisco CallManager 4.0 allows integration of video networks with voice networks, which have been separate until now. Enhancements to H.323 and SCCP signaling and call processing within Cisco CallManager allow video calls to be placed with the same model as audio calls.
Cisco CallManager provides a common control agent for setting up configurations, signaling endpoints, and the servicing of voice and video endpoints. This allows Cisco CallManager to provide the following features:
•A uniform dial plan for common calling patterns
•A complete set of serviceability capabilities, including Call Detail Records and Perfmon counters, captures video information
•Call admission control for quality-of-service support through enhancements to regions, locations, and the new Retry Video Call as Audio setting
•Call rerouting
•Support for features currently available on voice phones to video phones such as park, hold, resume, transfer, forward, conference, join, and music on hold
•Support for remote camera control and video endpoint management
•Support for Cisco IP V/C Media Control Units (MCU) using H.323 or SCCP
•H.323 endpoint support for call-routing features such as common dialing, call forwarding, shared lines, and hunt groups. Full H.323 endpoint capabilities depend on their support of the Empty Capability Set (ECS).
•Signaling and media control video awareness. Because Cisco CallManager is aware of the media capabilities of video-capable endpoints, system administrators can more intelligently manage system and user policy.
Cisco CallManager supports the typical video call with two or three RTP streams in each direction by using video codecs H.261 and H.263, as well as current audio codecs plus G.722 and G.728, and far-end camera control. The total bandwidth of a video call comprises the sum of both the audio bandwidth and the video bandwidth plus overhead.
Cisco CallManager Release 4.0 operates with Cisco's current video portfolio, which includes the following devices:
•Cisco IP/VC 3511 (video bridge)
•Cisco IP 3520 (V.35/BRI H.323/H.320 gateway)
•Cisco IP/VC 3525 (PRI H.323/H.320 gateway)
•Cisco IP/VC 3540 (chassis-based bridge/gateway unit)
•IOS H.323 gatekeeper
•Cisco IP/VC 3526 (PRI H.323/H.320 Gateway)
Cisco CallManager Release 4.0 supports existing Cisco IP Phones with video capabilities and extends their capabilities. Release 4.0 also supports new Cisco SCCP-controlled voice-video IP phones, IP phone calls with video on PCs, third-party SCCP room and executive systems, and far-end camera control (FECC) between SCCP endpoints and compatible H.323 endpoints.
Where to Find More Information
•"Understanding Video Telephony," Cisco CallManager System Guide
•"Call Admission Control," Cisco CallManager System Guide
•"Location Configuration," Cisco CallManager Administration Guide
•"Conference Bridge Configuration," Cisco CallManager Administration Guide
•"Media Resource Group Configuration," Cisco CallManager Administration Guide
•"Media Resource Group List Configuration," Cisco CallManager Administration Guide
•"Automated Alternate Routing Group Configuration," Cisco CallManager Administration Guide
•"Route/Hunt List Configuration," Cisco CallManager Administration Guide
•"Gateway Configuration," Cisco CallManager Administration Guide
•"Cisco IP Phone Configuration," Cisco CallManager Administration Guide
•"Trunk Configuration," Cisco CallManager Administration Guide
•Cisco CallManager Serviceability System Guide
•Cisco CallManager Serviceability Administration Guide
H.323 Enhancements
Some H.323 endpoints wait for the far end device to send Terminal Capability Set before sending their own Terminal Capability Set. These endpoints may become deadlocked where neither endpoints send a Terminal Capability Set. The "Active Capability" feature has been added to address this. Prior to Cisco CallManager 4.0, the active capability feature was only active on Intercluster Trunks.
Note Do not enable this feature if your calls are currently working.
Configuration Tips
•You enable active capability by unchecking the Wait for Far End H.245 Terminal Capability Set onH.323 clients, gateways and H.225 trunks.
•Active capability is disabled by default. You cannot disable active capabilities on intercluster trunks; by default, intercluster trunks are active capable.
•Cisco Callmanager may not be able to allocate transcoder resources in some scenarios when capabilities are sent before Cisco CallManager server receives the capabilities of the far end device. When you need a transcoder with Active Capabilities enabled, add the transcoder to the Media Resource Group List (MRGL) that the H.323 devices uses, and check the Media Termination Required check box in the H.323 device configuration. All MTPs and transcoders in the MRGL must support all the codecs that are used by the H.323 device.
•Cisco CallManager does not connect a call when neither endpoint initiate capabilities. Configure one of the endpoints to initiate capabilities.
•H.323 calls may still fail when Cisco CallManager cannot allocate transcoder resources. To ensure that Cisco CallManager allocates transcoder resources for an H.323 call, add the transcoder to the Media Resource Group List and check the Media Termination Required check box in the H.323 device configuration.
Removing a Deleted Subscriber
You delete a subscriber server from the Cisco CallManager cluster by using the Server Configuration window in Cisco CallManager Administration. This deletion, however, deletes the server from the Cisco CallManager Administration database, but not all server dependencies get deleted.
Configuration Tips
1. Remove all dependencies from the server; for example, delete the Cisco CallManager service.
2. Remove the server from Cisco CallManager Administration.
3. Run a script file that removes the SQL replication information from the database.
4. Run a script file that removes the DCD replication agreements from the publisher if Cisco CallManager cluster is integrated with local DCDirectory.
Where to Find More Information
•"Server Configuration," Cisco CallManager Administration Guide
•"Removing a Subscriber Server from Cisco CallManager," Cisco CallManager Administration Guide
Security
You implement authentication and encryption to prevent identity theft of phones and the Cisco CallManager server, data tampering, and call-signaling/media-stream tampering. To alleviate these threats, Cisco CallManager establishes and maintains authenticated communication streams between the phone and the server, digitally signs files before the file is transferred to the phone, and encrypts media streams and call signaling between Cisco IP Phones.
The following information applies to security:
•The Cisco CallManager 4.0(1) cluster boots up in nonsecure mode, and all devices register as nonsecure with Cisco CallManager.
•The Cisco CallManager installation creates a self-signed X.509 certificate for each server in the cluster.
•Encryption installs automatically when you install Cisco CallManager.
•Cisco CallManager supports authentication, integrity, and encryption for Cisco IP Phone to Cisco IP Phone calls in a single cluster where no media services are used.
Configuration Tips
•Not all Cisco IP Phone models support authentication and encryption; refer to the Cisco IP Phone authentication and encryption document, the phone administration guide, or the firmware release notes.
•You cannot implement encryption if authentication does not exist in the cluster; that is, if you do not install and configure the Cisco CTL client.
•Before you install the Cisco CTL client, verify that the workstation or server runs Windows 2000 sp3a (or later) and has a USB port.
•Do not use Terminal Services or Virtual Network Computing (VNC) to install or use the Cisco CTL client.
•To use the Cisco CTL client, you must activate the Cisco CTL Provider service on every server in the cluster that runs the Cisco CallManager or Cisco TFTP services.
•You must obtain at least two Cisco System Administrator Security Tokens, which contain a X.509 certificate, to create the CTL file.
•To update the Cisco CTL file, you must obtain one security token that exists in the current Cisco CTL file.
•The Cisco CallManager cluster can run in either nonsecure or mixed mode, but only mixed mode supports security.
•You set the clusterwide security mode to mixed mode through the Cisco CTL client; you cannot set this parameter in Cisco CallManager Administration.
•With multicluster TFTP configurations, you must configure all Cisco CallManager clusters for the same security mode through the Cisco CTL client. You must install the Cisco CTL client in each cluster and choose the same clusterwide security mode during the configuration.
•Ensure that the TFTP path and alternate TFTP paths for building configuration files are unique; if the paths are not unique, a TFTP server may overwrite the CTL file that the other cluster creates.
•Auto-registration does not work when you configure the cluster for mixed mode.
•After you configure security, the Cisco CallManager server cannot use NETBIOS over TCP to send messages.
•Application Layer Gateways (ALG) that allow Voice over IP to traverse firewalls and Network Address Translation (NAT) do not work with signaling encryption.
•After you configure encryption, management/debug tools that sniff packets do not work.
•Do not use Terminal Services to install the CAPF utility. You can use VNC to install the CAPF utility, but do not use VNC when you use the CAPF utility to generate certificates.
•Use Windows native mode IPSEC for authenticated and encrypted signaling to gateways and other application servers; for example, Cisco Unity, or Cisco IP Contact Center (IPCC), or other Cisco CallManager servers.
•You can use Integrated Windows Authentication.
•In Cisco CallManager Administration, you can disable HTTP and telnet ports for phones.
How This Feature Affects the User
A security enabled phone supports these types of calls:
•Non-secure Call—At least one of the phones or the connection does not support security features.
•Authenticated Call—The system verifies identities of all phones that are connected to the call.
•Encrypted Call—The system encrypts data (conversation) in the call, so no one can listen in, and only the intended recipient receives the call. The system also authenticates encrypted calls.
•A security status icon displays on the phone and identifies the type of security for the connected call.
•Support for encrypted and authenticated calls differs on midrange and high-end phones.
Where to Find More Information
•Cisco IP Phone Authentication and Encryption for Cisco CallManager 4.0(1)
•Cisco IP Phone administration guide that matches your phone model
•Firmware release notes for your phone model
Bulk Administration Tool Enhancements
Bulk Administration Tool (BAT) release 5.0(1) includes the following enhancements:
•The Bulk Administration Tool Wizard guides administrators through bulk configuration tasks with step-by-step procedures that link to the web pages for each task. Administrators can easily update phones and lines by using the BAT web interface.
•Administrator s can use a flexible comma-separated values (CSV) data input file format for phones and user device profiles. Administrators can choose the phone or user device profile fields to use in the CSV file and arrange the order of the fields. The first record of the CSV file shows the customized file format. Values in the CSV file take precedence over template values.
•A BAT report utility generates reports in CSV format with information about phones, users, user device profiles, managers and assistants, and gateway records. Reports do not get generated for the Cisco Catalyst 6000 FXS ports. Administrators can customize reports for phones and user device profiles by selecting and arranging the order of the fields in the report. You can import report data into Microsoft Excel to format and print the report.
•By using a master template, administrators can configure phones or user device profiles with a variable number of lines provided the number of lines is less than or equal to the number of lines in the master template.
•When using the export utility, a new device summary report shows all existing devices in the system with the number of lines that are configured on each device. This report information helps the administrator create queries for BAT export transactions.
•Administrators can use a custom file to update and delete users now, when using queries is not feasible.
Configuration Tips
Be aware of the following limitations:
•You cannot insert user records that are exported from one type of directory into a different type of directory. Exporting user data does not export a user that is his own manager.
•When user records are migrated from Active Directory, passwords do not get exported. Administrators or users will need to assign a password after completing the migration.
•Database changes between releases make it impossible to export records from a former Cisco CallManager release such as 3.3.3 and insert these records into a later Cisco CallManager release such as 4.0.
Where to Find More Information
•Bulk Administration Tool User Guide
Tool for Auto-Registered Phone Support Enhancements
The Tool for Auto-Registered Phone support (TAPS) 5.0(1) has the following enhancements:
•This release separates TAPS installation from the BAT installation. Administrators can perform the TAPS installation once on a server with both Cisco CallManager and Cisco Customer Response Solution.
•TAPS includes a web interface for configuring the TAPS settings. System Administrators can access TAPS administration from the BAT configuration menu.
•Administrators can select different locales and languages for TAPS prompts by using the TAPS administration windows. The first prompt plays in the systemwide user locale default language.
Configuration Tip
•If you are planning to use TAPS to configure shared-line phones, you must create a unique external phone number mask for each shared-line phone.
Where to Find More Information
•Bulk Administration Tool User Guide
CDR Analysis and Reporting (CAR) Enhancements
In Cisco CallManager Release 4.0, the CDR Analysis and Reporting Tool (CAR) supports new hunting features for MLPP and Malicious Call and new conference reports. This release enhances CDR management to export CDR records for date range and allows specific purging.
The following list describes the CAR enhancements for Release 4.0:
•New hunting features
–Route Patterns will now list the configured Route/Hunt List.
–Route/Hunt List will now list the Line Groups in addition to Route Groups
–You can perform Route Pattern searches.
•MLPP (Multilevel Preemption and Precedence) service—New reports and changes for Call Precedence
–Call Summary by Precedence Level
–CDR Search changes by Call Precedence Level
•Malicious Call—New reports and changes for Malicious Call
–Malicious Call Details
–Call Detail Search for Malicious Calls
•CDR Management
–Export CDR/CMR Records obtains the CDR/CMR dump information for the given date range in CSV format.
–You can purge CDR between two dates by using Manual Purge
–No change in Automatic Purge of CDRs
•Conference Reports
–Conference Reports support Cisco CallManager ad hoc and meet me conferences and supports newly added Application Controlled Conference Bridge.
–Conference Call Details Summary Report—Displays the summary information of conference calls that took place during the chosen date/time range.
–Conference Call Details Detailed Report—Displays the detailed information about the conference calls that took place during the chosen date/time range, including information about each participant call leg.
Configuration Tip
•Only the top 50 Route Patterns will be listed in the menu on the left side of the pane.
Where to Find More Information
•Cisco CallManager Serviceability System Guide
•Cisco CallManager Serviceability Administration Guide
Tomcat Web Server
Cisco CallManager 4.0 uses Tomcat 4.1(12) web server and the Tomcat Web Application Manager for Cisco IPMA, Cisco WebDialer, Cisco Extension Mobility, and Cisco CDR Analysis and Reporting.
Configuration Tips
•You can stop and start any individual application without having to restart the Tomcat services.
•Users who belong to the group Administrator within the Microsoft Windows NT domain can access the Tomcat Web Application Manager on the Cisco CallManager server by going to http://<server-name>/manager/list.
New and Changed Information for Cisco CallManager Serviceability
This section describes the following new serviceability features and changes that are pertinent to this release of Cisco CallManager:
•TroubleShooting Trace Setting
•Cisco CallManager Trace Collection Tool
•Real-Time Monitoring Tool (RTMT) as Standalone Plugin
•Serviceability Reports Archive
•SNMP and Performance Counter Enhancements
TroubleShooting Trace Setting
The TroubleShooting Trace Setting tool allows users to set/reset the troubleshooting traces for chosen services in the Cisco CallManager cluster from a single window, as well as set adequate trace (SDI and SDL) settings to troubleshoot Cisco CallManager services. Using this tool, users can choose the required services on different Cisco CallManager nodes in the cluster, so the trace settings of the chosen services get changed to reflect the predetermined trace settings.
Troubleshooting trace settings differ from the default trace settings. The development team for troubleshooting predetermines the troubleshooting trace settings for each Cisco CallManager service. While troubleshooting trace is set, most trace configuration parameters are disabled in the trace configuration windows.
Find the TroubleShooting Trace Setting tool, which is new with Release 4.0(1), in the Trace menu in Cisco CallManager Serviceability.
Cisco CallManager Trace Collection Tool
Release 4.0 removes trace collection for Cisco CallManager from the Trace menu of Cisco CallManager Serviceability Administration and installs as a Cisco CallManager client plugin tool that users can download from the Plugins page and installs on a client machine. This tool collects traces for a Cisco CallManager cluster into a single zip file. The collection includes all traces for Cisco CallManager and logs, such as Event Viewer (Application, System, Security), Dr. Watson log, Cisco Update, Prog logs, RIS DC logs, SQL, and IIS logs.
The Trace Collection Tool collects traces from a remote machine for the following components on chosen servers in the Cisco CallManager cluster:
•Chosen Cisco CallManager services
•Chosen Cisco CallManager applications
•Chosen Cisco CallManager system traces
The Trace Collection Tool collects the traces and saves them in the form of a zip file (as a single file or split into multiple files) by using a different compression factor. You can collect traces for a chosen period or for all available traces.
You can install the Trace Collection Tool on Windows 2000, 98, or XP client.
Real-Time Monitoring Tool (RTMT) as Standalone Plugin
Real-Time Monitoring Tool (RTMT) enhancements provide client-side functionality that did not exist in previous versions of Cisco CallManager. With the 4.0 version, RTMT monitors and reports on typical precanned (preconfigured) alerts. This type of monitoring allows the system administrator to have a comprehensive view of the entire Cisco CallManager cluster with little RTMT configuration. The precanned alerts allow the administrator to be alerted, via e-mail or e-mail pager, about typical Cisco CallManager server or service problems.The precanned reporting allows some minor trending as well as troubleshooting problems after they occur.
The new client-side RTMT plugin continuously monitors real-time behavior of the components in a Cisco CallManager cluster. It uses HTTP and TCP to monitor system performance, critical services, call activity, device status, and CTI applications.
The following list comprises the RTMT enhancements for Cisco CallManager Release 4.0:
•RTMT runs as a standalone java application (prior to Release 4.0, RTMT ran as a java applet).
•Because typical monitoring views are precanned, the majority of desired views come ready to run upon installation.
•Backend Alerting allows system administrators to set up alerts on critical services to send by e-mail or page.
•Service parameter enhancements
•You can install RTMT on remote PC by using the Cisco CallManager Plugins window.
•RTMT includes the following precanned monitors (packaged with RTMT, so no configuration is required by the system administrator):
–Memory and CPU Utilization
–Disk Utilization
–Critical Cisco CallManager and System Services
–Call Activity
–SDL Queue Depth—Shows when Cisco CallManager queues get backed up, which indicates potential poor Cisco CallManager performance.
–Cisco TFTP
–Directory
–Cisco CallManager Heartbeat Information
–Summary of Registered Devices
–CTIManager
•Precanned Alerts (typical Cisco CallManager and system parameters that can detect problems in the network) cam alert the system administrator via e-mail or pager, and administrators can troubleshoot accordingly. The following list comprises the precanned alerts that RTMT includes:
–NumberOfRegisteredPhonesDropped
–NumberOfRegisteredGatewayDevicesDecreased
–NumberOfRegisteredGatewayDevicesIncreased
–NumberOfRegisteredMediaDevicesDecreased
–NumberOfRegisteredMediaDevicesIncreased
–MediaListExhausted
–MgcpDChannelOutOfService
–RouteListExhausted
–CriticalServiceDown
–CallProcessingNodeCpuPegging
–NonCallProcessingNodeCpuPegging
–LowInAvailableMemory
–LowInAvailableDiskSpace
–LowCallManagerHeartbeatRate
–LowTFTPServerHeartbeatRate
–LowTcdServerHeartbeatRate
–DirectoryConnectionFailed
–DirectoryReplicationFailed
–MaliciousCallTrace
–ExcessiveVoiceQualityReports
–CodeYellowEntry
–CodeRedEntry
•Cisco CallManager Serviceability Reporter logs reports and CSV files of key performance counters for troubleshooting and trending. (See the "Serviceability Reports Archive" section for information on viewing the reports that by Reporter generates.) The following reports automatically generate:
–Alert Report (shows what alerts were generated on a daily basis)
–Device Statistics Report
–Server Statistics Report
–Service Statistics Report
•CSV files get saved for the customer, TAC (Technical Assistance Center), or development engineer for use in troubleshooting problems.
Note RTMT continues to monitor real-time behavior of Cisco CallManager components in the background, even when RTMT is not running.
Serviceability Reports Archive
The Cisco CallManager Serviceability Reports Archive allows users to view reports that the NT service Cisco CallManager Serviceability Reporter generates. Reporter generates five daily reports in Cisco CallManager Serviceability Administration: Device Statistics, Server Statistics, Service Statistics, Call Activities, and Alert. Each report provides a summary that comprises different charts that display the statistics for that particular report.
Users can view the reports by accessing Cisco CallManager Serviceability > Tools > Serviceability Reports Archive.
SNMP and Performance Counter Enhancements
Cisco CallManager SNMP for Release 4.0 provides the following changes and enhancements:
•New MIB objects:
–ccmSystemVersion—As the installed version of the local Cisco CallManager system, it matches the system version that displays in the Cisco CallManager Administration main window.
–ccmInstallationId—As the installation component identifier of the local Cisco CallManager component (ccm.exe), it matches the Installation ID that displays in the Cisco CallManager Administration main window.
•A new table, ccmSIPDeviceTable, provides SIP trunk information.
•Dynamic population of product types in CCM MIB means that the CCM MIB will always be up to date with all the new device types that Cisco CallManager supports. A new table, ccmProductTypeTable, provides the list of all the product types that Cisco CallManager supports.
•A new column that was added in each device table in CCM MIB relates to the product type in the ccmProductTypeTable.
•Existing static (enum based) device type definitions are deprecated.
The following SNMP traps, with associated trap objects, that were added alert the system administrator of a malicious call or quality report: ccmMaliciousCall and ccmQualityReport.
•ccmMaliciousCall—This notification gets sent when a user registers a call with the local Cisco CallManager as malicious.
•ccmQualityReport—This notification gets sent when a user reports a quality problem while using the Quality Report Tool.
•ccmQualityReportAlarmEnable flag enables/disables ccmQualityReport Trap.
•Release 4.0 adds Cisco IP Phone 7970 in ccmPhoneType.
•Release 4.0 adds several media device types in ccmMediaDeviceType.
Release 4.0 adds several new performance objects and counters to support new Cisco CallManager features. Release 4.0 adds performance counters for the application-controlled bridge device, annunciator, security, video, hunt lists, SIP, transcoders, MTP, software conference bridge, and hardware conference bridge. The release also renamed and/or deleted some system performance counters.
Where to Find More Information
•Cisco CallManager Serviceability System Guide
•Cisco CallManager Serviceability Administration Guide
New and Changed Information for Third-Party and SDK Applications
This following sections describe new features and changes that are pertinent to this release of Cisco CallManager and third-party and SDK applications.
•Cisco CallManager Call Detail Record Definition
•Cisco CallManager Extension Mobility API Developer Guide Release 4.0(1)
•Cisco IP Phone Services Application Development Notes
•Cisco JTAPI Developer Guide for Cisco CallManager 4.0(1)
•Cisco JTAPI Installation Guide for Cisco CallManager 4.0(1)
•Cisco TAPI Developer and Installation Guides for Cisco CallManager 4.0(1)
Refer to each guide for specific details.
Cisco CallManager Call Detail Record Definition
This section describes any new features and or changes for CDRs that are pertinent to Cisco CallManager release 4.0(1):
•Identifies Multilevel Precedence and Preemption (MLPP)
–Adds the new field origPrecendenceLevel for the precedence level of the originating leg of the call
–Adds the new field destPrecedenceLvel for the precedence level of the destination leg of the call
–MLPP utilizes existing cause codes 8, 9, 46, 50, and 128.
•Identifies malicious calls by adding a new Comment field
•Drop any party feature utilizes existing cause fields: origCause_value and destCause_value.
•OnBehalfOf field contains a new code (value = 14) for the Immediate Divert feature and value = 15 for Barge.
•The following new fields support video in Cisco CallManager:
–origVideoCap_Codec
–destVideoCap_Codec
–origVideoCap_Bandwidth
–destVideoCap_Bandwidth
–origVideoCap_Resolution
–destVideoCap_Resolution
–origVideoTransportAddress_IP
–origVideoTransportAddress_Port
–destVideoTransportAddress_IP
–destVideoTransportAddress_Port
•Adds user login fields (callingPartyLoginUserID and finalCalledPartyLoginUserID) to ensure that a valid UserID is associated with a newly created phone device and is properly reported in CDRs
•Adds CDRView Utility examples for different call scenarios including IDivert, Barge, and cBarge
Cisco CallManager Extension Mobility API Developer Guide Release 4.0(1)
The following list provides the features or changes for Cisco Extension Mobility service API developers in Cisco CallManager release 4.0(1):
•Tomcat Servlet architecture replaces the ASP block.
•Connection from the IIS to the Tomcat server uses the established AJP mechanism.
•The Login Service Java Object runs in the Tomcat Servlet.
•The Tomcat Servlet Logout Scheduler assumes the functionality that the Logout NT Service previously performed and contains a new data structure in the scheduling information.
•Communication from the Extension Mobility service to the DBL uses JNI instead of COM.
Cisco IP Phone Services Application Development Notes
The following list provides the features or changes for Cisco IP Phone developers in Cisco CallManager 4.0(1):
•Cisco IP Phones 7905, 7912, and 7920 support XML services.
•RTP streaming includes the Volume feature.
•The CiscoIPPhoneImageFile object supports advanced higher-resolution displays. The CiscoIPPhoneImageFile object behaves identically to the CiscoIpPhoneImage object except that the image data no longer gets embedded in the XML object by using the <Data> tag. Instead, a <URL> tag points to the PNG image file.
•The CiscoIPPhoneGraphicFileMenu object exposes the touchscreen capability for devices that can receive and process pointer events.
•The IP phone client request to send the relevant information from the IP phone to the web server application includes the following HTTP headers:
–x-CiscoIPPhoneModelName
–x-CiscoIPPhoneDisplay
–x-CiscoIPPhoneSDKVersion
–Accept
•The updated <ExecuteItem> tag of the <CiscoIPPhoneExecute> object with an optional attribute called Priority informs the phone of the urgency of the execute request and whether the phone should be interrupted to perform the request. The Priority levels determine whether the phone must be idle to perform the requested action.
Cisco JTAPI Developer Guide for Cisco CallManager 4.0(1)
The following list provides the features or changes for Cisco JTAPI in Cisco CallManager release 4.0(1):
•Multiple Calls Per DN—Enables applications to have multiple calls on the same line with feature operations.
•Shared Line Support—Provides the following abilities to applications:
–Control shared DN terminals
–Hold a call on one shared DN terminal and unhold the same call from another shared DN terminal
–Make calls between two shared lines
–Initiate a call from one shared-line terminal while another active call exists on another shared-line terminal with the same DN
•Transfer and DirectTransfer—Provides the following enhancements:
–Application can transfer two held calls.
–Application can have one held call and one connected call in any order.
–Application can transfer any two calls that are present on the line.
•Conference and Join—Enhanced to perform Arbitrary Conference of multiple calls.
•Barge, CBarge, and Privacy Event Notification—For Barge and CBarge, Cisco JTAPI supports manual feature activation on the application-controlled IP phones. The system does not support feature activation through the API. The Privacy feature provides a shared address ability to enable or disable other shared addresses to barge into a call.
•CallSelect and UnSelect Even Notification—Provides events for applications when they monitor RemoteInUse terminals. Applications cannot invoke an API on the Passive or InUse TerminalConnection.
•Dynamic CTIPort Registration Per Call—Enables applications to provide an ipAddress and port number for each call or whenever media gets established.
•Media Termination at Route Point—Enables applications to terminate media for all active calls by specifying an ipAddress and port number for each call or whenever media gets established.
•Redirect Set Original Called ID—Provides applications the ability to specify preferred original called party DN apart from the destination party information in the redirect request.
•Single Step Transfer—Provided applications with the following enhancements:
–A new call does not get created.
–CiscoTransferStartEv and CiscoTransferEndEv do not get delivered to applications.
–The state of the original call gets retained if the transfer operation fails.
•Auto Update of API—Provides a facility by which an application at startup can identify itself to a web server via an HTTP request and receives a response with the version of the required JTAPI API. The application compares the version available on the server to the local version in the application classpath and determines whether an upgrade is necessary.
•CiscoTerminal Filter and ButtonPressedEvents—Enables applications to receive the CiscoTermButtonPressedEv when a digit gets pressed on the phone.
•Modifying Calling Number—Enables applications to modify the calling party in the select route API from a route point.
•AutoAccept support for CTIPort and RoutePoint—Provides applications the ability to enable or disable AutoAccept for the addresses on the CTIPort and RoutePoint. When changes occur to AutoAccept on the address, the application receives CiscoAddrAutoAcceptStatusChangedEv on AddressObservers.
•CiscoTermRegistrationFailed event—Provides the applications with an event when CiscoMediaTerminal or CiscoRouteTerminal registration asynchronously fails.
•SelectRoute Interface Enhancement—Enhances the SelectRoute interface to take the parameters "PreferedOriginalCalledNumber" and "PreferedOriginalCalledOption," which enables applications to reset the OriginalCalled value to a specified "PreferedOriginalCalledNumber" when the call gets routed.
•Presentation Indicator (PI) for the Call—Provides applications with the ability to hide or reveal Calling/Called/CurrentCalling/CurrentCalled/LastRedirecting parties name and number to the end user.
Cisco JTAPI Installation Guide for Cisco CallManager 4.0(1)
Auto Install for Upgrades provides a facility by which an application at startup can identify itself to a Cisco CallManager web server via an HTTP request and receive a response with the version of the required JTAPI API. The application compares the version that is available on the server to the local version in the application classpath and determines whether an upgrade is necessary.
The application makes changes in the init process to instantiate an updater API to discover the server-installed component and download the component as needed.
The feature allows applications to refresh the jtapi.jar component to match the Cisco CallManager, and also a way to centrally deploy the jtapi.jar to which applications can auto update.
Packaging for the API that is required to perform this functionality comes in the form of an updater.jar. jtapi.jar, and updater.jar are packaged with a standard manifest that can be used to compare versions. A application does not have to resort to instantiating a Version class because this could make the API write protected from an update.
This feature, when specified with the location and component, downloads jtapi.jar from server and copies it to local directory. The application can either copy downloaded jtapi.jar with its copy by overwriting it or change the classpath to access the new jtapi.jar.
Note Auto Install does not update JTAPI preferences, TAPITestTools, updater.jar, and javadoc components. If applications require these components, install JTAPI from the Cisco CallManager plugin pages.
Cisco TAPI Developer and Installation Guides for Cisco CallManager 4.0(1)
The following list describes the CiscoTSP 4.0 enhancements for Cisco CallManager 4.0:
•Dynamic Port Registration—The Dynamic Port Registration feature allows applications to specify the IP address and UDP port number on a call-by-call basis.
•Media Termination at Route Point—The Media Termination at Route Point feature allows applications to terminate media at route points. This feature enables applications to pass the IP address and port number where they want the call at the route point to have media establish.
The system supports the following features at route points:
–Answer
–Multiple active calls
–Redirect
–Hold
–UnHold
–Blind transfer
–DTMF digits
–Tones
•Redirect Support for Blind Transfer—The Redirect support for blind transfer eliminates problems that arise from the consult call that is created during a blind transfer in the earlier CiscoTSPs and also bring it in accordance with TAPI specification. This means that the system now properly supports lineBlindTransfer().
•Redirect Set Original Called ID—The Redirect Set Original Called ID allows applications to redirect a call on a line to another destination while allowing the applications to set the OriginalCalledID to any value. This request can be used to implement the Transfer to Voice Mail feature (TxToVM).
•Multiple Calls per Line Appearance
–Maximum Number of Calls—In Cisco CallManager 4.0, the maximum number of calls per LA has changed to be database configurable. This means that the CiscoTSP has been enhanced to support more than 2 calls per line on MCD (Multiple Call Display) devices. For non-MCD devices, the CiscoTSP will only support a maximum of 2 calls per line. The absolute maximum number of calls per line appearance specifies 200.
–Busy Trigger—You cannot modify the busy trigger setting by using the CiscoTSP; no changes occur in the TAPI interface that is exposed by the CiscoTSP as a result of this feature, but it will have an effect on applications that use the existing call waiting flag per DN.
–CFNA Timer—The Call Forward No Answer (CFNA) timer changes in Cisco CallManager 4.0 to be database configurable, per DN, per cluster. You cannot configure this timer by using the CiscoTSP, so no changes occur to the CiscoTSP to support this feature, but this change will have an effect on applications that use the CFNA feature of Cisco CallManager.
•Shared Line Appearance—The enhanced CiscoTSP in Release 4.0 supports Shared Line Appearances. The CiscoTSP does not support shared lines on CTI Route Point devices.
•Select Calls—A new softkey, Select, on the IP phones allows a user to select call instances to perform feature activation, such as transfer or conference, on those calls. The CiscoTSP does not support the ability to select calls. The CiscoTSP supports the events that are caused by a user selecting a call on a line that is being monitored by the application. When a call on a line is selected, all other lines that share the same line appearance will see the call state change to dwCallState=CONNECTED and dwCallStateMode=INACTIVE.
•Transfer Changes—The CiscoTSP has removed the lineDevSpecific() - Swap Hold Setup Transfer function. The lineDevSpecific() - Swap Hold Setup Transfer function performs the functionality that is described in behavior #2 and as mentioned is not needed any more because of the addition of the Direct Transfer feature.
•Direct Transfer—The addition of the Direct Transfer feature makes the CiscoTSP function lineDevSpecific() - Swap Hold Setup Transfer obsolete. A TAPI application can invoke the Direct Transfer feature by using the TAPI lineCompleteTransfer() function on two calls that are already in the established state. This also means that the two calls do not have to be initially set up by using the lineSetupTransfer() function.
•Conference Changes—In Cisco CallManager 4.0, the Conference softkey changed, so it always initiates a new consultation call. The Conference softkey can no longer be used to perform "Arbitrary Conference" because that is not necessary any more with the addition of the Join feature.
•Call Join—In Cisco CallManager 4.0, the CiscoTSP exposed the Join feature as a new device-specific function, which will be known as lineDevSpecific() - Join. You can perform this function on two or more calls that are already in the established state. This also means that the two calls do not have to be initially set up by using the lineSetupConference() or linePrepareAddToConference() functions.
•Privacy Release—In Cisco CallManager 4.0, the CiscoTSP was not enhanced to support the Privacy Release feature.
•Barge and cBarge—In Cisco CallManager 4.0, changes in the CallManager allow the TSP to support the events that are caused by the Barge feature. Also in Cisco CallManager 4.0, Cisco CallManager implemented a new feature, cBarge, which always uses the shared conference resource in the Cisco CallManager, also known as a conference bridge, as opposed to the builtin bridge on the phone. In Cisco CallManager 4.0, the TSP does not support an API to invoke either the Barge feature or the cBarge feature. The TSP was only modified to support the events that are caused by the invocation of the Barge and cBarge features.
•TSP Auto Update Functionality—CiscoTSP supports auto update functionality, so the latest plugin can be downloaded and installed on a client machine. The new plugin will be QBE compatible with the connected CTIManager. When Cisco CallManager is upgraded to a higher version, and CiscoTSP auto update functionality is enabled, user will receive the latest compatible CiscoTSP, which will work with the upgraded Cisco CallManager. Do not update CiscoTSP by using Auto Update functionality.
•QoS Support—CiscoTSP 4.0 supports the Cisco baseline for quality of service. No change occurs in the TAPI interface to support QoS.
•Forwarding Changes—A slight change takes place in behavior in CiscoTSP 4.0 in forwarding. In CiscoTSP 4.0 and Cisco CallManager 4.0, the calls that come into the line no longer get forwarded to a voice messaging system.
•Presentation Indication Flag—In Cisco CallManager 4.0, the CiscoTSP enhancement supports this feature. If calls are made via Translation patterns with the all the flags set to Restricted, the CallerID/Name, ConnectedID/Name and RedirectionID/Name get sent to applications as Blank. The LINECALLPARTYID flags will also be set to Blocked if both the Name and Party number are set to Restricted.
•Modified CiscoTSP 4.0 Entities—Several Cisco TAPI device structures, functions, and messages that have been modified in this version enhance overall functionality. This table lists each modified entity and its type.
Changes From CiscoTSP 3.3 to CiscoTSP 4.0
•Line In Service or Out of Service—If the device is out of service, the application should wait for an in-service message before initiating a TAPI request that results in Cisco CallManager interaction. If an application initiates such a request while the device is out of service, CiscoTSP responds with a resource unavailable message.
This represents a change from the behavior in CiscoTSP 3.0. In CiscoTSP 3.0, when a device successfully opened, it was always in-service.
•LINE_CALLINFO—This release added complete support for the fields of the LINE_CALLINFO message in CiscoTSP 3.1. The LINE_CALLINFO parameter dwCalledID correctly reflects the OriginalCalledParty information.
•User Deletion from Directory—In CiscoTSP 3.3, when the TSP user is removed, the TSP now closes all lines and phones and sends LINE_CLOSE/PHONE_CLOSE messages. After doing this, the TSP removes all lines and phones and sends LINE_REMOVE/PHONE_REMOVE messages.
•Removal of lineDevSpecific() - Swap Hold Setup Transfer—In CiscoTSP 4.0, the lineDevSpecific() - Swap Hold Setup Transfer function was removed because of the changes made to the Transfer feature in the Cisco CallManager and because of the addition of the Direct Transfer feature.
•Call Reason Enhancements—In CiscoTSP 4.0, the TSP properly supports call reasons as defined in the TAPI specification.
•Changes to phoneSetDisplay()—In Cisco CallManager 4.0, the message that is sent to the phone in the phoneSetDisplay() API will remain on the phone until the phone is rebooted. To clear the text from the display and see the Cisco CallManager messages again, pass a NULL string, not spaces, in the phoneSetDisplay() API. In other words, ensure that the lpsDisplay parameter is NULL and the dwSize is set to 0.
Important Notes
The following section contains important information that may have been unavailable upon the initial release of documentation for Cisco CallManager Release 4.0(1).
•CSCso79248 Do Not Run installxml.vbs in Unified CM Release 3.3 and Later
•Uninstall CDR Analysis and Reporting Plugin Before Upgrading to Cisco CallManager 4.0(1)
•Locale Installer for Cisco CallManager
•Using TAPS to Configure Shared-line Phones
•Survivable Remote Site Telephony (SRST) Support
•Uninstalling Backup and Restore (BARS) Version 4.0(1)
CSCso79248 Do Not Run installxml.vbs in Unified CM Release 3.3 and Later
In previous releases, during the Unified CM installation, the installxml.vbs VB script got used to parse all the display instances and rules in the XML files, and upload the data into a table in the default database. In Unified CM Release 3.3 and later, the DBInstall.dll function CInstallXML performs the parsing of the XML files.
The troubleshooting guide for Cisco Unified CallManager (and Cisco CallManager) suggests that you can initialize the installxml.vbs script to fix problems with blank parameters after an upgrade. Do not initialize the installxml.vbs script as the troubleshooting guide recommends. Initializing the script erases all service parameters on the server.
Caution Cisco Unified CM releases 3.3.x or later do not use the installxml.vbs script. Running this script erases all Service Parameters in the server.
Uninstall CDR Analysis and Reporting Plugin Before Upgrading to Cisco CallManager 4.0(1)
If you have installed CDR Analysis and Reporting (CAR) plugin on a Cisco CallManger 3.3(4) system, you must perform the following pre-upgrade and post-upgrade tasks when you upgrade to Cisco CallManager 4.0(1) or risk corrupting your CAR database. Refer to Upgrading Cisco CallManager Release 4.0(1) for complete information.
Procedure
Step 1 Uninstall CAR. Be sure to save the CAR database. Click No when you are prompted to remove the ART database.
Step 2 Upgrade to Cisco CallManager Release 4.0(1).
Step 3 Install Cisco CallManager Service Release 4.0(1) or later.
Step 4 Install CAR from the Plugins.
If you upgrade to Cisco CallManager 4.0(1)and you did not follow the recommended steps , see http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCed29872 for more information on how to recover your CAR database.
Locale Installer for Cisco CallManager
You can obtain locale specific versions of the Cisco IP Telephony Network Locale installer for Cisco CallManager 4.0 when they become available at
http://www.cisco.com/kobayashi/sw-center/telephony/callmgr/locale-installer.shtml.
Refer to the readme file that is posted next to the Cisco IP Telephony Locale Installer software for the complete list of supported languages and localized features.
Using TAPS to Configure Shared-line Phones
If you are planning to use TAPS to configure shared-line phones, you must create unique external mask for each shared-line phone. Enter a unique combination of numbers and asterisks (*) for the external mask. For more information, see http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCec20093.
Survivable Remote Site Telephony (SRST) Support
Cisco CallManager 4.01 using Cisco SRST 3.0 does not support the Cisco IP Phone model 7970G. All other Cisco IP Phones are supported in SRST mode.
New Cisco CallManager 4.01 phone features, such as multiple calls per DN, join, direct transfer, immediate divert to voicemail, are not supported in SRST mode.
Uninstalling Backup and Restore (BARS) Version 4.0(1)
If you have installed Cisco IP Telephony Applications Backup and Restore System (BARS) Version 4.0(1), Cisco recommends that you upgrade to BARS version 4.0(2). If you have installed BARS version 4.0(1), do not uninstall this utility without first upgrading to BARS version 4.0(2). Uninstalling BARS 4.0(1) without first upgrading to BARS version 4.0(2) or later may result in users and applications losing access permission to certain files and directories. You can download the latest version of BARS from Cisco.com at http://cisco.com/cgi-bin/tablebuild.pl/cmva-3des.
Adding Cisco CallManager Servers
In Cisco CallManager Administration, make sure that you only add each server once on the Server Configuration window (System > Server). If you add a server using the host name and add the same server using the IP address, Cisco CallManager cannot accurately determine component versions for the server after a Cisco CallManager upgrade. If you have two entries in Cisco CallManager Administration for the same server, delete one of the entries before you upgrade.
Softkey Support for Cisco IP Phone Models 7905 and 7912
Cisco CallManager 4.0(1) allows the administrator to configure the Standard User and Standard Feature softkey templates on the Cisco IP Phone Model 7905 and model 7912; however, these phones do not support all of the Cisco CallManager features available on the softkey templates; for example, Barge. Consult the phone documentation that came with the phone for information about the specific features these model phones support.
Resolved Caveats for Cisco CallManager - Release 4.0(1)
Table 3 lists and describes caveats that were resolved in Cisco CallManager Release 4.0(1).
Tip If you have an account with Cisco.com (Cisco Connection Online), you can use the Bug Toolkit to find caveats of any severity for any release.
To access the Bug Toolkit, log on to http://www.cisco.com/pcgi-bin/Support/Bugtool/launch_bugtool.pl.
Open Caveats for Cisco CallManager - Release 4.0(1)
Table 4 describes possible unexpected behaviors by Cisco CallManager Release 4.0(1). Unless otherwise noted, these caveats apply to all Cisco CallManager 3.0 releases up to and including Cisco CallManager Release 4.0(1).
Tip If you have an account with Cisco.com (Cisco Connection Online), you can use the Bug Toolkit to find caveats of any severity for any release. To access the Bug Toolkit, log on to http://www.cisco.com/pcgi-bin/Support/Bugtool/launch_bugtool.pl.
Documentation Updates
This section provides documentation changes that were unavailable when the Cisco CallManager Release 4.0(1) documentation suite was released.
Errors
This section contains errors that are contained in the Cisco CallManager Documentation suite.
Installation and Upgrade Document References Incorrect Version of Backup and Restore (BARS)
The documents, Installing Cisco CallManager Release 4.0(1) and Upgrading Cisco CallManager Release 4.0(1) refer to Cisco IP Telephony Applications Backup and Restore System (BARS) Version 4.0(1). BARS Version 4.0(2) replaces BARS Version 4.0(1), so instead, you should install and configure Cisco IP (BARS) Version 4.0(2) or later.
Cisco Video Link Codec
Cisco CallManager documentation incorrectly references a Cisco Video Link codec. For Cisco Video Link codec, read wideband video codec. Any other references to Cisco Video Link are not valid.
Cisco IP Communicator
Cisco CallManager documentation incorrectly references Cisco IP Communicator. Cisco CallManager Release 4.0(1) does not support Cisco IP Communicator. For complete information, see http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCed55971.
Malicious Call Identification
The Cisco CallManager Features and Services Guide identifies a PRI gateway that uses the MGCP PRI backhaul interface for T1 (NI2) as a gateway that supports MCID. Note, non-standard NI-2 PRI trunk interfaces do not support the Cisco CallManager MCID feature.
Changes
This section contains changes that have occurred since the original release of the Cisco CallManager Release 4.0 documentation. These changes do not currently appear in the current documentation or the online help for the Cisco CallManager application.
Route Pattern/Hunt Pilot Configuration
Provide outside dial tone, Allow overlap sending and Urgent priority are fields that are described in "Route Pattern/Hunt Pilot Configuration," of the Cisco CallManager Administration Guide.
Provide outside dial tone
Outside dial tone indicates that Cisco CallManager routes the calls off the local network. Check this box for each route pattern that you consider to be off-network.
Allow overlap sending
With overlap sending enabled, when Cisco CallManager passes a call to the PSTN, it relies on overlap sending in the PSTN to determine how many digits to collect and where to route the call. Check this box for each route pattern that you consider to be assigned to a gateway or route list that routes the calls to a PSTN that supports overlap sending.
Urgent priority
If the dial plan contains overlapping route patterns, Cisco CallManager would not route the call until the interdigit timer expires (even if it is possible to dial a sequence of digits to select a current match). Check this box to interrupt interdigit timing when Cisco CallManager must route a call immediately.
Troubleshooting Security
Symptom Security Token Locks When You Consecutively Enter an Incorrect Security Token Password
Possible Cause Each Cisco System Administrator Security Token (CSAST) contains a retry counter, which specifies the number of consecutive attempts to log in to the etoken Password window. The retry counter value for the CSAST equals 15. If the number of consecutive attempts exceeds the counter value, that is, 16 unsuccessful consecutive attempts occur, an error message indicates that the security token is locked and unusable. Corrective Action: You cannot reenable a locked CSAST. Obtain additional security token(s) and configure the Cisco CTL file, as described in Cisco IP Phone Authentication and Encryption for Cisco CallManager 4.0(1). If necessary, purchase new security token(s) to configure the file.
Omissions
This section lists new and additional information that is not included in the current Cisco CallManager documentation.
•Fax and Modem Connectivity with Cisco CallManager
•Cisco Unity Voice-Mail Port Changes
Fax and Modem Connectivity with Cisco CallManager
Cisco CallManager supports only modem pass-through technology with voice gateways.
For fax connectivity, Cisco CallManager supports SuperG3 to SuperG3 fax on gateways that provide fax pass-through mode using G.711 codecs. A SuperG3 fax call uses a V.34 modem connection. For SuperG3 to SuperG3 fax calls, no V.21 tones are acknowledged by either of the Cisco gateways. The call is answered as a modem call by using a 2100Hz answer tone plus phase reversal. Both gateways disable echo cancellation (ECAN). SuperG3 must use Error Correction Mode (ECM).
The Cisco fax relay mode supports SuperG3 to SuperG3 fax under the following conditions:
•Use all G.711 codec regions to allow the SuperG3 fax call to complete as a modem-pass-through call. Be aware that this can impact bandwidth usage.
•Force both of the SuperG3 fax machines to use a maximum speed of 14400 bps (G3)
•Force both SuperG3 fax machines to disable ECM causing the fax machine to use 14400 bps with no ECM (G3).
For more information about configuring fax, refer to the Implementing Fax Over IP on Cisco Voice Gateways document on Cisco.com.
Cisco VG248 Analog Phone Gateway
The Cisco VG248 supports legacy fax machines and modems. When using fax machines, the Cisco VG248 uses either the Cisco fax relay or pass-through/up speed technology to transfer faxes across the network with high reliability.
You can connect any modem to the Cisco VG248 by using pass-through mode.
Cisco Catalyst 6000 24 Port FXS Analog Interface Module
The Cisco Catalyst 6000 FXS module also supports fax relay and pass-through/up speed. Fax relay enables compressed fax transmission over the IP WAN and preserves valuable WAN bandwidth for other data applications.
Cisco Unity Voice-Mail Port Changes
This section describes various voice-mail port configurations in Cisco CallManager. Use the scenarios and procedures that follow to ensure that migration from Cisco CallManager 3.3(x) to Cisco CallManager 4.0(1) properly migrates the voice-mail port settings. This section describes voice-mail port configurations in Cisco CallManager 3.3(x) as well as the expected configuration after migration to Cisco CallManager 4.0(1). This section also describes the voice-messaging system changes that take place after you upgrade your system to Cisco CallManager 4.0(1).
This section contains the following topics:
•Changes After Upgrading to Cisco CallManager 4.0(1)
•Before Upgrading to Cisco CallManager 4.0(1)
•Unity Failover Voice-Mail Port Setup
Changes After Upgrading to Cisco CallManager 4.0(1)
You will need to reconfigure a few items to maintain your original voice-mail port functionality, depending on what type of scenario you have set up. You must also change your setup as described in this section.
Things That May Affect Your Setup
If your last voice-mail port is forwarded to a route pattern (gateway or intercluster trunk [ICT]), this configuration will no longer exist after the upgrade. You will need to add the intercluster trunk or gateway to a route group, then add the route group to the corresponding route/hunt list of the route patterns that are attached to the voice-mail pilot number. The route group represents the last member of the route/hunt list.
Note Cisco does not recommend use of the Broadcast distribution algorithm in conjunction with the implementation of voice-mail ports for Cisco Unity.
Line Group Forwarding and Cisco Unity Failover
If you are using the recommended Cisco Unity failover voice-mail port setup, you need to configure the following values for the line groups that are used for the voice-mail ports:
•No Answer: Skip Remaining members and go directly to next group.
•Busy: Try Next member, but do not go to next group.
•Not Available: Skip Remaining members and go directly to next group.
The descriptions of the various scenarios throughout this document provide specific information about these values.
If your final voice-mail port is configured to go to an operator, and the operator is set up to Call Forward No Answer (CFNA) and Call Forward Busy (CFB) back to the voice-mail pilot, you will no longer be able to CFB or CFNA back to the same voice-messaging system. You can add an additional line group that contains the operator line to the voice-mail hunt list.
After an upgrade, the system places the line group where the failover voice-mail ports reside in the route/hunt list that is associated with the hunt list pilot number. You need to manually select the hunt options on the basis of your original configuration.
Changes That You Will Notice After the Upgrade
After the upgrade from previous versions of Cisco CallManager to Cisco CallManager 4.0(1), you will notice the following changes:
•The Cisco Voice Mail Port Configuration window no longer has forwarding fields.
•Voice-mail ports now use line groups, route/hunt lists, and hunt pilot numbers.The system creates these entities automatically after the upgrade if the database contained an existing voice-mail port setup. You need to select the hunt options on the basis of your original configurations.
•The pilot number now represents a route pattern with the same number as the first voice-mail port, but in a different partition. The partition that is used for the pilot number was originally the partition that associated with the first voice-mail port.
•The system places voice-mail ports in a newly created partition during the upgrade process.
•The system places voice-mail ports that are used for MWI and for outbound calls on their own separate line groups, route/hunt lists, and hunt list pilot numbers.
Before Upgrading to Cisco CallManager 4.0(1)
Perform the following step on the voice-mail ports to ensure proper migration:
1. Important: Remove any call forwarding that is set on voice-mail ports that are used only for outbound calls and message waiting indication.
Unity Failover Voice-Mail Port Setup
Two supported failover configurations exist. The following white paper discusses these failover configurations: Cisco CallManager Port Configuration for Cisco Unity Failover (Cisco Unity Versions 4.0 and 3.1(2) and Later).
This section provides example configurations in Cisco CallManager 3.3(x) and then outlines what each configuration should resemble after an upgrade to Cisco CallManager 4.0(1) occurs. Some manual configuration needs to take place after an upgrade to Cisco CallManager version 4.0(1). This section also outlines these changes.
This section covers the following topics:
•Unity Failover Configuration 1 in Cisco CallManager 3.3(x) (Recommended)
•Unity Failover Configuration 1 After Migration to Cisco CallManager 4.0(1) (Recommended)
•Single Cisco Unity Server with Single Cisco CallManager Cluster
•Single Cisco Unity Server with Single Cisco CallManager Cluster in Cisco CallManager 3.3(x)
Unity Failover Configuration 1 in Cisco CallManager 3.3(x) (Recommended)
In this example, on each server, four ports handle incoming calls, and two ports handle outbound calls and MWI. PhoneCSS contains partition(s) that are assigned to subscriber phones, as well as VMPilotNumberPT. VMRestrictedCSS contains only VMRestrictedPT, which is assigned only to VM ports.
Primary Cisco Unity server VM ports configuration:
Port 1: (Line: 2001) Device Settings - CSS = PhoneCSSPort 1: (Line: 2001) Directory Number Settings - Partition = VMPilotNumberPT, CSS = VMRestrictedCSSPorts 2 to 6: (Lines: 2002-2006) Device Settings - CSS = PhoneCSSPorts 2 to 6: (Lines: 2002-2006) Directory Number Settings - Partition = VMRestrictedPT, CSS = VMRestrictedCSSPorts 1 to 6: (Lines: 2001-2006) Call Forwarding Settings on Busy and No Answer CSS = VMRestrictedCSSLine: 2001, CFNA = 3001, CFB = 2002Line: 2002, CFNA = 3001, CFB = 2003Line: 2003, CFNA = 3001, CFB = 2004Line: 2004, CFNA = 3001, CFB = 2001Line: 2005, CFNA = 2001, CFB = Blank (for outbound calls and MWI)Line: 2006, CFNA = 2001, CFB = Blank (for outbound calls and MWI)The following example shows secondary Cisco Unity server VM ports (call does not get sent to operator if all ports are busy or ring no answer [RNA]) configuration:
Ports 1 to 6: (Lines: 3001-3006) Device Settings - CSS = PhoneCSSPorts 1 to 6: (Lines: 3001-3006) Directory Number Settings - Partition = VMRestrictedPT, CSS = VMRestrictedCSSPorts 1 to 6: (Lines: 3001-3006) Call Forwarding Settings on Busy and No Answer CSS = VMRestrictedCSSLine: 3001, CFNA = 3002, CFB = 3002Line: 3002, CFNA = 3003, CFB = 3003Line: 3003, CFNA = 3004, CFB = 3004Line: 3004, CFNA = 3001, CFB = 3001Line: 3005, CFNA = 3001, CFB = Blank (for outbound calls and MWI)Line: 3006, CFNA = 3001, CFB = Blank (for outbound calls and MWI)The following example shows secondary Cisco Unity server VM ports (call gets sent to operator if all ports are busy or RNA) configuration:
Ports 1 to 6: (Lines: 3001-3006) Device Settings - CSS = PhoneCSSPorts 1 to 6: (Lines: 3001-3006) Directory Number Settings - Partition = VMRestrictedPT, CSS = VMRestrictedCSSPorts 1 to 6: (Lines: 3001-3006) Call Forwarding Settings on Busy and No Answer CSS = VMRestrictedCSSLine: 3001, CFNA = 3002, CFB = 3002Line: 3002, CFNA = 3003, CFB = 3003Line: 3003, CFNA = 3004, CFB = 3004Line: 3004, CFNA = operator DN, CFB = operator DNLine: 3005, CFNA = 3001, CFB = Blank (for outbound calls and MWI)Line: 3006, CFNA = 3001, CFB = Blank (for outbound calls and MWI)Unity Failover Configuration 1 After Migration to Cisco CallManager 4.0(1) (Recommended)
In this example, on each server, four ports handle incoming calls, and two ports handle outbound calls and MWI. PhoneCSS contains partition(s) that are assigned to subscriber phones, as well as VMPilotNumberPT. VMRestrictedCSS contains only VMRestrictedPT, which is assigned only to VM ports. The VMPilotPartition gets created automatically and gets assigned to the voice-mail ports.
The following example shows primary Cisco Unity server VM ports configuration:
Ports 1 to 6: (Lines: 2001-2006) Device Settings - CSS = PhoneCSSPorts 1 to 6: (Lines: 2001-2006) Directory Number Settings - Partition = VMPilotPartition, CSS = VMRestrictedCSSThe following example shows secondary Cisco Unity server VM ports configuration:
Ports 1 to 6: (Lines: 3001-3006) Device Settings - CSS = PhoneCSSPorts 1 to 6: (Lines: 3001-3006) Directory Number Settings - Partition = VMPilotPartition, CSS = VMRestrictedCSSThe following example shows Line Groups (calls not sent to operator if all ports are busy or RNA) configuration:
1. Line Group Name: LG2001 includes 2001-2004, with the following settings:
No Answer: Skip remaining members, and go directly to next group (Because this setting is not the default, you must set it manually.)Busy: Try next member, but do not go to next group (Because this setting is not the default, you must set it manually.)Not Available: Skip remaining members, and go directly to next group (Because this setting is not the default, you must set it manually.)2. Line Group Name: LG3001 includes 3001-3004, with the following settings:
No Answer: Try next member, but do not go to next groupBusy: Try next member, but do not go to next groupNot Available: Try next member, but do not go to next groupEnsure that these values are set manually after the upgrade.
The following example shows Line Groups (calls sent to the operator if all ports are busy or RNA) configuration:
Note Configure only incoming line groups; line groups that dial out remain the same.
1. Line Group Name: LG2001 includes 2001-2004, with the following settings:
No Answer: Skip remaining members, and go directly to next groupBusy: Try next member, but do not go to next groupNot Available: Skip remaining members, and go directly to next groupEnsure that these values are set manually after the upgrade.
2. Line Group Name: LG3001 includes 3001-3004 with the following settings:
No Answer: Try next member, but do not go to next groupBusy: Try next member, but do not go to next groupNot Available: Skip remaining members, and go directly to next groupEnsure that these values are set manually after the upgrade.
3. Line Group Name: Operator includes Operator extension (example 1000):
No Answer: Try next member, but do not go to next groupBusy: Try next member, but do not go to next groupNot Available: Try next member, but do not go to next groupAfter an upgrade, a hunt list automatically gets configured as follows:
Hunt List Name: HL2001, includes Line Groups LG2001 and LG3001, and operator LG if used, in this order.After an upgrade, a hunt pilot automatically gets configured as follows:
Hunt Pilot: 2001, Partition: VMPilotNumberPT, Hunt List: HL2001Single Cisco Unity Server with Single Cisco CallManager Cluster
This section outlines the voice-mail port configurations with a single Cisco Unity server and a single Cisco CallManager cluster. The examples describe following configurations:
•Single Cisco Unity Server with Single Cisco CallManager Cluster in Cisco CallManager 3.3(x)
Single Cisco Unity Server with Single Cisco CallManager Cluster in Cisco CallManager 3.3(x)
In this example, voice-mail ports get configured as follows:
Port 1: (Line: 2001) Device Settings - CSS = PhoneCSSPort 1: (Line: 2001) Directory Number Settings - Partition = VMPilotNumberPT, CSS = VMRestrictedCSSPorts 2 to 6: (Lines: 2002-2006) Device Settings - CSS = PhoneCSSPorts 2 to 6: (Lines: 2002-2006) Directory Number Settings - Partition = VMRestrictedPT, CSS = VMRestrictedCSSPorts 1 to 6: (Lines: 2001-2006) Call Forwarding Settings on Busy and No Answer CSS = VMRestrictedCSSLine: 2001, CFNA = 2002, CFB = 2002Line: 2002, CFNA = 2003, CFB = 2003Line: 2003, CFNA = 2004, CFB = 2004Line: 2004, CFNA = 2001, CFB = 2001Line: 2005, CFNA = 2001, CFB = Blank (for outbound calls and MWI)Line: 2006, CFNA = 2001, CFB = Blank (for outbound calls and MWI)Single Cisco Unity Server with Single Cisco CallManager Cluster After Migration to Cisco CallManager 4.0(1)
In this example, voice-mail ports get configured as follows:
Ports 1 to 6: (Lines: 2001-2006) Device Settings - CSS = PhoneCSSPorts 1 to 6: (Lines: 2001-2006) Directory Number Settings - Partition = VMPilotPartition, CSS = VMRestrictedCSSLine groups get configured as follows:
Line Group Name: LG2001 includes 2001-2004 with the following settings:
No Answer: Try next member, but do not go to next groupBusy: Try next member, but do not go to next groupNot Available: Try next member, but do not go to next groupCreate the following line groups for outbound ports:
LG2005, include 2005 and 2006Configure these line groups with the following settings:
No Answer: Stop hunting. (Because this setting is not the default, you must set it manually.)Busy: Stop hunting. (Because this setting is not the default, you must set it manually.)Not Available: Stop hunting. (Because this setting is not the default, you must set it manually.)Hunt lists get configured as follows:
Hunt List Name: HL2001, includes Line Groups LG2001Hunt List Name: HL2004, includes Line Groups LG2004 and LG2001, in that orderHunt List Name: HL2005, includes Line Groups LG2005 and LG2001, in that orderHunt pilot gets configured as follows:
Hunt Pilot: 2001, Partition: VMPilotNumberPT, Hunt List: HL2001Static Digit Analysis
In Release 4.0(1) of Cisco CallManager, the new digit analysis process builds a static digit analysis engine with the patterns that are configured in the database during system initialization. This digit analysis engine reduces the propagation of patterns within a cluster of Cisco CallManagers and makes Cisco CallManager more scalable.
In previous releases, the individual device control process read pattern information from the database and dynamically registered the patterns to the digit analysis process to build its digit analysis engine. Each pattern had a mapping to its control process ID in the digit analysis engine. The control process ID of a pattern got changed dynamically if its associated device was reset or if a Cisco CallManager server restarted. If a change to the control process ID took place, the digit analysis engine had to be changed dynamically, and its contents required propagation to other Cisco CallManager servers. During call processing, the digit analysis engine returned the control process ID of a matched pattern.
In the current release, the digit analysis process reads the pattern information directly from the database to build the static digit analysis engine during Cisco CallManager initialization. With the static digit analysis engine, each pattern has a mapping to its callable endpoint name, which is a NumPlanPkID of the pattern in the database, a unique identifier to a configured pattern in Cisco CallManager. The static digit analysis engine no longer holds the control process ID of a pattern.
Static digit analysis integrates with the changes to the device manager to support all existing functions and features. The device manager includes a table where a NumPlanPkID shows a one-to-one mapping to the control process ID of a pattern. When processing a call, digit analysis asks the device manager to get the control process ID for a matched pattern.
Feature Description
The current Cisco CallManager system has these pattern types: Call Park, Call Forward, Meet-Me Conference, Device, Translation, Call Pickup Group, Route, and Message Waiting. The Device, Translation, and Route pattern types represent static patterns. The digit analysis process reads these patterns directly and inserts them into the static digit analysis engine during the initialization of a Cisco CallManager. Other pattern types (Call Park, Call Forward, Meet-Me Conference, Call Pickup Group, and Message Waiting), which are intercept patterns, remain dynamic patterns. Their individual control process reads the pattern information from the database and then asks the digit analysis process to insert the pattern into the static digit analysis engine via registration messages.
All static patterns remain unchanged until their records are changed in the database. Static patterns do not require propagation, because the database change notification is broadcast to the servers within a cluster. Dynamic patterns still use the existing propagating and updating mechanism to update the static digit analysis engines.
Regardless of its pattern type, each static pattern in the static digit analysis engine has a mapping to its PkID in the NumPlan table in the database. When a device registers its patterns to the device manager, the same PkID gets saved and mapped to its control process ID in the device manager. A new interface between the digit analysis and device manager retrieves the control process ID when a matched pattern is found in the static digit analysis engine during call processing.
Caveat 1
A potential loss of change notification exists in the current Cisco CallManager release. This loss could cause a device that is registered with Cisco CallManager to become unreachable by other devices. The following paragraphs provide troubleshooting for this potential problem.
The most common cause for this problem occurs when the DN that is assigned to the device belongs to a partition that is not contained in the calling search space of other devices. If the calling search space of other devices does contain the partition for that DN, other reasons may apply. For example, the DN was changed only for that device, and the change notification from the database to Cisco CallManager was lost. In Release 4.0(1) of Cisco CallManager, resetting the device may not resolve the problem.
To resolve this problem in Release 4.0(1), remove the DN and re-add the DN to the system. Remove the DN from its device on the Directory Number Configuration window and on the Route Plan Report window. After you remove the DN, add it back in with the same partition, pattern, and other configuration information. The problem should be resolved after you re-add the new DN to Cisco CallManager.
The same workaround applies to route patterns and translation patterns if similar problems exist.
Tip Be sure to document all configurations before removing the patterns.
Caveat 2
Static digit analysis disables the configuration of several applications. These applications rely on the provision of duplicate patterns in the same calling search space. For example, the CTI application may be pattern 5000 in partition A, and a particular phone may be pattern 5000 in partition B. In previous releases, if the CTI route point is down, the phone will ring. With static digit analysis, however, the caller receives a busy tone. This limitation implies that the application failure cannot be handled.
Administrators would normally use Call Forward No Answer and Call Forward on failure to handle application failure, but when the pattern on the CTI route point is 5XXX, a forward destination of 5XXX cannot be configured. To resolve this limitation, you can now perform configuration of X characters in Call Forward destinations.
The following example demonstrates the functionality of digit analysis prior to Release 4.0(1) (with dynamic digit analysis) and in Release 4.0(1) (with static digit analysis) for the IPMA application.
IPMA Example with Digit Analysis Prior to Release 4.0(1)
Given the following configuration
Partitions: IPMA, Managers, EveryoneCSS-I-E: IPMA:EveryoneCSS-M-E: Managers:EveryoneLine-1/CSS-I-E: EveryOne/1000Line-2/CSS-M-E: Manager/1001CTI RP: IPMA/1XXXTranslation Pattern/CSS-M-E: EveryOne/1XXXif the CTI route point (RP) is up, 1000/IPMA:EveryOne calls 1001. The call routes by using the CTI route point IPMA/1XXX.
If the CTI route point is down, 1000/IPMA:EveryOne calls 1001. The call goes through the translation pattern Everyone/1xxx, and the call reaches Manager/1001 after the translation and achieves the goal of the IPMA application.
IPMA Example with Static Digit Analysis in Release 4.0(1)
Given an identical configuration, in Release 4.0(1), you must make the following modification: configure 1xxx as a CFNA mask and CSS-E as a CFNA calling search space for the CTI route point to handle the CTI route point failure case.
In Release 4.0(1), using static digit analysis, the following processing takes place:
•If the CTI route point (RP) is up, 1000/IPMA:EveryOne calls 1001. The call routes through CTI route point IPMA/1XXX. (Routing does not change from previous releases.)
•If the CTI route point is down, 1000/IPMA:EveryOne calls 1001. The call goes to the CTI route point, and its CFNA is triggered. The forwarding feature routes the call through the translation pattern Everyone/1xxx, and the call reaches Manager/1001 after translation.
Without configuring the CFNA in the CTI route point, the translation pattern never gets matched, and the IPMA application fails.
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
Cisco.com
You can access the most current Cisco documentation on the World Wide Web at this URL:
http://www.cisco.com/univercd/home/home.htm
You can access the Cisco website at this URL:
International Cisco websites can be accessed from this URL:
http://www.cisco.com/public/countries_languages.shtml
Ordering Documentation
You can find instructions for ordering documentation at this URL:
http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm
You can order Cisco documentation in these ways:
•Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Ordering tool:
http://www.cisco.com/en/US/partner/ordering/index.shtml
•Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
Documentation Feedback
You can submit e-mail comments about technical documentation to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883We appreciate your comments.
Obtaining Technical Assistance
For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, the Cisco Technical Assistance Center (TAC) provides 24-hour-a-day, award-winning technical support services, online and over the phone. Cisco.com features the Cisco TAC website as an online starting point for technical assistance. If you do not hold a valid Cisco service contract, please contact your reseller.
Cisco TAC Website
The Cisco TAC website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The Cisco TAC website is available 24 hours a day, 365 days a year. The Cisco TAC website is located at this URL:
Accessing all the tools on the Cisco TAC website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a login ID or password, register at this URL:
http://tools.cisco.com/RPF/register/register.do
Opening a TAC Case
Using the online TAC Case Open Tool is the fastest way to open P3 and P4 cases. (P3 and P4 cases are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Case Open Tool automatically recommends resources for an immediate solution. If your issue is not resolved using the recommended resources, your case will be assigned to a Cisco TAC engineer. The online TAC Case Open Tool is located at this URL:
http://www.cisco.com/tac/caseopen
For P1 or P2 cases (P1 and P2 cases are those in which your production network is down or severely degraded) or if you do not have Internet access, contact Cisco TAC by telephone. Cisco TAC engineers are assigned immediately to P1 and P2 cases to help keep your business operations running smoothly.
To open a case by telephone, use one of the following numbers:
Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447For a complete listing of Cisco TAC contacts, go to this URL:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
TAC Case Priority Definitions
To ensure that all cases are reported in a standard format, Cisco has established case priority definitions.
Priority 1 (P1)—Your network is "down" or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.
Priority 2 (P2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.
Priority 3 (P3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.
Priority 4 (P4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
•Cisco Marketplace provides a variety of Cisco books, reference guides, and logo merchandise. Go to this URL to visit the company store:
http://www.cisco.com/go/marketplace/
•The Cisco Product Catalog describes the networking products offered by Cisco Systems, as well as ordering and customer support services. Access the Cisco Product Catalog at this URL:
http://cisco.com/univercd/cc/td/doc/pcat/
•Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press online at this URL:
•Packet magazine is the Cisco quarterly publication that provides the latest networking trends, technology breakthroughs, and Cisco products and solutions to help industry professionals get the most from their networking investment. Included are networking deployment and troubleshooting tips, configuration examples, customer case studies, tutorials and training, certification information, and links to numerous in-depth online resources. You can access Packet magazine at this URL:
•iQ Magazine is the Cisco bimonthly publication that delivers the latest information about Internet business strategies for executives. You can access iQ Magazine at this URL:
http://www.cisco.com/go/iqmagazine
•Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:
•Training—Cisco offers world-class networking training. Current offerings in network training are listed at this URL:
http://www.cisco.com/en/US/learning/index.html
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0401R)