Guest

Cisco Unified Communications Manager (CallManager)

Release Notes for Cisco Unified CallManager Release 4.1(2)

 Feedback

Table Of Contents

Release Notes for Cisco CallManager Release 4.1(2)

Contents

Introduction

System Requirements

Determining the Software Version

Compatibility Matrix and Supported Upgrades

Related Documentation

New and Changed Information

Cisco CallManager Installation, Upgrade, and Backup Enhancements

Installation and Upgrade

Backup

Operating System Installation Guidelines

Upgrading to Cisco CallManager Release 4.1(2)

Before Upgrading to Cisco CallManager 4.12

Requirement for Installation of Java Virtual Machine

JRE Installation

Cisco CallManager Administration Menu Changes

Call Coverage Enhancements

External Call Transfer Restrictions (Trunk-to-Trunk) Enhancements

Drop Ad Hoc Conference Enhancements

H.323 fastStart and T.38 Enhancements

MGCP BRI Endpoint Configuration

Time-of-Day Routing

Forced Authorization Codes/Client Matter Codes

Call Display Restrictions Enhancements

Multilevel Precedence and Preemption Enhancements

Cisco CallManager Attendant Console Enhancements

Cisco CallManager Extension Mobility Enhancements

Cisco IP Manager Assistant Enhancements

Directory Enhancements

Cisco Unity Voice-Mail Port Adjustments and Unity User Integration

Multilevel Administration Access Enhancements

QSIG Protocol Enhancements

Alerting Name

Annex M.1

Call Completion

Call Diversion

Compatibility with Older Versions of QSIG Protocol (ECMA)

Facility Selection and Reservation

Path Replacement

Video Calls Enhancements

Security Enhancements

CTI Super Provider

Bulk Administration Tool Enhancements

New BAT Features

External Call Transfer Restrictions (Trunk-to-Trunk Transfer)

Call Coverage

FAC/CMC

Call Display Restrictions

MLPP Enhancements

QSIG for Alerting Name

Video

Security

CTI Super Provider

CAPF Configuration

Tool for Autoregistered Phone Support Enhancements

Dialed Number Analyzer Enhancements

New and Updated Support for Cisco IP Phone Models 7940/7960

Support for Cisco IP Phone Model 7970

New and Changed Information for Cisco CallManager Serviceability

CDR Analysis and Reporting (CAR) Enhancements

Trace Collection Tool and RTMT Security Enhancements

Trace Configuration Tool

New and Changed Information for Third-Party and SDK Applications

JTAPI and TAPI Enhancements

Important Notes

CSCso79248 Do Not Run installxml.vbs in Unified CM Release 3.3 and Later

Adding Cisco CallManager Servers

Locale Installer for Cisco CallManager

Using the JTAPI Update Utility with CRS

Upgrade Requirements for CRS and Cisco CallManager 4.1

NetMeeting Calls Fail When T.38 is Advertised to NetMeeting

Cisco CallManager Installation Status Bar

CTI Route Point Considerations

Cisco CallManager Extension Mobility Scalability Update

Disabling IPSec for Cisco CallManager Upgrades

Disabling IPSec on the Cisco CallManager Server

Enabling IPSec on the Cisco CallManager Server

Resolved Caveats for Cisco CallManager - Release 4.1(2)

Bug Toolkit

Open Caveats for Cisco CallManager - Release 4.1(2)

Documentation Updates

Errors

Java Runtime Environment

Cisco CallManager Dialed Number Analyzer Service Startup Type

Barging into Encrypted Calls with the Cisco IP Phone Model 7970

Using Valid Characters in Cisco CallManager User IDs

Incorrect Reference in the Cisco CallManager Security Guide

Removing a Subscriber Server from Cisco CallManager

Using Script Files to Remove a Subscriber Server from Cisco CallManager

Changes

Associating H.323 Devices to Users

Omissions

? Icon Displays Incorrect Online Help for Region and Calling Search Space Pop p Windows

Name Change for the Cisco IAD 2400 Gateway Type in Cisco CallManager Administration

Route List Redundancy Configuration

Cisco IP Phone Models 7940/7960 Built-in Bridge and Device Security Considerations

CAPF Interaction When Cisco IP Phone Resets

Using Server Authentication, Third-Party CA Certificates

Using Shared Lines with Encrypted Devices

Reinstalling Dialed Number Analyzer after a Cisco CallManager Upgrade

Personal Directory

Support for the Cisco VG224 Gateway

Obtaining Documentation

Cisco.com

Ordering Documentation

Documentation Feedback

Obtaining Technical Assistance

Cisco Technical Support Website

Submitting a Service Request

Definitions of Service Request Severity

Obtaining Additional Publications and Information


Release Notes for Cisco CallManager Release 4.1(2)


Updated June 23, 2008

These release notes describe the new features and caveats for Cisco CallManager release 4.1(2).


Note To view the release notes for previous versions of Cisco CallManager, go to: http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/index.htm


Before you install Cisco CallManager, Cisco recommends that you review the "Important Notes" section for information about issues that may affect your system.

For a list of the open and resolved caveats for Cisco CallManager release 4.1(2), see the "Resolved Caveats for Cisco CallManager - Release 4.1(2)" section and the "Open Caveats for Cisco CallManager - Release 4.1(2)" section. Updates for these release notes occur with every maintenance release and major release.

To access the documentation suite for voice products, refer to the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/voice/

You can access the latest software upgrades and release notes for Cisco CallManager 4.0 on Cisco Connection Online (CCO) at the following URL:

http://www.cisco.com/public/sw-center/sw-voice.shtml

Contents

These release notes discuss the following topics:

Introduction

System Requirements

Compatibility Matrix and Supported Upgrades

Related Documentation

New and Changed Information

New and Changed Information for Cisco CallManager Serviceability

New and Changed Information for Third-Party and SDK Applications

Important Notes

Resolved Caveats for Cisco CallManager - Release 4.1(2)

Open Caveats for Cisco CallManager - Release 4.1(2)

Documentation Updates

Obtaining Documentation

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.1(2) on a Cisco Media Convergence Server (MCS).

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 an IBM server or an HP server at the following URL:

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.1(2).

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.1(2) and which previous release of Cisco CallManager has upgrade support by referring to the Cisco CallManager Compatibility Matrix 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.1(2). 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.1 at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/4_1/doc_gd.

Along with the documents listed in the Cisco CallManager Document Guide, the following list specifies other related documents for Cisco CallManager release 4.1:

Cisco CallManager Call Detail Record Definition

Cisco IP Phone Services Application Development Notes

Cisco JTAPI Installation Guide for Cisco CallManager 4.1(2)

Cisco JTAPI Developer's Guide for Cisco CallManager 4.1(2)

Cisco TAPI Installation Guide for Cisco CallManager 4.1(2)

Cisco TAPI Developer's Guide for Cisco CallManager 4.1(2)

Cisco CallManager Extension Mobility API Developer's Guide Release 4.1(2)

Cisco CallManager 4.1(2) AXL Programming Guide

Cisco CallManager 4.1(2) AXL Serviceability Programming Interface Guide

Cisco CallManager Dialed Number Analyzer Guide

Cisco WebDialer API Reference

System Error Messages for Cisco CallManager 4.1

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.

Cisco CallManager Installation, Upgrade, and Backup Enhancements

Operating System Installation Guidelines

Upgrading to Cisco CallManager Release 4.1(2)

Requirement for Installation of Java Virtual Machine

Cisco CallManager Administration Menu Changes

Call Coverage Enhancements

External Call Transfer Restrictions (Trunk-to-Trunk) Enhancements

Drop Ad Hoc Conference Enhancements

H.323 fastStart and T.38 Enhancements

MGCP BRI Endpoint Configuration

Time-of-Day Routing

Forced Authorization Codes/Client Matter Codes

Call Display Restrictions Enhancements

Multilevel Precedence and Preemption Enhancements

Cisco CallManager Attendant Console Enhancements

Cisco CallManager Extension Mobility Enhancements

Cisco IP Manager Assistant Enhancements

Directory Enhancements

Cisco Unity Voice-Mail Port Adjustments and Unity User Integration

Multilevel Administration Access Enhancements

QSIG Protocol Enhancements

Video Calls Enhancements

Security Enhancements

CTI Super Provider

Bulk Administration Tool Enhancements

Tool for Autoregistered Phone Support Enhancements

Dialed Number Analyzer Enhancements

New and Updated Support for Cisco IP Phone Models 7940/7960

Support for Cisco IP Phone Model 7970

New and Changed Information for Cisco CallManager Serviceability

New and Changed Information for Third-Party and SDK Applications

Cisco CallManager Installation, Upgrade, and Backup Enhancements

Cisco CallManager 4.1(2) implements the following changes for installation, upgrade, and backup procedures.

Installation and Upgrade

Installation and upgrade enhancements include the following:

The enhanced Cisco CallManager upgrade process records the status of all running services and resets the services to an appropriate state for an upgrade to occur; the system automatically reboots and restarts the upgrade, as necessary.

This enhancement applies to upgrades from Cisco CallManager release 3.3(x) and 4.0(x) to Cisco CallManager release 4.1(2).

You must apply SQL 2000 SP3a before the upgrade from Cisco CallManager release 3.3(x).

The upgrade process requires Cisco IP Telephony operating system (OS) version 2000.2.3 with OS upgrade 2000.2.6 or a fresh installation of OS version 2000.2.6 and the latest service release 2000.2-6-sr3 (or later).


Note This enhancement helps to ensure that the files the system needs are not in use and that the necessary services can be stopped, as required by the upgrade process.


Backup

Backup enhancements include the following:

The Cisco IP Telephony Backup and Restore System (BARS) version 4.0(5) or later supports Cisco CallManager 4.1(2).

Cisco CallManager release 3.3 and later no longer support Cisco IP Telephony Applications Backup Utility version 3.5.


Note Be sure to check the Cisco CallManager Compatibility Matrix for the latest information about supported compatibility combinations. See the "Compatibility Matrix and Supported Upgrades" section for more information.


Where to Find More Information

Installing Cisco CallManager Release 4.1(2)

Upgrading Cisco CallManager Release 4.1(2)

Cisco IP Telephony Backup and Restore System (BARS)

Operating System Installation Guidelines

Cisco recommends that you install Cisco IP Telephony operating system version 2000.2.6 with the latest service release 2000.2-6-sr3 (or later) before you upgrade to Cisco CallManager release 4.1(2).

Where to Find More Information

Installing the Operating System on the Cisco IP Telephony Applications Server, Version 2000.2.6

Upgrading to Cisco CallManager Release 4.1(2)

For detailed information about upgrading to Cisco CallManager 4.1(2), refer to Upgrading Cisco CallManager Release 4.1(2).

To verify which versions of Cisco CallManager are compatible for upgrade, refer to the Cisco CallManager Compatibility Matrix. To obtain the most recent version of this document, go to the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/ccmcomp.htm

If your server runs Cisco CallManager release 4.0(2a), you can upgrade your server to release 4.1(2) by using the web download file that is available at http://www.cisco.com/public/sw-center/sw-voice.shtml.

If your server runs a version of Cisco CallManager release 3.2 or earlier, you must use the Cisco CallManager software kit CD-ROM disks to first upgrade every server in the cluster to the latest version of Cisco CallManager release 3.3 or 4.0 before you can upgrade to a version of Cisco CallManager release 4.1.


Note For information about upgrading to Cisco CallManager release 3.3 or 4.0, refer to the appropriate version of the Upgrading Cisco CallManager document.


You cannot upgrade directly from Cisco CallManager release 3.2 or earlier to Cisco CallManager release 4.1.


Tip Be sure to refer to the Cisco CallManager Compatibility Matrix for important information about the supported upgrade path for each Cisco CallManager release.


Before Upgrading to Cisco CallManager 4.12

Perform the following step on the voice-mail ports to ensure proper migration:

Important: Remove any call forwarding that is set on voice-mail ports that are used only for outbound calls and message waiting indication.

Requirement for Installation of Java Virtual Machine

The Microsoft Java Virtual Machine (MSJVM) technology allows Java applications to run on Microsoft Windows-based computers. Some versions of Microsoft Internet Explorer (a component of the Windows operating systems) included MSJVM, but Microsoft has since discontinued distribution of MSJVM in its software and announced end-of-life support for the product.

MSJVM was installed by default in all client workstation versions of the current Windows operating systems, except for the following versions:

Windows XP Professional with SP1 slipstreamed into the installation

Windows 2000 Server/Professional with SP4 slipstreamed into the installation


Note Because the Cisco CallManager Administration windows depend on remote scripts, which depend on the JVM for web interaction, Cisco CallManager requires the use of JVM on the client machine to ensure that the Cisco CallManager Administration windows display correctly.


If your client machine runs MSJVM, you can continue to use the existing configuration to browse into the Cisco CallManager Administration windows and perform administration tasks.

If you do not have MSJVM installed on your client machine (or if you receive an error message stating that Cisco CallManager cannot detect JVM on the client machine), and you need to perform Cisco CallManager Administration tasks, you must install and configure the Sun Microsystems Java Virtual Machine (JVM) on the client machine. (The Sun JVM comprises part of the Java 2 Runtime Environment—JRE.) In addition, you must configure the browser security to be Java-enabled. See the "JRE Installation" section for information about installing JRE on the client machine.

If you are not sure whether MSJVM is installed on the client machine, you can install the Sun J2RE anyway. You would then have two Java Runtime Environments installed and running on your machine.


Tip If you run two separate JVM products (MSJVM and Sun J2RE) on your client machine, be sure to download and install patches and security updates for each JVM from the appropriate software vendor (Microsoft and Sun).


JRE Installation

As part of the Cisco CallManager installation, the system provides the Sun JRE client software in a zip file that is installed on the Cisco CallManager server.


Note Windows XP/XP Professional includes a built-in tool that handles zip files. If you use Windows 2000 as your operating system, you must obtain a separate compression utility (such as WinZip) to store and access zip files.



Tip Be sure you install Cisco IP Telephony operating system version 2000.2.6 with the latest service release 2000.2-6-sr3 (or later) before you upgrade to Cisco CallManager release 4.1(2).


To install the JRE software on the client PC, follow these steps:

Procedure


Step 1 From the Cisco CallManager server, navigate to the C:\utils\JRE directory and search for the J2RE_Client_<jre version>.zip file.

The following shows an example of the zip file name:

J2RE_Client_1.4.2_05.zip


Note Only the Cisco CallManager Administrator can access the JRE software on the Cisco CallManager server; to enable access to other users, copy the J2RE_Client_<jre version>.zip file to a server that can be shared by all users.


Step 2 Right-click the J2RE_Client_<jre version>.zip file and click Copy to copy the file to your client PC.

Step 3 Double-click the J2RE_Client_<jre version>.zip file to unzip the Sun J2RE installation executable.

Step 4 Double-click the installation executable file on the client PC.

The following shows an example of the installation executable file name:

j2re-1_4_2_04-windows-i586-p.exe


Note The exact name of the installation executable file changes with each version as the new version number is incorporated into the name.


The JRE software installs in the C:\Program Files\Cisco\Java\JRE directory.


Cisco CallManager Administration Menu Changes

Cisco CallManager 4.1(2) contains the following Cisco CallManager Administration menu changes:

The Route Plan menu contains a new submenu item, Class of Control. From the Cisco CallManager Administration window, navigate to Route Plan > Class of Control. Class of Control contains the following submenu items:

Two new submenu items: Time Period and Time Schedule. (See the "Time-of-Day Routing" section for additional information about these submenus.)

Two existing submenu items: Partition and Calling Search Space. (These submenu items moved from the Route Plan menu to the Class of Control submenu in this release.)

This release separates and reorganizes Route and Hunt submenus under Route Plan (Route Plan > Route/Hunt).

Two groups of three submenus—the routing submenus (Route Group, Route List, and Route Pattern) and the hunting submenus (Line Group, Hunt List, and Hunt Pilot)—replace the previous Route Plan > Route Pattern/Hunt Pilot submenu.


Note In Cisco CallManager release 4.0, route/hunt lists comprised line groups followed by route groups. In release 4.1, route lists comprise only route groups and hunts lists comprise only line groups. An existing route/hunt list that contains both line groups and route groups migrates to a hunt list that contains only line groups and a route list that contains only route groups.


The Feature menu includes two new submenu items: Client Matter Code (Feature > Client Matter Code) and Forced Authorization Code (Feature > Forced Authorization Code).

CAPF Report, a new Certificate Authority Proxy Function (CAPF) application submenu item, appears under Device.

By navigating to Device >Device Settings >CAPF Report from the Cisco CallManager Administration window, you can generate a CAPF report to view the certificate operation status, the authentication strings, or the authentication mode for listed devices.


Note Refer to the Cisco CallManager Administration Guide for detailed information about the updated administration configuration windows.


Where to Find More Information

Cisco CallManager Administration Guide

Call Coverage Enhancements

Cisco CallManager 4.1(2) now allows call forwarding on line directory numbers (DNs) to be configured (on Busy/No-answer) based on whether the caller DN is Internal (OnNet) or External (OffNet).

With this release, the system administrator can configure a forwarding point that acts as a personal forwarding point. A call that is placed to a phone can be set up for CFNA or CFB to a hunt group. If the call goes unanswered, it can be forwarded to the Call Forward no-coverage destination (for example, a voice-messaging system or another DN).

Cisco CallManager 4.1(2) allows Hunt Pilot DNs to be configured with forwarding capabilities on "Forward Hunt No Answer" or "Forward Hunt Busy." This change allows greater flexibility for inbound/outbound call hunting.


Note The Hunt Pilot and the Hunt List configuration is now separate from the Route Pattern and the Route List configuration, as described in the "Cisco CallManager Administration Menu Changes" section.


Configuration Tips (for Administrators)

On call forward settings for line DNs, Gateway, Trunk, and Route Pattern settings of OnNet (internal) or OffNet (external), as defined in the "External Call Transfer Restrictions (Trunk-to-Trunk) Enhancements" section, determine the internal/external configuration.

When configuring "Call forward no coverage" on a line DN, ensure that the Busy or No-answer settings for that line DN are configured to forward to a Hunt Pilot DN. Also, ensure that the Hunt Pilot DN is configured with the "Use Personal Preferences" check box enabled in the Forward Hunt Busy/No-answer settings.

To configure a hunt list in Cisco CallManager release 4.1 so that the last resort of a hunt list specifies an external directory number, configure a hunt pilot that specifies the hunt list, and configure the hunt list so that the Forward Hunt No Answer and Forward Hunt Busy fields specify the external directory number.

How This Feature Affects the End User

End users gain additional flexibility in handling call forwarding on internal or external calls.

End users have more options for handling coverage to hunt groups by having calls that are not answered by the hunt group forward to a voice-messaging system or to another DN (such as a cell phone or another hunt group).

Where to Find More Information

Route Group Configuration, Cisco CallManager Administration Guide

Route List Configuration, Cisco CallManager Administration Guide

Route Pattern Configuration, Cisco CallManager Administration Guide

Line Group Configuration, Cisco CallManager Administration Guide

Hunt List Configuration, Cisco CallManager Administration Guide

Hunt Pilot Configuration, Cisco CallManager Administration Guide

Cisco IP Phone Configuration, Cisco CallManager Administration Guide

Understanding Route Plans, Cisco CallManager System Guide

External Call Transfer Restrictions (Trunk-to-Trunk) Enhancements

In previous releases, no configurable option existed to define a call as OnNet (internal) or OffNet (external). Cisco CallManager release 4.1(2) now provides that flexibility at the individual gateway, trunk, and route pattern levels. It also provides a global setting for gateways and trunks.

Cisco CallManager classifies incoming and outgoing calls on the basis of the following settings:

An incoming call gets classified as OnNet or OffNet based on the setting that is configured on the gateway through which the call came into the network.

An outgoing call gets classified as OnNet or OffNet based on the route pattern setting that is used to route the call out of the network.

Cisco CallManager 4.1(2) provides the ability to block OffNet to OffNet transfer that can be enabled by using a clusterwide service parameter, Block OffNet to OffNet Transfer; this field appears under the clusterwide service parameter (Feature - General) in the Service Parameters Configuration window. This new service parameter replaces the Block External to External Transfer service parameter. During upgrade to Cisco CallManager 4.1(2), the new parameter replaces the old service parameter, and the old value (true or false) gets set to the new parameter value.

Ad Hoc Conference Enhancements

Related to the concept of OnNet/OffNet, a new conference feature in this release includes the option to drop an active ad hoc conference when the conference controller drops out. An additional alternative allows you to drop an ad hoc conference when no OnNet parties remain in the conference. Choose the desired option by using the clusterwide service parameter, Drop Ad Hoc Conference. See the "Drop Ad Hoc Conference Enhancements" section and the Cisco CallManager System Guide for additional details.

Configuration Tips (for Administrators)

Use the Call Classification field in the Cisco CallManager Administration Gateway Configuration window to configure H.323 and MGCP gateways with the option for OffNet, OnNet, or Use System Default.

The default value for H.323 and MCGP gateways specifies OffNet.

The default value for intercluster trunks (ICT), or trunks other than SIP trunks, specifies OnNet.

In Cisco CallManager release 4.1, Call Classification replaces the H323 Network Location, MGCP Network Location, and MGCP Network Location OffNet for E1 and T1 service parameters.

To configure trunks and gateways, the administrator can use the Call Classification clusterwide service parameter and choose the Use System Default option for the individual trunks and gateways.

By default, the service parameter specifies OffNet.

You can also configure trunks and gateways individually.

The system considers FXS and phones to be OnNet; you cannot configure them.

Use the setting on the Cisco CallManager Administration Gateway and Trunk Configuration windows to mark an incoming call as OnNet or OffNet.

Use the Cisco CallManager Administration Route Pattern Configuration window to mark an outgoing call as OnNet or OffNet by configuring the following fields:

Call Classification—Use this drop-down list box to classify the call that uses this route pattern as OffNet or OnNet.

Allow Device Override—When you check this check box, the system uses the Call Classification setting of the trunk or gateway that is associated with the route pattern instead of the Call Classification setting on the Route Pattern Configuration window.

How This Feature Affects the End User

If you enable this feature by using the service parameter, the end user cannot transfer an OffNet call to another OffNet call.

The system allows transfer of an OnNet call to another OnNet/OffNet call, and an OffNet call may transfer to an OnNet destination.

The "Cannot Complete Transfer" message displays on the phone when transfer is blocked.

Where to Find More Information

External Call Transfer Restrictions, Cisco CallManager Features and Services Guide

Drop Ad Hoc Conference Enhancements

Cisco CallManager 4.1(2) makes available the option to drop an active ad hoc conference when the conference controller drops out. As an alternative, you can choose to drop an ad hoc conference when no OnNet parties remain in the conference. Choose the desired option by using the clusterwide service parameter, Drop Ad Hoc Conference. The Cisco CallManager System Guide documents this feature, which has been modified from Cisco CallManager release 3.3(x).

Configuration Tips (for Administrators)

Use the setting on the Cisco CallManager Administration Route Pattern Configuration window to mark any call going through it as OnNet or OffNet.

See the "External Call Transfer Restrictions (Trunk-to-Trunk) Enhancements" section for additional configuration tips.

How This Feature Affects the End User

When you choose the option to drop an ad hoc conference when the conference creator leaves and the conference originator hangs up the call, the entire conference terminates.

When the conference originator transfers/redirects or parks the call and another party retrieves the call, the party becomes a virtual controller. When this virtual controller hangs up, the entire conference terminates.

When the option to drop an ad hoc conference when "No OnNet Parties Remain in the Conference" is selected and the last OnNet party moves out of the conference, the entire ad hoc conference terminates.

Where to Find More Information

Conference Bridges, Cisco CallManager System Guide

H.323 fastStart and T.38 Enhancements

Cisco CallManager 4.1(2) provides support for the following enhancements to H.323 fastStart and T.38:

H.323 outbound fastStart, including the following new parameters in the H.225 Trunk and H.323 Gateway Configuration windows:

Enable Outbound fastStart

Codec for Outbound fastStart

Replacement of the H.323 fastStart Inbound service parameter with the Enable Inbound fastStart configuration field in the H.225 Trunk and H.323 Gateway Configuration windows.

T.38 to allow switching from a voice call to a T.38 fax data call.

Where to Find More Information

Understanding Cisco CallManager Voice Gateways, Cisco CallManager System Guide

Gateway Configuration, Cisco CallManager Administration Guide

MGCP BRI Endpoint Configuration

Cisco CallManager 4.1(2) adds a basic rate interface (BRI) endpoint configuration window on the MGCP Gateway Configuration window. The new configuration window contains configurable BRI MGCP backhaul parameters and hardware-specific parameters that you may use to configure a BRI endpoint on the IOS gateway.

Configuration Tips (for Administrators)

Cisco CallManager 4.1(2) includes support for new network modules. (Refer to the following documentation for additional information.)

This release provides support only for ETSI BRI basic-net3 (user side only).

Where to Find More Information

Understanding Cisco CallManager Voice Gateways, Cisco CallManager System Guide

Gateway Configuration, Cisco CallManager Administration Guide

Time-of-Day Routing

The Time-of-Day feature routes calls to different locations based on the time of day when the call is made. For example, during business hours, calls could route to your office(s), and after hours, they could go directly to a voice-messaging system or to your home number.

Configuration Tips (for Administrators)

The time-of-day feature comprises individual Time Periods that are grouped into Time Schedules. You can access these menus from Cisco CallManager Administration by navigating to Route Plan > Class of Control > Time Period (and Time Schedule).

You can associate the Time Schedules with a Partition. (You can access the Partition Configuration window by navigating to Route Plan > Class of Control > Partition from Cisco CallManager Administration.) In the Partition Configuration window, you can choose either the originating device time zone or any specific time zone for the Time Schedule. The system checks the chosen time zone against the Time Schedule when a call is placed to directory numbers in this partition.


Tip Three new configuration windows support the time-of-day feature. These windows appear under the Route Plan > Class of Control submenu option. (The Calling Search Space and Partition Configuration windows also exist as part of this new submenu.)


How This Feature Affects the End User

If the time-of-day feature is enforced, users cannot set certain CFwdAll numbers at certain times. For example, User A Calling Search Space for forwarding has a Time-of-Day configured partition that allows international calls from 8:00 am to 5:00 pm. User A wants to configure a CFwdAll number to an international number. User A can only set this number between the hours of 8:00 am to 5:00 pm because, outside of these hours, the international number will not be in the partitionSearchString that is used to validate the CFwdAll number.

Users cannot reach directory numbers in some partitions that are configured with the time-of-day feature and are not active during the time of call depending upon the configuration of the partitions.

Where to Find More Information

Route Plan Configuration, Cisco CallManager Administration Guide

Time Period Configuration, Cisco CallManager Administration Guide

Time Schedule Configuration, Cisco CallManager Administration Guide

Partition Configuration, Cisco CallManager Administration Guide

Calling Search Space Configuration, Cisco CallManager Administration Guide

Partitions and Calling Search Spaces, Cisco CallManager System Guide

Time of Day Routing, Cisco CallManager System Guide

Forced Authorization Codes/Client Matter Codes

Introduced in Cisco CallManager 3.3(4), Client Matter Codes (CMC) force the user to enter a code to specify that the call relates to a specific client matter. You can assign client matter codes to customers, students, or other populations for call accounting and billing purposes. The Forced Authorization Codes (FAC) feature mandates that the user enter a valid authorization code before the call completes.


Tip In most cases, Cisco CallManager can alert a CTI, JTAPI, or TAPI application that the user must enter a code during a call. When a user places a call, creates an ad hoc conference, or performs a consult transfer through an FAC- or CMC-enabled route pattern, the user must enter a code after receiving the tone. When a user redirects or blind transfers a call through an FAC- or CMC-enabled route pattern, the user receives no tone, so the application must send the codes to Cisco CallManager. If Cisco CallManager receives the appropriate codes, the call connects to the intended party. If Cisco CallManager does not receive the appropriate codes, the system sends an error to the application that indicates which code is missing.


The system writes both the authorization information and the Client Matter Codes information to the Cisco CallManager Call Detail Record (CDR) database.

Configuration Tips (for Administrators)

The Feature menu includes the Forced Authorization Code and the Client Matter Code submenus (Feature > Forced Authorization Code and Feature > Client Matter Code).

The FAC feature requires that users enter an authorization code to reach certain dialed numbers; the CMC feature requires that users enter a client matter code to reach certain dialed numbers. As administrator, you can enable or disable the FAC/CMC feature by configuring the following attributes in the Route Pattern Configuration window:

FAC—Require Forced Authorization Code check box and Authorization Level field—Check the check box to enable the FAC feature and enter a value in the authorization level field.

Authorization Level limits the range to 0-255 inclusive; the administrator defines the number of configured authorization levels.

CMC—Require Client Matter Code check box—Check this box to enable the CMC feature.

When you enable these features, the user receives a prompting tone to enter an authorization code and/or a client matter code. Call processing collects digits until a number is entered or until the interdigit timeout expires. If the authorization level of the user authorization code is greater than or equal to the authorization level of the route pattern, the system processes the call; otherwise, the reorder tone plays. If the client matter code is valid, the system processes the call; otherwise, the reorder tone plays.

In addition to CMC and FAC configuration in Cisco CallManager Administration, you must update route patterns and dial plan documents to reflect that you have enabled or disabled FAC and/or CMC for each route pattern.

A route pattern can have both FAC and CMC enabled. In this case, the system collects the Authorization Code first and then collects the Client Matter Code.

The system does not support FAC/CMC with overlap sending. When you check the Allow Overlap Sending check box, the FAC and CMC check boxes are disabled.

The system writes the authorization description, authorization level, and the client matter code to the CDR to allow the CDR Analysis and Reporting Tool (CAR) to create reports for FAC/CMC calls. (For security purposes, the authorization code does not get written to the CDR.)

How These Features Affect the End User

If the administrator enables and defines FAC/CMC codes and configures route patterns to use them, the user receives a prompt to enter a code when making a call.

Users can press # on the phone to immediately route a call after entering the code.

Users can start entering the code before the tone completes.

The phone plays a reorder tone when the user enters an invalid code.

After dialing the phone number, hearing-impaired users should wait 1 or 2 seconds before entering the authorization or client matter code.

Cisco IP SoftPhone cannot play tones; however, after a Cisco SoftPhone user dials a directory number, the user can use CMC and FAC by waiting 1 or 2 seconds before entering the code.

When a user presses the Redial softkey on the phone, the user must enter the authorization code or CMC when the dialed number is routed through an FAC- or CMC-enabled route pattern.

The user cannot configure FAC or CMC for speed-dial buttons.

Cisco WebDialer does not support FAC or CMC.


Note See the "CDR Analysis and Reporting (CAR) Enhancements" section for more information about the FAC/CMC reports that are available under the CAR Configuration window.


Where to Find More Information

Understanding Route Plans, Cisco CallManager System Guide

FAC/CMC, Cisco CallManager Features and Services Guide

Call Display Restrictions Enhancements

The Call Display Restrictions feature allows administrators to choose the information that displays for calling and/or connected lines, depending on the parties involved in the call. By using specific configurable Calling and Connected party restrictions on the Cisco CallManager Administration Translation Pattern Configuration window, call display information may be presented or restricted for each call.

Cisco CallManager 4.1(2) provides enhancements to this feature over Cisco CallManager 4.0. Specifically, the Phone Configuration window provides a new Ignore Presentation Indicators (internal calls only) check box that, when set, ignores presentation settings of the remote party for internal calls. For incoming external calls, the system respects the received presentation indicators even if the flag is set. The User Device Profile and Device Profile Default Configuration windows also provide this check box.

Configuration Tips (for Administrators)

The basis for the functionality of the Call Display Restrictions feature relies on calls always being routed through different translation patterns before the calls are extended to the actual device. Configuring partitions and calling search spaces, along with translation patterns, make this possible. (In a hotel environment, this will ensure that, when two rooms are in a call, display information does not become visible across parties.)

Configure partitions and calling search spaces before you add a translation pattern.

Configure translation patterns with different levels of display restrictions.

Check the Ignore Presentation Restriction (internal calls only) check box to ensure that the call information display for internal calls is always visible. (Phones that are used at hotel front desks usually require this characteristic.)

Be aware that the translation pattern configuration at the terminating end can override the originating cluster settings for outgoing calls.

Configure individual, associated translation patterns for each individual Call Park directory number to preserve the Call Display Restrictions feature; configuring a single translation pattern to cover a range of call park numbers does not work with Call Display Restrictions.

For users who log in to phones that are enabled for Extension Mobility, configure the Ignore Presentation Indicators (internal calls only) setting from the Cisco CallManager Administration User Device Profile window as well as from the Phone Configuration window.

How This Feature Affects the End User

This feature, which is well-suited to the hospitality industry, ensures that the display information is secured from public viewing (by the usage of translation patterns along with partitions and calling search spaces).

The phones that have the Ignore Presentation Indicators (internal calls only) check box checked, however, always display the call information of the remote, internal party. Even when this flag is set, phones honor the call restrictions on external calls.

Where to Find More Information

Call Display Restrictions, Cisco CallManager Features and Services Guide

Phone Configuration, Cisco CallManager Administration Guide

Device Profile Configuration, Cisco CallManager Administration Guide

Translation Pattern Configuration, Cisco CallManager Administration Guide

Multilevel Precedence and Preemption Enhancements

Cisco CallManager 4.1(2) provides the following Multilevel Precedence and Preemption (MLPP) enhancements.

Defense Switched Network (DSN) Features

MLPP includes the following features for the DSN:

Support for secure communication by using legacy BRI and analog secure endpoints (STE/STU) and support for IP-STE, including A, B, C, D digit dialing and V150 subset support.

Support for missing certification requirements (Signal IE).

Defense Red Switched Network (DRSN) Features

MLPP includes the following features for the DRSN:

Support for MLPP-enabled, UUIE-based PRI-4ESS interface.

Support for Executive Override precedence level.

Location-based MLPP through locations over intracluster and intercluster limited bandwidth WAN links for DRSN.

Support for intercluster MLPP announcements.

Configuration Tips (for Administrators)

Cisco CallManager 4.1(2) includes the following configuration enhancements:

Four new Cisco CallManager Service Parameters:

Enable Location-based MLPP Feature

Executive Override Call Preemptable

H225 T305 Timer

PRI 4ESS UUIE Device Type

UUIE Configuration on MGCP PRI Gateway Configuration window for 4ESS protocol:

Passing Precedence Level Through UUIE

Security Access Level

V150 (subset): Configuration on MGCP PRI/CAS Gateway Configuration window.

MLPP Indication: Configuration on Intercluster and Gatekeeper controlled trunks on the Trunk Configuration window.

IP-STE: New Skinny phone available.

SCCP IOS GW Available: Configuration similar to MGCP Gateway configuration except endpoints are Skinny Analog and BRI phones:

Five GW types, 269X, 26XX, 3725, 3745, and VG224, support the new SCCP protocol.

In Add a New Gateway window, the system makes available both MGCP and SCCP protocols for five gateway types, 269X, 26XX, 3725, 3745, and VG224. (Choose gateway type and either MGCP or SCCP protocol type.)

On the Translation Pattern and Route Pattern Configuration windows, the system makes highest precedence level Executive Override available.

You can configure A, B, C, D digits and Transformation Masks on Route Pattern and Translation Pattern Configuration windows.

CDR changes for Executive Override calls.

Changes to the precedence level, as shown by the previously displayed/CDR display for precedence level:

(0) Flash Override/Executive Override

(1) Flash/Flash Override

(2) Immediate/Immediate

(3) Priority/Priority

(4) Routine/Routine

How This Feature Affects the End User

Additional Executive Override precedence enables higher precedence than the existing Flash Override precedence.

IP-STE may have limited features (especially in secure mode).

IOS Skinny endpoints (BRI and analog) include very limited features, one call, one-line phones.

Where to Find More Information

Multilevel Administration Access, Cisco CallManager Feature and Services Guide

Route Pattern Configuration, Cisco CallManager Administration Guide

Translation Pattern Configuration, Cisco CallManager Administration Guide

Gateway Configuration, Cisco CallManager Administration Guide

Trunk Configuration, Cisco CallManager Administration Guide

Call Admission Control, Cisco CallManager System Guide

Understanding Cisco CallManager Trunk Types, Cisco CallManager System Guide

Understanding Cisco CallManager Voice Gateways, Cisco CallManager System Guide

Cisco IP Phone Administration Guide for Appropriate phone model

Cisco CallManager Attendant Console Enhancements

Cisco CallManager 4.1(2) contains the following Attendant Console enhancements:

Cisco CallManager Attendant Console 1.4(1) contains accessibility features, such as mouse-less operation (using only keyboard shortcuts), to assist visually impaired or blind attendants with using the attendant console.

Cisco CallManager Attendant Console supports screen readers such as JAWS. The screen reader provides information about the status of the attendant console and about the text in various windows.

Attendants can enable audible alerts to indicate various call events.

Attendants can enable accessibility messages, so dialog boxes display information about the status of the attendant console, such as when call control goes up or down.

How This Feature Affects the User

The default values for the keyboard shortcuts of some actions changed to avoid conflicts with JAWS shortcuts.

The attendant can choose whether to enable audible alerts.

The attendant can choose whether to enable accessibility messages.

The attendant can choose whether to put calls on hold during a transfer, consult transfer, or conference.

Where to Find More Information

Cisco CallManager Attendant Console User Guide

Cisco CallManager Extension Mobility Enhancements

Cisco CallManager 4.1(2) contains the following changes for Extension Mobility:

Changes to comply with JTAPI.

Changes for MSJVM removal.

Support for the Call Display Restrictions feature.

Configuration Tips (for Administrators)

To set up Call Display Restrictions, check the Ignore Presentation Indicators (internal calls only) check box on the User Device Profile Configuration window. For additional information, see the "Call Display Restrictions Enhancements" section.

Where to Find More Information

Cisco CallManager Extension Mobility, Cisco CallManager Features and Services Guide

Call Display Restrictions, Cisco CallManager Features and Services Guide

Cisco IP Manager Assistant Enhancements

Cisco CallManager 4.1(2) contains the following changes for Cisco IP Manager Assistant:

Changes to comply with JTAPI.

Changes for MSJVM removal.

Support for the Time-of-Day routing feature.

Where to Find More Information

Cisco CallManager Features and Services Guide

Directory Enhancements

Cisco CallManager 4.1(2) provides security automatically for the DC Directory. Microsoft Active Directory (AD) and the Netscape Directory require manual configuration for security. Providing LDAP at SSL (LDAPS) enables security. When security is set, the system "encrypts" certain data (such as user passwords and user IDs) when it passes through the network.

Configuration Tips (for Administrators)

The administrator must run the Customer Directory Plugin if security is needed for Microsoft AD or for the Netscape Directory.

Where to Find More Information

Directory, Cisco CallManager System Guide

Installing the Cisco Customer Directory Configuration Plugin for Cisco CallManager

Cisco Unity Voice-Mail Port Adjustments and Unity User Integration

Cisco CallManager 4.1(2) includes a link to configure a Cisco Unity voice messaging subscriber number from the Directory Number Configuration window and from the User Configuration window (under "Add a New User"). Phones must associate with users for the link to appear on the User Configuration window.

Configuration Tips (for Administrators)

The Unity administrator must perform certain configurations to make the link accessible, including copying an asp page to the Cisco CallManager server. This feature requires Unity 4.04 and additional configuration, as described in the Unity documentation.

Where to Find More Information

Phone Configuration, Cisco CallManager Administration Guide

Add a New User Configuration, Cisco CallManager Administration Guide

Cisco Unity, Cisco CallManager System Guide

Cisco CallManager 4.1 Integration Guide for Cisco Unity 4.0

Multilevel Administration Access Enhancements

Multilevel Administration Access (MLA) now supports UMX APIs for LDAP Directory access as a transparent change to the administrator. Previously, a custom Java code (MultilevelAdmin.dll) implemented the LDAP Directory access for Users and User Group. With this conversion, no dependency on the Microsoft JVM exists in future releases.

The Cisco CallManager Administration menu changes include MLA support for assigning access rights.

Where to Find More Information

MLA, Cisco CallManager System Guide

MLA Configuration, Cisco CallManager Administration Guide

QSIG Protocol Enhancements

Cisco CallManager release 4.1(2) includes the following QSIG enhancements:

Alerting Name

Annex M.1

Call Completion

Call Diversion

Compatibility with Older Versions of QSIG Protocol (ECMA)

Facility Selection and Reservation

Path Replacement

Alerting Name

Cisco CallManager 4.1(2) supports "Alerting on ring" only to allow the QSIG Alerting Name that you configure to send and receive call name information while the phone rings. When two phones ring for the shared directory number, the name that you entered in the Alerting Name field displays on the phone of the called party at the terminating Private Integrated Services Network Exchange (PINX), unless translation pattern restrictions affect the information that displays. Route pattern restrictions may affect the information that displays on caller phone at the originating PINX. (In a QSIG network, a switch such as Cisco CallManager or other PBX represents a PINX.)

Configuration Tips (for Administrators)

Configure the Alerting Name field for shared and nonshared directory numbers from the Cisco CallManager Administration Directory Number Configuration window.

If you do not configure an Alerting Name, only the directory number displays on the calling party phone when alerting occurs.

If you configure a Display Name for the called party, the Display Name displays on the calling party phone when the call connects.

If you do not enter a Display Name or an Alerting Name, no name displays on the calling party phone during the call.

Cisco CallManager does not provide support for Alerting Name with the following device types:

PRI trunks

FXS/FXO ports for MGCP gateways

MGCP T1-CAS gateways

Annex M.1

The Annex M.1 feature uses intercluster trunks to transport (tunnel) non-H.323 protocol information in H.323 signaling messages between Cisco CallManagers. Annex M.1 supports QSIG calls and QSIG call independent signaling connections.

QSIG tunneling supports the Call Completion, Call Diversion, Call Transfer, Identification Services, Message Waiting Indication, and Path Replacement features.

Configuration Tips (for Administrators)

In the Cisco CallManager Administration Trunk Configuration window, choose the QSIG option in the Tunneled Protocol drop-down list box and check the Path Replacement Support check box.

After you configure the QSIG Tunneled Protocol option, the Path Replacement Support check box automatically becomes checked. If you do not require path replacement over Annex M.1 or QSIG-tunneled trunks, you can uncheck the Path Replacement Support check box.

When you set the Tunneled Protocol field to None, Cisco CallManager automatically grays out the Path Replacement Support check box.

When you set the Tunneled Protocol field to QSIG, the system does not allow configuration of the Redirecting Number IE Delivery (Inbound), Redirecting Number IE Delivery (Outbound), or Display IE Delivery options.


Tip If you use a gatekeeper, you must configure every gateway in the network for QSIG tunneling. If any gateway in the network does not support QSIG tunneling, calls drop at the intercluster trunk that is configured for QSIG tunneling.



Note Cisco CallManager does not support protocol profile 0x91 ROSE encoding with Annex M.1.


Call Completion

The Cisco Call Back feature allows you to receive call back notification on your Cisco IP Phone when a called party line becomes available. You can activate call back for a destination phone that is within the same Cisco CallManager cluster as your phone or on a remote PINX over QSIG trunks or QSIG-enabled intercluster trunks.

Configuration Tips (for Administrators)

You may need to update the default settings for the Cisco Call Back service parameters if the Cisco Technical Assistance Center (TAC) directs you to do so.

Cisco Call Back service parameters include Connection Proposal Type, Connection Response Type, Callback Request Protection Timer, Callback Recall Timer, and Callback Calling Search Space. For information about these parameters, click the i button that displays in the upper corner of the Cisco CallManager Service Parameter window.

How This Feature Affects the End User

Refer to the Cisco CallManager Features and Services Guide for details about how Cisco Call Back works when a phone becomes unavailable.

Call Diversion

Cisco CallManager 4.1(2) supports call diversion by rerouting and call diversion by forward switching.

Call Diversion by Rerouting

When call diversion by rerouting occurs, the originating PINX receives a request from the receiver of the call to divert the call to another user.

Call diversion by rerouting does not support non-QSIG trunks.

If you do not use a uniform dial plan for your network, use call diversion by forward switching and path replacement to optimize the path between the originating and terminating users.

Call Diversion by Forward Switching

If the receiver of the incoming call and the diverted-to user exist in the same PINX, Cisco CallManager uses call diversion by forward switching.

If call diversion by rerouting is not successful for any reason, for example, the rerouting timer expires, forward switching occurs.

Configuration Tips (for Administrators)

Service parameters for call diversion by rerouting include Call Diversion by Reroute Enabled and Call Reroute T1 Timer. If you do not configure the service parameters, call diversion by forward switching automatically occurs.

Cisco CallManager does not invoke call diversion by rerouting when the system forwards the call to the voice mailbox. If the connection to the voice mail server occurs over a QSIG trunk and you want to use call diversion by rerouting, you must enter the voice mail pilot number in the appropriate Coverage/Destination field instead of checking the Voice Mail check box in the Directory Number Configuration window.

Compatibility with Older Versions of QSIG Protocol (ECMA)

To create Cisco CallManager compatibility with your version of the QSIG protocol, configure the ASN.1 Rose OID Encoding and QSIG Variant service parameters.

For more information about these parameters, click the i button that displays in the upper corner of the Service Parameter window.

Configuration Tips (for Administrators)

If you choose ECMA for the QSIG Variant parameter, you must choose the Use Global Value (ECMA) setting for the ASN.1 Rose OID Encoding service parameter.

If you choose ISO for the QSIG Variant parameter, choose the Use Local Value setting for the ASN.1 Rose OID Encoding service parameter.

If you configure the QSIG Variant service parameter, a warning message indicates that Cisco CallManager does not support ECMA with QSIG tunneling over intercluster trunks (Annex M.1). To use ECMA, verify that the None option displays for the Tunneled Protocol drop-down list box in the Trunk Configuration window.

Cisco Call Manager supports the use of Annex M.1 for tunneling QSIG over intercluster trunks. To configure Annex M.1, set the ASN.1 Rose OID Encoding to Use Global Valueless) and the QSIG Variant to ISO (Protocol Profile 0x9F).

Facility Selection and Reservation

The Facility Selection and Reservation feature allows you to make calls by using mixed route lists, which contain route groups that use different protocols. This feature supports route lists that include the following types of facilities:

E1 or T1 PRI trunks that use the QSIG protocol

E1 or T1 PRI trunks that use a protocol other than QSIG

T1-CAS gateways

FXO ports

Intercluster trunks

If a call requires a QSIG facility, Cisco CallManager hunts through the route groups to reserve the first available QSIG facility. If a QSIG facility is unavailable, Cisco CallManager uses a non-QSIG facility to failover to the public switched telephone network (PSTN). If a call does not require a QSIG facility, Cisco CallManager hunts through the route groups to find the first available facility.

Configuration Tips (for Administrators)

You cannot add route groups with H.323 gateways to a route list that includes QSIG route groups.

When you configure the route list, configure the QSIG route groups as the first choice, followed by the non-QSIG route groups that serve as alternate connections to the PSTN. Make sure that you include additional route groups for QSIG calls in addition to the private network QSIG facilities.

The Path Replacement, Message Waiting Indication, and Call Completion supplementary services require a QSIG facility to meet QSIG signaling compliance requirements. If a QSIG facility is not available for one of the aforementioned services, the call does not meet QSIG signaling compliance requirements, and the feature fails.

Path Replacement

In a QSIG network, a switch such as Cisco CallManager or other PBX represents a PINX. After a call is transferred or forwarded to a phone in a third PINX, multiple connections through at least three PINXs can exist for the call. When the call connects, the path replacement feature drops the connection to the transit PINX(s) and establishes a new, more direct call connection to the terminating PINX.

Cisco CallManager initiates path replacement for calls that are transferred by joining and for calls that are diverted by forward switching only.

Cisco CallManager does not support path retention.

When you use CTI applications with path replacement, the leg of the call that uses path replacement has a different Global Caller ID than the originating leg of the call. After a call is forwarded or transferred, if the remaining parties use the same Cisco CallManager, two Global Caller IDs exist, one for each party. The system deletes one of the Global Caller IDs, leaving both parties in the call with the same Global Caller ID.

Configuration Tips (for Administrators)

Calls that involve multiple trunks, such as conference calls, do not use path replacement. However, if you choose the QSIG option for the Tunneled Protocol drop-down list box and check the Path Replacement Support check box for gatekeeper-controlled or non-gatekeeper-controlled intercluster trunks, path replacement occurs over the intercluster trunk and the other QSIG intercluster or PRI trunk that is used to transfer or divert the call.

Use QSIG features, such as path replacement, in a network with a uniform dial plan.

When a private network uses nonunique directory numbers in the dial plan, you must reroute calls through a PINX ID, which is a unique directory number for every PINX in the network. The path replacement feature uses the PINX ID, if configured, instead of the called or calling party number. To configure the PINX ID, perform the following tasks in Cisco CallManager Administration:

Configure the PINX ID service parameter(s) for the Path Replacement feature. (The Path Replacement feature uses the Cisco CallManager service.)

Create a call pickup group that includes only the PINX ID.


Tip Reserve the PINX ID call pickup group for PINX ID usage. Do not add other directory numbers to this call pickup group.


Path Replacement service parameters include Path Replacement Enable, Path Replacement on Tromboned Trunks, Start Path Replacement Minimum Delay Time, Start Path Replacement Maximum Delay Time, Path Replacement PINX ID, Path Replacement Timers, Path Replacement Calling Search Space, and so on. To obtain information about these parameters, click the i button that displays in the Service Parameter window.

Path replacement performance counters allow you to track when path replacement occurs. For information about performance counters, refer to the Cisco CallManager Serviceability System Guide.

For each call, the system generates more than one CDR for the path replacement feature. One CDR generates for the caller at the originating PINX; another CDR generates for the called party at the PINX where path replacement is initiated.

How This Feature Affects the End User

When a Cisco SoftPhone user performs a consultive transfer to move a call to another PINX, path replacement can occur; if the user performs a direct (blind) transfer, path replacement cannot occur. For more information about Cisco SoftPhone, refer to the Cisco SoftPhone documentation that supports your version of the application.

Where to Find More Information

Understanding IP Telephony Protocols, Cisco CallManager System Guide

Understanding Route Plans, Cisco CallManager System Guide

Gateway Configuration, Cisco CallManager Administration Guide

Gatekeeper Configuration, Cisco CallManager Administration Guide

Trunk Configuration, Cisco CallManager Administration Guide

Cisco IP Phone Configuration, Cisco CallManager Administration Guide

Cisco Call Back, Cisco CallManager Features and Services Guide

Video Calls Enhancements

Cisco CallManager 4.1(2) provides support for the following video call enhancements:

SCCP H.264

Mid-call Video for CVTA

Video Display Mode

Participant Information

Dynamic H.323 Addressing

Configuration Tips (for Administrators)

This release includes the following items in the Cisco CallManager Administration Phone Configuration window for H.323 clients:

Check box for Gatekeeper Controlled Client

Gatekeeper Information section (required only for Gatekeeper Controlled Client)

A drop-down menu for Gatekeeper (required only for Gatekeeper Controlled Client)

New text field for E.164 (required only for Gatekeeper Controlled Client)

New text field for Zone (required only for Gatekeeper Controlled Client)

New text field for Technology-Prefix (required only for Gatekeeper Controlled Client)

How This Feature Affects the End User

SCCP H.264—Users can place an H.264 video call from an SCCP device. This action assumes that both the calling and called SCCP device support H.264.

Mid-call Video for CVTA—Users who turn on CVTA during an active audio call get video if the other party is also video.

Video Display Mode—Users have an additional softkey that toggles the video display mode from Voice Activated to Continuous Presence during a video conference. This action assumes that the video conference is on an SCCP video bridge that supports this feature.

Participant Information—User information now displays in the video during a video conference. This action assumes that the video conference is on an SCCP video bridge that supports this feature.

Where to Find More Information

Gateway Configuration, Cisco CallManager Administration Guide

Phone Configuration, Cisco CallManager Administration Guide

Region Configuration, Cisco CallManager Administration Guide

Security Enhancements

Cisco CallManager 4.1(2) includes the following security enhancements:

Cisco IP Phone models 7960 and 7940 can support media and signaling encryption.

Certificate Authority Proxy Function (CAPF) parameters display on the Cisco CallManager Administration Phone Configuration window when you upgrade to Cisco CallManager 4.1(2), but these parameters are not supported for the Cisco IP Phone 7970 when it is running the default firmware image; that is, no CAPF operations are performed, including locally significant certificates (LSC) installations or upgrades on the Cisco IP Phone 7970. (The data/status information that displays in these parameters should be ignored for the Cisco IP Phone 7970.)

CAPF functionality will become available for the Cisco IP Phone 7970 with the release of a firmware image that is compatible with Cisco CallManager release 4.1(2). For Cisco IP Phone firmware release availability information, refer to the applicable firmware release notes for the Cisco IP Phone 7970 at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/.

Certificate Authority Proxy Function (CAPF) displays in BAT and the Cisco CallManager Administration Phone Configuration window. (In Cisco CallManager 4.0, it existed as a CLI utility on the voice software download page.) For information about migrating CAPF 1.0(1) data to the Cisco CallManager 4.1(2) database, refer to Cisco CallManager Security Guide and Upgrading Cisco CallManager Release 4.1(2).

In Cisco CallManager Administration (Device > Device Settings > CAPF Report), you can now generate a CAPF report to view the certificate operation status, to view the authentication strings, or to view the authentication mode for listed devices. After you generate the CAPF report, you can view the report in a CSV file.

A new service, Certificate Authority Proxy Function (CAPF) service, displays in Cisco CallManager Serviceability. Activate this service only on the publisher database server.

SCCP/SRTP troubleshooting settings display in BAT and the Cisco CallManager Administration Phone Configuration window.


Tip Do not configure the SCCP/SRTP settings unless you are troubleshooting encryption. Configuring these settings may cause high CPU usage and call-processing interruptions.


You can search for phones by choosing one of the following criteria in the Cisco CallManager Administration Phone Find/List window:

Device Security Mode

LSC Status

After you configure the MGCP gateway for security, use Windows native mode IPSec to set up the IPSec connection between the MGCP gateway and Cisco CallManager.


Caution If you do not configure the IPSec connections and verify that the connections are active between the gateway and Cisco CallManager, privacy of the media streams may be compromised.

Hypertext Transfer Protocol over Secure Sockets Layer (SSL), which secures communication between the browser client and the IIS server, uses a certificate and a public key to encrypt the data that is transferred over the Internet. HTTPS also ensures that the user login password transports securely via the web. The following Cisco CallManager applications support HTTPS to ensure the identity of the server:

Cisco CallManager Administration

Cisco CallManager Serviceability

Cisco IP Phone User Option Pages

Bulk Administration Tool (BAT)

Tool for Autoregistered Phone Support (TAPS)

Cisco CDR Analysis and Reporting (CAR)

Trace Collection Tool

Real Time Monitoring Tool

You can use HTTPS with the versions of Internet Explorer and Netscape Navigator that are supported with this release of Cisco CallManager.

When you install/upgrade Cisco CallManager, the HTTPS self-signed certificate, httpscert.cer, automatically installs on the IIS default website that hosts the Cisco CallManager virtual directories shown in Table 1:

Table 1 Cisco CallManager Virtual Directories 

Cisco CallManager Virtual Directory
Corresponding Application

CCMAdmin

Cisco CallManager Administration

CCMService

Cisco CallManager Serviceability

CCMUser

Cisco IP Phone User Option Pages

AST

Real Time Monitoring Tool (RTMT)

RTMTReports

RTMT reports archive

CCMTraceAnalysis

Trace Analysis Tool

PktCap

Troubleshooting tools

Note These troubleshooting tools use the virtual directory to get the trace files that contain the SCCP signaling packet traces.

CCMServiceTrace
CollectionTool

Trace Collection Tool

ART

CAR

BAT

Bulk Administration Tool

TAPS

Tool for Auto-Registered Phones Support (TAPS)


New Cisco CallManager Administration configuration settings display secure Survivable Remote Site Telephony (SRST) references. After you perform the required security tasks for the gateway and reference, the TFTP server adds the SRST certificate to the phone cnf.xml file and sends the file to the phone. A secure phone then uses a Transport Layer Security (TLS) connection to interact with the SRST-enabled gateway.

Cisco CallManager only supports depth-1 chaining for the SRST certificates; that is, the phone configuration file only contains a certificate from a single issuer. The system does not support Hot Standby Router Protocol (HSRP).

The following information applies for Cisco IP Phone models 7960 or 7940 that are configured for encryption and associated with a wideband codec region. To establish an encrypted call, Cisco CallManager ignores the wideband codec and chooses another supported codec from the codec list that the phone presents. If the other devices in the call are not configured for encryption, Cisco CallManager may establish the authenticated/nonsecure call by using the wideband codec.

How This Feature Affects the End User

If the initiator phone is configured for encryption, the barge initiator can barge into an authenticated or nonsecure call from the encrypted phone. After the barge occurs, Cisco CallManager classifies the call as nonsecure. For more information about barging into an encrypted call, see the"Barging into Encrypted Calls with the Cisco IP Phone Model 7970" section.

A user can barge into an authenticated call, even if the phone that is used to barge is nonsecure. The authentication icon continues to display on the authenticated devices in the call, even if the initiator phone does not support security.

You can configure cBarge if you want barge functionality, but Cisco CallManager automatically classifies the call as nonsecure.

Cisco IP Phone models 7940 and 7960 that are encrypted cannot use the barge feature.

The encryption lock icon indicates that the media stream between the Cisco IP devices is encrypted. The encryption lock icon may not display on the phone when the user performs tasks such as conferencing, transferring, or putting a call on hold; the status changes from encrypted to nonsecure if the media streams that are associated with these tasks are not encrypted.

New security menus display on Cisco IP Phone models 7940, 7960, and 7970.

Where to Find More Information

Cisco CallManager Security Guide

Cisco IP Phone User Guide

Cisco IP Phone Administration Guide for Cisco CallManager

Cisco IP Phone Configuration, Cisco CallManager Administration Guide

SRST Configuration, Cisco CallManager Administration Guide

Overview, Cisco CallManager Administration Guide

Overview, Cisco CallManager System Guide

Services, Cisco CallManager System Guide

Cisco IP Phone Authentication and Encryption for Cisco CallManager

CTI Super Provider

CTI Super Provider allows a CTI application to control any CTI-controllable device that is configured in the Cisco CallManager system; this allows certain applications to control a large number (possibly all) of the CTI-controllable devices. The system administrator configures the super provider capability in the Cisco CallManager Administration User Configuration window.

Configuration Tips (for Administrators)

This release supports the addition of a check box to Add a New User in the User Configuration window—Check this check box, along with the Enable CTI Application check box, to make CTI Super Provider work. If the application monitors a call park number, you must also check the Call Park Retrieval Allowed check box.

CTIManager provides two advanced, clusterwide service parameters that are used in conjunction with the CTI Super Provider capability:

Maximum Devices Per Provider—This parameter specifies the maximum number of devices that a single CTI application can open. The default specifies 1000 devices.

Maximum Devices Per Node—This parameter specifies the maximum number of devices that all CTI applications on any CTIManager node in the Cisco CallManager system can open. The default specifies 2000 devices.

Where to Find More Information

Adding A New User, Cisco CallManager Administration Guide

CTI, Cisco CallManager System Guide

Bulk Administration Tool Enhancements

The Bulk Administration Tool (BAT) version 5.1(3) supports Cisco CallManager release 4.1(2) and provides support for the following features and enhancements:

New BAT Features

External Call Transfer Restrictions (Trunk-to-Trunk Transfer)

Call Coverage

FAC/CMC

Call Display Restrictions

MLPP Enhancements

QSIG for Alerting Name

Video

Security

CTI Super Provider

CAPF Configuration

New BAT Features

The system includes support for the following new BAT features:

BAT includes a change in the location of BAT log files, including the creation of two new folders: C:\Program Files\Cisco\Trace\BAT and
C:\Program Files\Cisco\Trace\BAT\Export.

BAT log files generate under C:\Program Files\Cisco\Trace\BAT.

BAT trace files generate under
C:\Program Files\Cisco\Trace\BAT\ Traces.

BAT export log files generate under
C:\Program Files\Cisco\Trace\BAT\Export.

The installation sets permissions for all users on the new folders.

BAT Update Phones window includes the option to remove duplicate IP phone services from phones.

BAT supports the deletion of unassigned DNs from the Delete Phones window. (Unassigned DNs comprise those directory numbers that are not associated to any device.)


Note BAT does not support exporting data from one release of Cisco CallManager and importing the data into another release of Cisco CallManager; that is, you must export data on the same version of Cisco CallManager as you imported it from. For example, if you export data from a Cisco CallManager 4.1 system, you can only import that data on a Cisco CallManager 4.1 system.


External Call Transfer Restrictions (Trunk-to-Trunk Transfer)

The system provides support for the following enhancements to external call transfer restrictions:

When you choose 'Use System Default' at the device level, the system uses the value of the service parameter for device applicability as OnNet (internal) or OffNet (external).

The system provides support for inserting new gateway configuration attributes by adding the "Call Classification" device field for gateways. BAT supports the new field on the Gateway Template Configuration window for non-FXS ports for VG200 gateways.

BAT template migration includes the default values of the new gateway field when you upgrade BAT to release 4.1.

For additional information about External Call Transfer Restrictions, see the "External Call Transfer Restrictions (Trunk-to-Trunk) Enhancements" section.

Call Coverage

This release includes the following enhancements for the call coverage feature:

BAT supports the following new fields on the Directory Number Configuration window for Call Coverage for the phone, user device profile, and FXS port DN template:

Call Forward No Answer (CFNA): Internal DN, Internal CSS, Internal Voice mail check box, External DN, External CSS, External Voice mail check box.

Call Forward Busy (CFB): Internal DN, Internal CSS, Internal Voice mail check box, External DN, External CSS, External Voice mail check box.

Call Forward No Coverage: Internal DN, Internal CSS, Internal Voice mail check box, External DN, External CSS, External Voice mail check box.

BAT includes support for Export/Import All for the Internal/External Call Forward fields.

BAT File Title supports Call Forward conditionals that are added under the line fields. This enables the administrator to enter directory numbers for call forward primitives in the BAT CSV file while inserting new devices. The BAT file title provides support for Forward Busy Internal and External, Forward No Answer Internal and External, and Forward No Coverage Internal and External "directory numbers" only.

BAT supports Add Lines functionality to add lines to existing phones or device profiles based on the data input file and/or the phone or UDP templates. The administrator can specify these values as a part of the data input file or the phone/UDP template; the data input file values take priority over the corresponding values in the templates.

BAT supports Update Lines functionality to support update of the call coverage fields. (These existing call forwards now represent Forward Busy External and Forward No Answer External calls.)

BAT xlt includes support for Call Forward primitives (Forward Busy Internal/External, Forward No Answer Internal/External, and Forward No Coverage Internal/External for directory numbers).

BAT template migration includes the default values for the new line fields for external/internal call forwards when you upgrade BAT to release 4.1. (The new fields for internal/external call forwards comprise part of the phone, UDP, and gateway DN templates.) The system maintains the specified values for CFNA and CFB from earlier versions of Cisco CallManager.

For additional information about Call Coverage, see the "Call Coverage Enhancements" section.

FAC/CMC

The system includes support for the following FAC/CMC enhancements:

Bulk Insert/Update of Forced Authorization Codes.

Bulk Delete of Forced Authorization Codes.

Bulk Insert/Update of Client Matter Codes.

Bulk Delete of Client Matter Codes.

BAT excel template for creating data input files for Inserting FAC and CMC codes.

For additional information about FAC/CMC, see the "Forced Authorization Codes/Client Matter Codes" section.

Call Display Restrictions

The system provides support for the following enhancements for the Call Display Restrictions feature:

The new field on the phone and UDP template configuration for Call Display Restrictions includes the Ignore Presentation Indicators (internal calls only) option.

The Export/Import functionality contain the following support for the Ignore Presentation Indicators (internal calls only) option:

BAT exports the value of the Ignore Presentation Indicators (internal calls only) to the phone/UDP export all file.

BAT Import All functionality also extends to the new fields; while phones/UDP are moved from one cluster to another, the system maintains the values of this new field.

The BAT validate feature prevalidates the CSV file before inserting the data and is used specifically for the All details file for phones/UDP; it validates the value of the Ignore Presentation Indicators (internal calls only) field.

Updated phone support includes the Ignore Presentation Indicators (internal calls only) field in the list of features that can be updated for all the phones that are chosen based on query or custom file.

BAT template migration includes the Ignore Presentation Indicators (internal calls only) field in the phone template; the BAT template migration includes the default value of this device field/UDP field when you upgrade BAT to release 4.1.

For additional information about Call Display Restrictions, see the "Call Display Restrictions Enhancements" section.

MLPP Enhancements

This release includes the following enhancements for MLPP:

Release 4.1 includes gateway support for SCCP. The system classifies the gateway end points as phones and displays them in the drop-down list for supported device types in BAT.

The system does not provide support to insert SCCP gateway endpoints because gateways that support SCCP do not include the network module information in the endpoint MAC address. (BAT uses the feature "Supports Auto Registration" to display the supported endpoints.)

The system supports the update and delete features for the SCCP gateway endpoints; you can choose phones to update and/or delete based on a query or a custom file.

For additional information about MLPP, see the "Multilevel Precedence and Preemption Enhancements" section.

QSIG for Alerting Name

The system supports the following enhancements for QSIG:

BAT provides Export/Import All support for Alerting Name changes:

BAT exports the value of the Alerting Name to the phone/UDP export all file.

BAT import all functionality also extends to the new field; it maintains the value of this field while phones/UDP are moved between clusters.

BAT validate feature validates the value of Alerting Name.

BAT File Title includes the Alerting Name field under the line fields for phones and UDPs; this enables entry of an Alerting name in the BAT CSV file while inserting a new device with a shared DN.

BAT Gateway Directory Number Template includes the Alerting Name; this capability enables entry of the Alerting Name that is common for all the directory numbers.

BAT xlt includes support for Alerting Name.

Support for the BAT template migration for the Alerting Name field, which is part of the Gateway DN templates; BAT includes the default values for the new gateway field when you upgrade BAT to release 4.1.

For additional information about QSIG, see the "QSIG Protocol Enhancements" section.

Video

This release provides support for the following video enhancements:

Video as a Cisco application can associate with a Cisco IP Phone to video-enable an audio-only device. This release adds new fields in the H.323 client configuration window (Phone Configuration) for the video changes.

Insertion of new fields on the H.323 client by adding the Gatekeeper, E.164, Zone, and Technology Prefix fields for H.323 clients. BAT supports these fields on the Phone Template Configuration window for H.323 clients, with the exception of the E.164 field, which is included in the file title for the phone. The BAT excel template supports the E.164 field.

The use of Import All/Export All for video changes:

BAT exports the value of the video fields to the phone export all file.

BAT import all functionality also extends to the new fields; it maintains the value of these fields while phones are moved between clusters.

BAT validate feature validates the values of the video fields.

BAT template migration supports these fields in the phone templates, and includes the default values of the new phone template fields when you upgrade BAT to release 4.1.

For additional information about video calls, see the "Video Calls Enhancements" section.

Security

The system includes support for the following security enhancements:

Cisco CallManager release 4.1 includes HTTPS support for the BAT configuration windows and new signal packet capture mode and packet capture duration device fields. (Implementing HTTPS ensures that the BAT configuration changes that you process, including secure web transport of user passwords, are secure.) Security fields are set on the phone template for configuration.

The BAT installation sets the security setting on the BAT virtual directory, with the directory properties set to require secure channel (SSL).

The system removes hard-coding of http in the URLs in the BAT configuration windows.

The BAT installation modifies the shortcut link for BAT to the new BAT URL.

BAT phone template support includes the signal packet capture model and packet capture duration security fields; this allows the administrator to enter the security fields that are common to all the phones.

BAT Export/Import functionality provides support for security fields:

BAT exports the value of the signal packet capture mode and packet capture duration security fields to the phone export all file.

BAT import all functionality also extends to the new fields; it maintains these values of the new fields while phones are moved between clusters.

BAT validate feature validates the value of the signal packet capture mode and packet capture duration fields.

BAT supports update of the Device Security Mode and signal packet capture mode security fields under Update Phones.

The system includes support for BAT template migration.

For additional information about Security, see the "Security Enhancements" section.

CTI Super Provider

The system includes support for the following CTI Super Provider enhancement:

With the CTI Super Provider feature, an application that is configured as a Super-Provider can control any device in the system without the need to perform any preconfiguration. For all the users that are inserted by using BAT, the Enable CTI Super Provider attribute specifies false by default.

For additional information about CTI Super Provider, see the "CTI Super Provider" section.

CAPF Configuration

This release supports the following CAPF configuration enhancements:

Insertion of new fields on BAT phone templates by adding the Authentication Mode, Authentication String, Key Size, Certificate Operation (No Pending Operation, Install/Upgrade, Delete, Troubleshoot), and Operation Completes By fields to the BAT phones. BAT supports the new fields on the Phone Template configuration windows for supported models.

The system supports Import/Export All for CAPF fields:

BAT exports the values of the CAPF to the phone export all file.

BAT import all functionality extends to the new fields; it maintains the value of these fields while phones are moved between clusters.

BAT validate feature validates the CAPF fields.

BAT template migration supports these fields in the phone templates; BAT includes the default values of the new phone template fields when you upgrade BAT to release 4.1.

This release provides support to update/delete CAPF Authentication Mode, Authentication String, Key Size, and Operation Completes By fields by using BAT update CAPF configuration. BAT also provides the functionality for the Delete LSC option. BAT Delete LSC updates the certificate operation of the chosen phones to deletion. (BAT Update and Delete CAPF functionality results in the LSC status being set to "scheduled.")

For additional information about CAFP, see the "Security Enhancements" section.

Configuration Tips (for Administrators)

BAT supports the following new configuration fields on the web interface:

Phone Configuration window—CAPF fields (certificate operation, authentication mode, authentication string, key size, video fields for H.323 clients, gatekeeper Name, technology prefix, zone).

Call Display Restrictions—Ignore Presentation Indicators (internal calls only).

Security—Signal packet capture mode, packet capture mode.

Update Phones Window—Update for Ignore Presentation Indicators (internal calls only), removal of duplicate services from the phones.

Adds support in the BAT excel template for creation of CSVs to insert forced authorization codes and to insert client matter codes; supports Alerting Name to create phone CSV along with new fields for the call forward insert/external conditionals on the create file format options for phones and UDPs; supports the E.164 field.

Where to Find More Information

Bulk Administration Tool User Guide

Tool for Autoregistered Phone Support Enhancements

The system supports the following enhancements for the Tool for Autoregistered Phone Support (TAPS) version 5.1(3):

Security Enhancement—This release provides HTTPS support for the TAPS administration windows for security to ensure secure web configuration changes.

TAPS Log Files—The TAPS installation creates a new folder for TAPS log files and trace files that is located at
C:\Program Files\Cisco\Trace\TAPS.

Where to Find More Information

Bulk Administration Tool User Guide

Dialed Number Analyzer Enhancements

Cisco CallManager 4.1 contains enhancements to the Dialed Number Analyzer (DNA) tool, including additional information in the final results for an analysis performed.

This release includes the following new DNA features:

Call Coverage—Additional forwarding information pertaining to each directory number displays in the output. Hunt forwarding treatment information displays in results for Hunt Pilot numbers.

H323Outbound fastStart—DNA results for H.323 devices also show information regarding "Inbound/Outbound fastStart" that is configured for the device.

External Call Transfer Restrictions (Trunk-Trunk Transfer)—External Call Transfer Restrictions (Trunk-Trunk Transfer) DNA gateway, trunk and phone windows now display information about the "Call Classification" field. The final analysis result for route patterns displays OnNet/OffNet information about the route pattern. Also, the final analysis results that lands on a device (for example, gateway/trunk/phone), displays the "Call Classification" information (OnNet/OffNet/Use System Default) configured for that device.

Call Display Restrictions—Call Display Restrictions DNA results include a new tag for the Ignore presentation indicators (internal calls only) field whenever a phone device is matched during analysis.

Time-Of-Day—DNA now includes Time-of-Day settings for analysis. The user can specify any time for analysis by modifying the existing analysis user interface. The final analysis results display the time schedule and the time zone information of the matched pattern and device respectively.

FAC/CMC—Analysis for route patterns now display tags for FAC/CMC Required and Authorization Level.

BRI—New support includes performing an analysis from BRI gateways. Also, if any given analysis lands on a BRI device, information pertaining to that device displays in the results.

MLPP—DNA windows permit dialing of A, B, C, and D digits.

QSIG—Analysis results display the Tunneled Protocol for an Inter Cluster Trunk configured to use the QSIG protocol. In addition, the analysis results display the Alerting Name for a device configured with this information.

Configuration Tips (for Administrators)

This release modifies the user interface slightly to allow the user to enter Time of Day settings for an analysis.

Where to Find More Information

Cisco CallManager Dialed Number Analyzer Guide

New and Updated Support for Cisco IP Phone Models 7940/7960

Cisco CallManager 4.1 includes the following enhancements for the Cisco IP Phone model 7940/7960:

Signaling encryption—This release supports AES256-SHA-AES12-SHA encryption in a TLS session with Cisco CallManager to encrypt Skinny Call Control Protocol (SCCP) messages. This allows for encrypted registration with Cisco CallManager and is a mandatory requirement for supporting media encryption.

Media encryption—This release supports SRTP to encrypt the voice stream, allowing for encrypted calls.

Registration encryption and call encryption—The 7.0(x) firmware releases for Cisco IP Phone models 7940/7960 that are running on Cisco CallManager 4.1(2) and later now support encrypted calls. With Cisco CallManager 4.1(2), you may configure the security mode to encrypted for these phones to enable encrypted registration and encrypted calls.


Note The 6.0(x) phone firmware releases support encrypted registration; that is, they register as encrypted, but they do not provide support for encrypted calls. When you upgrade to Cisco CallManager 4.1(2) and configure the security mode to encrypted while using the 6.0(x) images, the device security mode displays "encrypted," meaning the 6.0(x) phones encrypt the signalling messages exchanged with the Cisco CallManager 4.1(2) servers, but the calls are not encrypted. (The 6.0(x) phones encrypt the registration and authenticate the call.)


Secure SRST—This release supports a TLS session with SRST.

Locally Significant Certificate (LSC) update automation—This enhancement allows you to remotely manage LSC updates by using a configuration file. Phones may automatically initiate sessions with the CAPF to update their certificates.

CAPF IP address and Port from Phone Configuration—This enhancement enables you to configure the IP address and port of CAPF from the configuration file; in this release, the port does not get hard coded in the phone.

Phone security UI—This release adds a Security Configuration menu similar to the one that the Cisco IP Phone model 7970 currently uses. In Cisco CallManager 4.1, an LSC update item on the Security Configuration menu replaces the Certificate menu.

Configuration Tips (for Administrators)

After you upgrade to Cisco CallManager 4.1(2), be sure to upgrade the phone firmware load to ensure no loss of functionality or features.

LSC Automation

Boot Up sequence with LSC Update Automation Invoked—This enhancement enables the phones to automatically initiate a connection to the CAPF.


Note The phone may behave in different ways depending on the device security mode in the configuration: Non-Secure, Authenticated, or Encrypted.


Initiating LSC Update After Fully Registered to a Cisco CallManager—The phone checks the CAPF after it fully registers with its primary Cisco CallManager and after it receives its configuration file via TFTP.

CAPF Session Failure Recovery

This release enhances the phone to automatically retry the CAPF connection if a communication failure occurs while a session is in progress. This failure could occur while the certificate is being installed, deleted, or fetched, or if the phone fails to receive an explicit End Session command from the CAPF. The system sets the retry count and inserts a fixed pause time (up to 30 seconds) before each attempt.

The CAPF authentication mode that is received from the configuration gets saved in flash along with other configuration parameters. If a power failure occurs, the phone uses the CAPF authentication mode that is stored in flash to indicate whether to automatically retry to initiate a session with CAPF after the failure.

Secure SRST

Boot Up Sequence with Secure SRST—When the phone receives the SRST certificate in the configuration file from the Cisco CallManager, it saves it and uses it to make a secure connection to the SRST.

Troubleshooting

The inability to make a secure connection to an SRST device usually indicates a configuration error in either Cisco CallManager or the SRST.

If the phone connects securely to Cisco CallManager but makes an insecure connection to the SRST, verify that the phone has received the SRST certificate from Cisco CallManager by checking the Trust List under the Phone Security Menu; look to see whether a certificate appears next to the SRST entry.

If the phone does not connect at all to the SRST but makes secure connection attempts as shown by the TLS Error to <SRTP IP address> message that is displayed on the phone, either Cisco CallManager has sent the wrong SRST certificate to the phone, or the SRST has the wrong CAPF certificate in its configuration. (It should be the one that was used to sign the LSC that the phone is currently using.) Use a sniffer trace to determine which end of the connection (phone or SRST) is rejecting the other's certificate during the TLS handshake. If the phone is rejecting the SRST, Cisco CallManager has the wrong SRST certificate. If the SRST is rejecting the phone, the SRST does not have the proper CAPF certificate. (Refer to the Cisco CallManager Administration Guide and the Cisco CallManager System Guide or the SRST documentation to fix these problems.)

Phone Security Menu

The Cisco IP Phone models 7940/7960 now contain a read-only Security Menu hierarchy that conforms to the security menu that is currently deployed in the Cisco IP Phone model 7970. This menu contains the following entries:

Table 2 Cisco CallManager Phone Security Menu 

Menu Number
Menu Entry
Status

1

Web Access

<Enabled | Disabled>

2

Security Mode

<Non-Secure | Authenticated | Encrypted>

3

MIC

<Installed | Not Installed>

4

LSC

<Installed | Not Installed | Pending>

5

CTL File

<Hash Value on 2 lines | Not Installed>

6

Trust List

 

7

CAPF

<dotted-decimal ipaddr:port number>


The LSC, CTL File, and Trust List entries allow for navigation to submenus for certificate operations (LSC) and for viewing the phones Trust information (CTL File and Trust List). Generally, for troubleshooting purposes, refer to the Trust List menu because it contains the complete trust list rather than the CTL File subset.

The CTL File menu provides an important configuration tool when the phone has a CTL file installed and the user/administrator wants to change the TFTP server (to which the phone points) to an address that is not found in the current Trust List. With this implementation, the user must unlock the CTL Menu to allow for the TFTP address change. Logic in the Network Configuration menu prevents the user from configuring TFTP so no TFTP server address is authorized. For additional details, refer to the Cisco IP Phone administration guide for your model IP phone.

How This Feature Affects the End User

UI Behavior During CAPF Session While the Phone Is Coming From Reset—This enhancement allows the phone to automatically initiate a CAPF session as part of the reset sequence before it registers with Cisco CallManager. During this time, the "Updating Certificate..." status displays at the phone status line in the same manner as the "Configuring IP..." status.

Security Menu—This release removes the Certificate entry in the Settings Menu; Manual certificate updates now get initiated from the LSC entry in the Security Menu.

Security Icons—When the phone is configured for Authenticated or Encrypted calls, the phone displays a security icon in the call detail bubble. A shield icon displays if the call is Authenticated, and a lock icon displays if the call is Encrypted.


Note Icons that associate with the Cisco CallManager Network Configuration menu entries now exist. When the phone registers nonsecurely with Cisco CallManager, no icon displays; when the phone registers as Authenticated or Encrypted, icons display next to the Cisco CallManager entries. Similar to the per-call icons, the system displays a shield icon for an Authenticated registration and a lock icon to indicate an Encrypted registration.


For more information about Cisco IP Phones, refer to the following URL for the appropriate Cisco IP Phone guide for your model IP phone:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/index.htm.

Where to Find More Information

Cisco IP Phone administration guide for your model IP phone

Firmware release notes for your model IP phone

Cisco CallManager Administration Guide

Cisco CallManager System Guide

SRST documentation

Customizing Your Cisco IP Phone on the Web

Cisco IP Phone Guide

Support for Cisco IP Phone Model 7970

The Cisco IP Phone 7970 can function on a server that runs Cisco CallManager release 4.1(2) but the phone does not support the Cisco CallManager 4.1(2) features at this time. (For specific information about CAPF support, see the "Security Enhancements" section.)

Cisco CallManager 4.1(2) features will be supported with a future release of a compatible Cisco IP Phone 7970 firmware image. For Cisco IP Phone firmware release availability information, refer to the applicable firmware release notes for the Cisco IP Phone 7970 at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/.

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:

CDR Analysis and Reporting (CAR) Enhancements

Trace Collection Tool and RTMT Security Enhancements

Trace Configuration Tool

CDR Analysis and Reporting (CAR) Enhancements

Cisco CallManager 4.1(2) contains the following enhancements for CAR:

Adds a new report to support the Client Matter Code feature.

Access this report from the System Reports menu (System Reports > FAC\CMC > Client Matter Code) within the CAR Administration windows.

Adds two new reports to support the FAC feature and use Authorization Description and Authentication Level as a basis.

Access these reports from the System Reports menu (System Reports > FAC\CMC > FAC by Authorization Code Name and System Reports > FAC\CMC > FAC) by Authorization Level, respectively, within the CAR Administration windows.

Includes security configurations for ART (CAR) virtual directory.

Changes made to Loader that facilitate loading the new fields in the CDR for FAC/CMC.

How This Feature Affects the End User

The CAR Configuration window includes a new menu selection for the FAC\CMC reports.

The end user can generate reports based on Client Matter Code, Authorization Level, and Authorization Description.


Note The system only generates FAC authorization level reports that are associated with route patterns.


CAR logon window opens with HTTPS; for example, https://<server name or IP>/art/Logon.jsp, when accessed from Cisco CallManager Serviceability.

Relevant Documents

Cisco CallManager Serviceability Administration Guide

Cisco CallManager Serviceability System Guide

Trace Collection Tool and RTMT Security Enhancements

Cisco CallManager 4.1(2) includes the following enhancements for the Trace Collection Tool and the Real-Time Monitoring Tool (RTMT):

The Trace Collection Tool and Real-Time Monitoring Tool allow you to access a security-enabled Cisco CallManager server over an HTTPS connection.

Cisco CallManager 4.1(2) adds a new menu option (View >Certificate) for all the windows after login to enable certificate viewing.

When you login to a node in the cluster, a message indicates that the certificate for the server may not be secure. To continue, click Yes. If you click No, the session terminates.

When you access online help, you have the option to continue by installing the security certificate or to continue without installing the security certificate. If you choose to continue, you can access online help. If you choose not to continue, the TCT or RTMT application remains up but you cannot access online help.

Configuration Tips (for Administrators)

Cisco CallManager release 4.1(2) adds a check box to enable secure connection on the login window of RTMT. (Make sure that security is enabled on the MCS Server.)

To log into the tools over an HTTPS connection, check the Secure Connection check box on the log in window of the tool. When you access online help from the Real-Time Monitoring Tool or the Trace Collection Tool, the Security Alert dialog box displays. This dialog box displays each time that you access online help until you install the certificate for that tool on your computer.

How This Feature Affects the End User

The user can validate and authorize the server to which they are communicating, based on the certificate contents, and ensure that all communication to the server occurs over a secure channel.

Where to Find More Information

Cisco CallManager Serviceability System Guide

Cisco CallManager Serviceability Administration Guide

Loading the Trace Collection Tool, Cisco CallManager Serviceability Administration Guide

Loading Real-Time Monitoring, Cisco CallManager Serviceability Administration Guide

Using Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS), Cisco CallManager Serviceability Administration Guide

Trace Configuration Tool

The Cisco CallManager Serviceability 4.1(2) Trace Configuration Tool includes the following changes.

Provides trace parameters for the Cisco Certificate Authority Proxy Function service.

Provides renamed trace fields for the Quality Report Tool (QRT) service. In previous releases, the Cisco Call Back service shared these trace fields, and they contained "Call Back" in the field name instead of "QRT."

The following traces fields support QRT:

Enable QRT Event Handler Trace

Enable QRT Report Trace

Enable QRT Service Traces

Enable QRT DB Traces

Where To Find More Information

Configuring Cisco Certificate Authority Proxy Function Parameters, Cisco CallManager Serviceability Administration Guide

Configuring Cisco Extended Functions Trace Parameters, Cisco CallManager Serviceability Administration Guide

New and Changed Information for Third-Party and SDK Applications

This section describes the following new Cisco CallManager and third-party SDK applications features and changes that are pertinent to this release of Cisco CallManager:

JTAPI and TAPI Enhancements

JTAPI and TAPI Enhancements

JTAPI and TAPI applications support the following enhancements.

JTAPI

QSIG Path Replacement—Provides new interfaces to monitor a call when QSIG path replacement changes the Global Call ID.

CTI Super Provider—Provides new interfaces to disable device validation and enables applications to control and monitor any terminal in a Cisco CallManager cluster.

Device State Server—Provides new events that enable applications to monitor the state of all addresses on a terminal. Applications must turn the appropriate event filters on to receive the device state events.

MSJVM Migration—Provides the capability for cosmetic changes to JTAPI preference settings to occur while existing settings remain preserved.

TAPI

CTI Port Third-Party Monitoring—Enables TAPI applications to open a CTI port device in third-party mode.

JTAPI/TAPI

FAC/CMC—Supports new features to force the user to enter an authorization code before the call is extended (FAC) or enables the user to enter additional information, such as accounting or billing codes (CMC), in support of the call.

Where to Find More Information

For information about third-party and SDK applications, refer to the Cisco CallManager 4.1 Developer Documents at the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/voice/vpdd/cdd/4_1/

Important Notes

The following section contains important information that may have been unavailable upon the initial release of documentation for Cisco CallManager release 4.1(2).

CSCso79248 Do Not Run installxml.vbs in Unified CM Release 3.3 and Later

Adding Cisco CallManager Servers

Locale Installer for Cisco CallManager

Using the JTAPI Update Utility with CRS

Upgrade Requirements for CRS and Cisco CallManager 4.1

NetMeeting Calls Fail When T.38 is Advertised to NetMeeting

Cisco CallManager Installation Status Bar

CTI Route Point Considerations

Cisco CallManager Extension Mobility Scalability Update

Disabling IPSec for Cisco CallManager Upgrades

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.

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 by using the host name and add the same server by 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.

Locale Installer for Cisco CallManager

You can obtain locale-specific versions of the Cisco IP Telephony Network Locale installer for Cisco CallManager 4.1 at the following URL:

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.

Where to Find More Information

Cisco CallManager Features and Services Guide

Using the JTAPI Update Utility with CRS

Cisco Customer Response Solutions (CRS) servers include a JTAPI Update Utility that performs synchronization of the Cisco CallManager Plugin with the CRS server and the Cisco Agent Desktop (CAD). You must run this update tool to ensure successful operation of your CRS server.

If you have CRS or Cisco CallManager Extended Services installed (either co-located with the Cisco CallManager server or on a separate server) and you upgrade and/or install Cisco CallManager, you must take additional action to ensure plug-in synchronization.

Because an upgrade to a Cisco Call Manager server may include an updated JTAPI Plugin component, make sure that you run the JTAPI Update Utility on the CRS server to upgrade the JTAPI client. Running the JTAPI Update Utility on your CRS server, after you upgrade Cisco CallManager, ensures that the JTAPI Plugin is properly installed.


Note Simply executing the plug-in installer to install the JTAPI Plugin on the CRS server (instead of running the JTAPI Update Utility) does not copy the jtapi.jar file to the CRS share folder, leaving the update in an unfinished state.


For detailed information about the JTAPI Update Utility, refer to the Cisco Customer Response Applications Administrator Guide at http://www.cisco.com/univercd/cc/td/doc/product/voice/sw_ap_to/apps_3_5/english/admn_app/apadm35.pdf.

Upgrade Requirements for CRS and Cisco CallManager 4.1

Cisco CRS customers who currently run CRS version 3.5(1) with Cisco CallManager 4.0 (either co-located with the Cisco CallManager server or on a separate server) must upgrade their CRS servers to version 3.5(2) before they upgrade to Cisco CallManager 4.1.


Note The CRS 3.5(1) installer is not compatible with Cisco CallManager 4.1; the CRS 3.5(1) installer may fail if you run it after you upgrade your server to Cisco CallManager 4.1.


Because of the incompatibility issue, you must re-run the CRS 3.5(1) installer after deployment in the following situations:

Disaster recovery where a re-installation of the CRS 3.5(1) software is required to stabilize the system—In this case, a restore from backup requires CRS 3.5(1); otherwise, historical data and some configuration data will be lost.

Upgrade of the CRS product license to obtain additional functionality—In this case, the CRS 3.5(1) installer fails, but the CRS 3.5(2) installer succeeds.


Note CRS 3.5(2) is compatible with both Cisco CallManager 4.0 and Cisco CallManager 4.1.


For more information, refer to http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef83104

NetMeeting Calls Fail When T.38 is Advertised to NetMeeting

When a call is made to or from NetMeeting, and the calling/called device advertises T.38 to NetMeeting in the Terminal Capability Set (TCS), NetMeeting does not correctly acknowledge the TCS and the call times out. If T.38 is not advertised to NetMeeting, the call completes.

To ensure successful call completion, configure the calling/called device to not advertise T.38 to NetMeeting or use a calling/called device that does not advertise T.38.

For more information, refer to http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef36817.

Cisco CallManager Installation Status Bar

During the installation or upgrade of Cisco CallManager 4.1(2), you may see the installation program reset the status bar multiple times. The progress of the status bar may reset as each software package is being installed and as the installation program configures your machine. Make sure that you do not reboot the server unless the installation process prompts you to do so.

CTI Route Point Considerations

When a CTI route point contains 200 calls, the additional calls (above 200) exhibit slower performance. If the CTI application needs more than 200 calls, Cisco recommends that you configure multiple CTI route points.


Note Although Cisco CallManager Administration, Directory Number Configuration, provides a default value of 5000 for the Maximum Number of Calls parameter, degradation begins to display after 200 active calls.


Cisco CallManager Extension Mobility Scalability Update

The Cisco CallManager Features and Services Guide states that Cisco CallManager Extension Mobility supports a maximum of 2000 sequential login and logout operations per hour. This number represents the minimum supported logins or logouts.

Cisco CallManager Extension Mobility running on larger hardware platforms, such as the MCS-7845, may support more sequential login (or logout) operations per hour. For example, the MCS-7845 can support 4500 login or logout operations per hour.

Disabling IPSec for Cisco CallManager Upgrades

Cisco recommends that you temporarily disable the IP Security Protocol (IPSec) before you upgrade your Cisco CallManager server to release 4.1(2).

If you enabled IPSec on your server, you must perform the configuration steps as shown in "Disabling IPSec on the Cisco CallManager Server" section to disable this security protocol before you begin the upgrade process.

After you have completed the Cisco CallManager upgrade, you must re-enable IPSec. See the "Enabling IPSec on the Cisco CallManager Server" section for configuration information.

Disabling IPSec on the Cisco CallManager Server

To disable IPSec, perform the following steps:

Procedure


Step 1 Choose Start > Programs > Administrative Tools > Local Security Policy.

Step 2 Double-click IP Security Policies on Local Machine to view the local security settings.


Tip You can type the secpol.msc command from a command prompt as an alternative to following Step 1 and Step 2.


Step 3 Look for the Policy Assigned column, that displays in the right window pane, to identify the active policy for the Cisco CallManager server.


Tip Be sure to make a note of the active security policy so that you can enable this policy after the upgrade.


Step 4 Right-click the active policy and select unassign.


Enabling IPSec on the Cisco CallManager Server

After you have completed the Cisco CallManager upgrade to release 4.1(2), you must re-enable IPSec on your Cisco CallManager server.

To enable IPSec, perform the following steps:

Procedure


Step 1 Choose Start > Programs > Administrative Tools > Local Security Policy.

Step 2 Double-click IP Security Policies on Local Machine to view the local security settings.


Tip You can type the secpol.msc command from a command prompt as an alternative to following Step 1 and Step 2.


Step 3 Look for the Policy Assigned column, that displays in the right window pane, to identify the policy for the Cisco CallManager server.

Step 4 Right-click the policy that was previously active on your server and select assign.


Resolved Caveats for Cisco CallManager - Release 4.1(2)

Resolved caveats are no longer listed in the Cisco CallManager Release Notes. Instead, you can find the latest resolved caveat information through Bug Toolkit, which is an online tool that is available for customers to query defects according to their own needs.


Tip You need an account with Cisco.com (Cisco Connection Online) to use the Bug Toolkit to find open and resolved 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.


Bug Toolkit

To access Bug Toolkit, you need the following items:

Internet connection

Web browser

Cisco.com user ID and password

To use Bug Toolkit, follow this procedure.

Procedure


Step 1 To access the Bug Toolkit, go to http://www.cisco.com/pcgi-bin/Support/Bugtool/launch_bugtool.pl.

Log on with your Cisco.com user ID and password.

Step 2 Click the Launch Bug Toolkit hyperlink.

Step 3 If you are looking for information about a specific caveat, enter the ID number in the "Enter known bug ID:" field.

To view all caveats for Cisco CallManager, go to the "Search for bugs in other Cisco software and hardware products" section, and enter Cisco CallManager in the Product Name field. Alternatively, you can scroll through the product name list and click Cisco CallManager.

Step 4 Click Next. The Cisco CallManager search window displays.

Step 5 Choose the filters to query for caveats. You can choose any or all of the available options:

a. Select the Cisco CallManager version:

Choose the major version for the major releases (such as, 4.1, 4.0, 3.3).

A major release contains significant new features, enhancements, architectural changes, and/or defect fixes.

Choose the revision for more specific information; for example, choosing major version 4.1 and revision version 2 queries for release 4.1(2) caveats.

A revision (maintenance) release primarily contains defect fixes to address specific problems, but it may also include new features and/or enhancements.

b. Choose the Features or Components to query; make your selection from the "Available" list and click Add to place your selection in the "Limit search to" list.

To query for all Cisco CallManager caveats for a specified release, choose "All Features" in the left window pane.


Note The default value specifies "All Features" and includes all of the items in the left window pane.


To query only for Cisco CallManager-related caveats, choose "ciscocm;" then click Add.

To query only for phone caveats, choose "ciscocm-phone;" then click Add.

To query only for gateway caveats, choose "voice-gateway;" then click Add.

c. Enter keywords to search for a caveat title and description, if desired.


Note To make queries less specific, use the All wildcard for the major version/revision, features/components, and keyword options.


d. Choose the Set Advanced Options, including the following items:

Bug Severity level—The default specifies 1-3.

Bug Status Group—Check the Fixed check box for resolved caveats.

Release Note Enclosure—The default specifies Valid Release Note Enclosure.

e. Click Next.

Step 6 Bug Toolkit returns the list of caveats on the basis of your query. You can modify your results by submitting another query and using different criteria.



Note For complete Cisco IP Phone firmware release note information, refer to the applicable firmware release notes for your specific model IP phone at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/.


Open Caveats for Cisco CallManager - Release 4.1(2)

Table 3 describes possible unexpected behaviors by Cisco CallManager release 4.1(2), sorted by component. Unless otherwise noted, these caveats apply to all Cisco CallManager 3.0 releases up to and including Cisco CallManager release 4.1(2).


Tip If you have an account with Cisco.com, you can use the Bug Toolkit to find caveats of any severity for any release. Bug Toolkit may also provide a more current listing than what is reflected in this document. To access the Bug Toolkit, log on to http://www.cisco.com/pcgi-bin/Support/Bugtool/launch_bugtool.pl.


Table 3 Open Caveats for Cisco CallManager Release 4.1(2) 

Identifier

Headline

 

Component: Call Processing

CSCef22049

Call Control: The system creates an extra call connection after a second call transfer is done.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef22049

CSCef24993

Call Control: Lack of instruction and feedback on the phone make it difficult for the user to complete Transfer and Conference tasks.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef24993

CSCef38277

Call Control: Incorrect call event and call information displays after a call is unparked.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef38277

CSCef83048

Call Control: CRS agents are stuck in a reserved state because of a missing JTAPI event.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef83048

CSCef51798

CDR: Under certain circumstances, the cause value is not getting populated in the CDR record for a conference call.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef51798

CSCef33465

Change Notify: CFwdAll remains active after the Extension Mobility user logs off.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef33465

CSCin69640

Digit-Analysis: Under certain circumstances, called number transformation does not occur in the translation pattern.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin69640

CSCef31459

Huntlist: Secondary Cisco CallManager nodes report high expected delay and enter Code Yellow when a large number of RouteLists/HuntLists are registered to one node and the primary Cisco CallManager node goes offline.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef31459

CSCef40774

Huntlist: Circular call distribution does not work correctly with Extension Mobility lines.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef40774

CSCef71972

Huntlist: Route group does not load balance on second priority gateways.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef71972

CSCee25670

MGCP: MGCP T1-CAS calls fail when the gateway is using the Cisco CallManager automated configuration.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCee25670

CSCef36872

MGCP: After changing a route pattern or destination number, reset the gateway; otherwise, the trunk (or endpoint that is getting a new destination number) may become unusable.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef36872

CSCef58219

MGCP: Inbound calls to an MGCP-controlled gateway may fail when Cisco CallManager takes some channels out of service and fails to provide the status to the gateway.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef58219

CSCef64202

MGCP: Calls through a T1 CAS/T1 PRI gateway take 30 seconds to disconnect.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef64202

CSCef82095

PRI: When an MLPP precedence call is made through an MGCP PRI gateway and a multi-feature switch (MFS), a Blocked Precedence Call (BPA) announcement is played twice.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef82095

CSCef83478

PRI: The progress indicator is missing from the progress message, which causes calls to disconnect.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef83478

CSCef87122

PRI: Cisco CallManager plays a reorder tone for a call that is established and then disconnected with a value of 0XFF.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef87122

CSCef81549

QSIG: The message waiting lamp on an IPMA manager phone that is using QSIG MWI does not light if the CSS on the incoming gateway where QSIG MWI is received does not contain a partition with the manager phones.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef81549

CSCef81181

SCCP: A parked phone remains in the connected state after the CallPark reversion timer expires.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef81181

CSCef43625

SS-CallBack: CallBack activation does not occur immediately after a call is diverted.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef43625

CSCef62437

SS-CallBack: Cisco CallManager may generate a CallBack notification screen if a monitored phone disconnects and then reconnects to the network when two Cisco CallManager clusters are connected via QSIG trunks.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef62437

CSCef65767

SS-CallBack: An SDI trace alarm displays an "Entry not found in userCallTable for key" error when running 7,500 SimPhones at a 51,000 BHCA rate, degrading system performance.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef65767

CSCef69260

SS-CallBack: CallBack cannot be activated on the manager when the assistant goes offline.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef69260

CSCef77425

SS-CallBack: When the CallBack feature is activated from a DN that is located on a 7914, the CallBack activation screen may not display.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef77425

CSCef78518

SS-CallBack: CallBack notification is returned even though the phone displays that CallBack is not active.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef78518

CSCef27106

SS-Transfer: The display restriction information that is set in the translation pattern does not carry over in the alerting/connected states.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef27106

CSCef81206

SS-Transfer: A call that is transferred to the same phone cannot be answered.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef81206

CSCef78397

Supplementary Services: A missed call from a conference does not display on the phone.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef78397

CSCee40188

System: An update to the Cisco CallManager service is needed to provide the correct order of dependent services in the SCM database.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCee40188

CSCef32076

System: Call failures occur due to call throttling under load testing.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef32076

CSCef59815

System: The ccm.exe initialization fails with an access violation message.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef59815

CSCef21983

SDL: Inservice event does not get sent to observed device.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef21983

 

Component: CMCTI

CSCef39271

The system incorrectly reports a redirect failure because of a busy destination when the failure occurs because of a call disconnect due to expiration of the "new call accept timer."

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef39271

CSCef86928

You must restart CTI Manager after a JTAPI upgrade; otherwise, the JTAPI sub system does not become active.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef86928

 

Component: Database/Database Administration/MLA

CSCed76614

Database: Aupair.exe application error displays during CCM upgrade.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCed76614

CSCef68656

Database: If you enable CDRs, you must back up the CDR database periodically to maintain the proper CDR file size; otherwise, adverse affects may occur during the installation process.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef68656

CSCee64893

Admin: The External Route Plan wizard returns an error on the Gateway information window.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCee64893

CSCef09891

Admin: The IIS service occasionally fails to respond, which causes the Cisco CallManager web services to stop responding.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef09891

CSCef42822

Admin: If you configure the web browser (on a Cisco CallManager server or on a remote machine) to use a proxy server for web access, the Cisco CallManager Administration windows do not function properly when accessed from the browser.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef42822

CSCef47354

Admin: Popup windows appear intermittently when Cisco CallManager Administration is used with JRE.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef47354

CSCef57648

Admin: When you process multiple updates to the user information and password, the device that is associated with a user no longer displays as being associated if you do not refresh the user configuration window before you change the password.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef57648

CSCef73096

Admin: The authentication and proxy server address fields in the Cisco CallManager Administration Phone Configuration window accept invalid characters, such as !@#$%^&*.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef73096

CSCef78550

Admin: The system returns an error when an existing DN is assigned as a Meet-me number.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef78550

CSCef79869

Admin: Phone services can be unsubscribed from the Cisco CallManager user window when the user is logged into the phone.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef79869

CSCef81227

Admin: A remote scripting error displays when you click the update button on the AutoGenerated Device Profile window.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef81227

CSCin59391

Admin: The system should validate gateway availability before device insertion into a route group.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin59391

 

Component: Directory

CSCef61784

A bulk provider search for a large number of user IDs displays an "Administrative Limit exceed" error.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef61784

CSCef82196

An API is needed to get and update the MLA user base from LDAP so the MLA User Group window can read the correct value from the database for Active Directory.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef82196

CSCef82694

When you configure Cisco CallManager with Active Directory, the Add User window returns an error if the user ID field contains special characters, such as *,:,[,],/,|,.,?

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef82694

 

Component: DNA/Extension Mobility/IPMA

CSCef69003

DNA: DNA installation rollback fails to unregister the DNA service.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef69003

CSCef85554

DNA: The DNA Find and List Phones window does not display records that contain a slash (\) in the description.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef85554

CSCef85556

DNA: The DNA Find and List Trunks window does not display records that contain a slash (\) in the description.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef85556

CSCef86759

DNA: The DNA results display the Device Destination field instead of the renamed Call Classification field.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef86759

CSCeb39815

EM: The "remember last userid" feature does not work on first time user login after a Cisco CallManager upgrade.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCeb39815

CSCef72785

EM: Some Cisco CallManager features do not work for users who were logged into their phones during an upgrade.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef72785

CSCef03674

IPMA: IPMA Assistant Console buttons (login, dial, answer) disappear when the console is idle for about 45 minutes.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef03674

CSCef05164

IPMA: The Time-of-Day Routing feature does not work correctly with IPMA.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef05164

CSCef07143

IPMA: The search results for IPMA return a blank window after a change is made.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef07143

CSCef31825

IPMA: CPU usage reaches 100 percent when the IPMA link is accessed from the user configuration window.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef31825

CSCef33888

IPMA: User input (service parameters) are set to null/empty when you click on "Set to Default."

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef33888

CSCef40461

IPMA: IPMA Manager User Configuration window returns an error when Assistant is added first.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef40461

CSCef68071

IPMA: Manager phone cannot intercept a conference call.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef68071

CSCef70182

IPMA: IPMA lines remain grayed out on Assistant Console after IPMA failover.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef70182

CSCin76264

IPMA: A new call to the assistant console does not make My Calls sub window visible if the pop-to-top feature is disabled and My Calls sub window is minimized.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin76264

CSCin79891

IPMA: When you cancel after choosing Manager > Configuration > Divert Tab and selecting `Directory Number,' an incorrect information message appears on the console.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin79891

CSCin80718

IPMA: DND/DivAll/Filter settings of a manager are not preserved across IPMA service failover.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin80718

CSCin81575

IPMA: Cisco CallManager Administration displays the incorrect name for the manager in the drop-down list on the assistant configuration screen if the manager name contains an apostrophe.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin81575

CSCin81669

IPMA: Login to the assistant console is not successful when the assistant has more than one manager and one of the managers is deleted from Cisco CallManager Administration.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin81669

CSCin81670

IPMA: After you configure new manager/assistant and launch the console, the manager phone displays an unknown status.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin81670

CSCin81761

IPMA: Manager phone status displays unknown on the console when you configure the Manager/Assistant in shared line mode.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin81761

CSCin81826

IPMA: The service URL speed dial does not show IPMA services on a Cisco IP Phone 7970 that is used as a manager phone.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin81826

CSCin81831

IPMA: The system allows the assistant configuration to be saved only when the proxy line is selected and there is no manager associated with the proxy line.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin81831

CSCin81843

IPMA: The IPMA service must be restarted after a second assistant is added to the manager.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin81843

CSCin82213

IPMA: The IPMA service does not work after the primary Cisco CallManager server goes offline and IPMA is reconnected after the standby server becomes active.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin82213

CSCin82373

IPMA: The assistant console window on the manager phone does not always display after IPMA service failover.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCin82373

 

Component: Documentation

CSCee85128

Time synchronization between Cisco CallManager servers and a configured time server stops working after upgrading to Cisco CallManager 4.1.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCee85128

 

Component: ES-SR-Wrapper

CSCef82841

DNA cannot be installed when you upgrade from Cisco CallManager 3.3(4)SR02 to Cisco CallManager 4.0 or 4.1.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef82841

 

Component: Install_Product

CSCef80853

Cisco CallManager overwrites the MDAC Security Update that is embedded within OS 2000.2.6 unless you install the latest OS 2000.2.6 SR after you install Cisco CallManager.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef80853

CSCef80879

The Cisco CallManager installation provides SQL SP3a but it does not include Microsoft Security Bulletin MS03-031, Cumulative Patch for Microsoft SQL Server (815495).

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef80879

 

Component: JTAPISDK/TAPISDK

CSCee66279

Deallocating the conference parent call on third-party-controlled CTI Port does not close the conferenced calls.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCee66279

CSCef28253

During load testing, JTAPI CreateCall takes a long time to finish, which causes a drop in busy hour call completion (BHCC).

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef28253

CSCef76823

CRS agents do not become active after the phone does not answer, when the phone is set to auto answer.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef76823

CSCef85069

When you attempt to transfer an ICD call to an available agent, the call may display as being aborted in the CRS real time report and an available agent cannot be offered a call in the queue (waiting for agent to become available).

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef85069

CSCef87142

After consult call failure, CRS does not take the original call off hold if the caller hangs up at the same time as the application is trying to unhold call.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef87142

 

Component: Media Streaming Application

CSCef72456

Cisco CallManager displays a blank screen and does not reboot after you reload the system when you are using live audio source with the Telex USB sound card.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef72456

 

Component: QED

CSCef39668

Add support for 3825 and 3845 gateways in Cisco CallManager Administration.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef39668

CSCef75296

Cisco CallManager 4.1(2) supports configuration of the Adhoc-Conference and Transcoding (ACT) module by defining the WS-SVC-CMM-MS module name in the Communication Media Module (CMM) interface.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef75296

 

Component: Security

CSCee40155

The Cisco CallManager service needs to update the SCM database with a list of dependent services.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCee40155

CSCee67043

Certificate upgrade option returns successful status if phone has no certificate.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCee67043

 

Component: Service Parameters

CSCef68394

The value descriptions for True/False are reversed on the H225 Block Setup Destination service parameter.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef68394

 

Component: Serviceability/RisDC

CSCef58246

RisDC: The RisDC process causes Cisco CallManager CPU usage to spike about every 5 minutes for a duration of about 3 seconds.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef58246

 

Component: Upgrade Assistant

CSCef86300

The Cisco IP Phone 7970 might display "Error Updating Locale" because of a missing `glyphs.xml' file.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef86300

 

Component: Video

CSCee65443

One-way video occurs when VTA retrieves a parked ICT video call.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCee65443

The following firmware caveats apply to this release.

CSCef57170

G.723 calls between two media termination point (MTP) hardware transcoders fail.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef57170

CSCef62209

When you update the port direction of the 6624 port, the port configuration page does not reflect the changes.

http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef62209



Note For complete Cisco IP Phone firmware release note information, refer to the applicable firmware release notes for your specific model IP phone at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/.


Documentation Updates

This section provides documentation changes that were unavailable when the Cisco CallManager release 4.1(2) documentation suite was released.

This section contains the following types of documentation updates:

Errors

Changes

Omissions

Errors

This section includes errors that the Cisco CallManager Documentation suite contains.

Java Runtime Environment

Cisco CallManager Dialed Number Analyzer Service Startup Type

Barging into Encrypted Calls with the Cisco IP Phone Model 7970

Using Valid Characters in Cisco CallManager User IDs

Incorrect Reference in the Cisco CallManager Security Guide

Removing a Subscriber Server from Cisco CallManager

Using Script Files to Remove a Subscriber Server from Cisco CallManager

Java Runtime Environment

The Cisco CallManager Administration Guide does not contain the most current information about installing JRE for use with Cisco CallManager Administration. See the "Requirement for Installation of Java Virtual Machine" section for the complete information.

Cisco CallManager Dialed Number Analyzer Service Startup Type

The "Installing Cisco CallManager Dialed Number Analyzer" chapter in the Cisco CallManager Dialed Number Analyzer Guide contains incorrect information about setting the service startup type to "Manual" after successful installation of DNA. The Dialed Number Analyzer service startup type actually gets set to "Automatic."

The text in the Cisco CallManager Dialed Number Analyzer Guide should state the following:

When installation is successful, the Dialed Number Analyzer service installs and starts. The service startup type gets set to Automatic.

Barging into Encrypted Calls with the Cisco IP Phone Model 7970

The Cisco CallManager Security Guide does not specify the phone models that are affected by barging into encrypted calls. The following information pertains only to the Cisco IP Phone model 7970 and becomes applicable with availability of the compatible phone firmware image.

Cisco CallManager 4.1(2) does not support barging into an encrypted call if the phone that is used to barge is not configured for encryption. When barge fails in this situation, a busy tone plays on the phone where the user initiated the barge.

Using Valid Characters in Cisco CallManager User IDs

The Add A New User chapter in the Cisco CallManager Administration Guide and the Cisco CallManager online help documentation contain incorrect information about the use of special characters in the User ID field.

Specifically, the UserID field in the User Configuration Settings under the
User > Add a New User menu incorrectly states that you may use special characters when you configure a Cisco CallManager user ID.

Special characters, such as =, +, <, >, #, ;, \, , "" and blank spaces, are not valid and may not be used. You must use alphanumeric characters only.

For more information, refer to http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef71945.

Incorrect Reference in the Cisco CallManager Security Guide

The Cisco CallManager Security Guide in the Cisco CallManager Administration 4.1(2) online help erroneously refers to Cisco CallManager version 4.1(1). The document should refer to Cisco CallManager version 4.1(2).

The online version of the Cisco CallManager Security Guide includes reference to the correct Cisco CallManager release number.

Removing a Subscriber Server from Cisco CallManager

The following information provides corrections and replaces the contents of the Cisco CallManager Administration Guide, Appendix B, Removing a Subscriber Server from Cisco CallManager.

You can delete a subscriber server from the Cisco CallManager cluster by using the Server Configuration window in Cisco CallManager Administration. This deletion removes the server from the Cisco CallManager Administration database, but it does not delete all of the server dependencies.

To fully delete a server from the system, you must perform the following steps:

Procedure


Step 1 Remove all dependencies from the server; for example, delete the Cisco CallManager service.

For additional information, refer to the Cisco CallManager Administration Guide, Deleting a Server chapter.


Tip To view the dependencies, click the Dependency Records link on the Server Configuration window. For more information about Dependency Records, refer to the Cisco CallManager Administration Guide, Appendix A.


Step 2 Deactivate the services from the server.

Refer to the Cisco CallManager Serviceability Administration Guide, Service Activation chapter, for more information.

Step 3 Remove the server from Cisco CallManager Administration.

Refer to the Cisco CallManager Administration Guide, Deleting a Server chapter, for more information.

Step 4 If the Cisco CallManager cluster is integrated with the local DC Directory, run the command file from the command prompt that removes the DCD replication agreements from the publisher.

See the "Remove Redundant DCD Replication Agreements" section for more information.


Remove Redundant DCD Replication Agreements

After you remove the subscriber server from the cluster, you must clean the DCD replication information from the publisher DCD by running the Clean_publisher command file. (This command file only executes on the publisher server.)

You can access this command file on servers that are running Cisco CallManager release 3.3 and later. Cisco CallManager installs the Clean_publisher command file on the server during installation of the Cisco Directory component.

To clean the DCD replication information, enter the following command from any directory on the publisher server:

c:\Clean_publisher.cmd


Note If you remove the server without running the Clean_publisher.cmd command file and then add the server back with the same host name into the same cluster from where it was removed, the DCD script that is used to configure the subscriber DCD will clean up the previous DCD replication agreement from the publisher DCD database during the Directory installation of the Cisco CallManager installation on the server.


Using Script Files to Remove a Subscriber Server from Cisco CallManager

The following information provides corrections and replaces the content that appears in the Cisco CallManager Administration Guide, Appendix B.

To remove a subscriber server from Cisco CallManager, see the "Removing a Subscriber Server from Cisco CallManager" section.

If your attempts to remove a server were not successful, perform the following steps:

Procedure


Step 1 Run the script file that cleans up subscriber-related database records and removes the SQL replication information from the publisher server.

See the "Remove Subscriber Information" section.

Step 2 If the Cisco CallManager cluster is integrated with the local DC Directory, run the command file that removes the DCD replication agreements from the publisher.

For more information, refer to the Cisco CallManager Administration Guide, Appendix A.


Remove Subscriber Information

If the server removal was unsuccessful, run the script file that cleans up subscriber-related database records and removes the SQL replication information. Run the script file for the publisher server and the script file for the subscriber server.

See the "Contents of the RemovePublisher.bat Script File" section and the "Contents of the RemoveSubscriber.bat Script File" section for more information.


Tip Copy the script file contents from Example 1 and Example 2 to a Notepad file and save it with a .bat extension; for example, RemovePublisher.bat and RemoveSubscriber.bat.


Run RemovePublisher.bat Script on Publisher

Execute the RemovePublisher.bat script file from the Cisco CallManager publisher server for the cluster containing the subscriber that you want to remove. This script runs from the command prompt from any directory.


Tip To view the procedure that runs the script, run the script with no parameters.


From any directory on the publisher server, enter the following command:

<path where you saved the script>:\RemovePublisher "server" "database" "name_of_server_to_delete_from_database connection string"

To find the database connection string name, follow these steps:

Procedure


Step 1 Navigate to Service > Service Parameters.

Step 2 Choose Cisco Database Layer Monitor.

Step 3 Click Advanced.

Step 4 Obtain the name from the Database Connection String field.

For example, DSN=CiscoCallManager;Server=ABC2.


When you run this command from the command prompt, errors display; no separate error log file gets generated.

To view the contents of the script file, see the "Contents of the RemovePublisher.bat Script File" section.

Contents of the RemovePublisher.bat Script File

Example 1 displays the contents of the script file that cleans up subscriber-related database records and removes the SQL replication information from the publisher server.

Example 1 Script File Contents

@echo off 
@if "%3x" == "x" goto Usage 
echo Install stored procedure in database %2 
echo USE %2 > temp.sql  
echo GO >> temp.sql 
echo DROP PROCEDURE dblRemoveServerFromDB >> temp.sql 
echo GO >> temp.sql 
echo CREATE PROCEDURE [dblRemoveServerFromDB] >> temp.sql 
echo (@servername NVARCHAR(50),@ispublisher NVARCHAR(50)) AS >> temp.sql 
echo BEGIN TRANSACTION >> temp.sql 
echo DECLARE @nodeid NVARCHAR(50), @deviceid NVARCHAR(50), @pnsid NVARCHAR(50) >> temp.sql 
echo -- >> temp.sql 
echo PRINT 'Get the Node ID' >> temp.sql 
echo SELECT @nodeid=pkid from ProcessNode where name=@servername >> temp.sql 
echo -- >> temp.sql 
echo PRINT 'Delete associated Device and MediaMixer' >> temp.sql 
echo WHILE (SELECT COUNT(*) FROM Device WHERE fkProcessNode=@nodeid) ^> 0 >> temp.sql 
echo BEGIN >> temp.sql 
echo     SELECT @deviceid=pkid from Device where fkProcessNode=@nodeid >> temp.sql 
echo     PRINT 'Delete MediaMixer' >> temp.sql 
echo     DELETE FROM MediaMixer WHERE fkDevice=@deviceid >> temp.sql 
echo     PRINT 'Delete MOHServer' >> temp.sql 
echo     DELETE FROM MOHServer WHERE fkDevice=@deviceid >> temp.sql 
echo     PRINT 'Delete Device' >> temp.sql 
echo     DELETE FROM Device WHERE pkid=@deviceid >> temp.sql 
echo END >> temp.sql 
echo -- >> temp.sql 
echo PRINT 'Delete associated CallManager records' >> temp.sql 
echo DELETE FROM CallManagerGroupMember FROM CallManagerGroupMember AS M >> temp.sql 
echo   JOIN CallManager AS C ON C.pkid=M.fkCallManager WHERE C.fkProcessNode=@nodeid >> temp.sql 
echo DELETE FROM CallManager WHERE fkProcessNode=@nodeid >> temp.sql 
echo -- >> temp.sql 
echo PRINT 'Delete associated ProcessConfig records' >> temp.sql 
echo DELETE FROM ProcessConfig WHERE fkProcessNode=@nodeid >> temp.sql 
echo -- >> temp.sql 
echo PRINT 'Delete associated AlarmConfig records' >> temp.sql   
echo DELETE FROM AlarmConfig FROM AlarmConfig AS A JOIN ProcessNodeService >> temp.sql   
echo   AS S ON A.fkProcessNodeService=S.pkid WHERE S.fkProcessNode=@nodeid >> temp.sql   
echo PRINT 'Delete associated ProcessNodeService records' >> temp.sql 
echo DELETE FROM ProcessNodeService WHERE fkProcessNode=@nodeid >> temp.sql 
echo -- >> temp.sql 
echo PRINT 'Delete associated ComponentVersion records' >> temp.sql 
echo DELETE FROM ComponentVersion WHERE fkProcessNode=@nodeid >> temp.sql 
echo -- >> temp.sql 
echo PRINT 'Delete the node' >> temp.sql 
echo DELETE FROM ProcessNode WHERE pkid=@nodeid >> temp.sql 
echo -- >> temp.sql 
echo COMMIT TRANSACTION >> temp.sql 
echo GO >> temp.sql 
echo -- Execute procedure on server %1                                                                                                                 
echo exec dblRemoveServerFromDB '%3' >> temp.sql                            
osql -S %1 -d %2 -E -e -i temp.sql                                                                                              
del temp.sql                                                                                                                    
echo USE %2 > temp1.sql  
echo sp_dropsubscription @publication = %2, @subscriber = '%3', @article='all' >> temp1.sql 
echo GO >> temp1.sql 
osql -S %1 -d %2 -E -e -i temp1.sql                                                        
del temp1.sql 
goto endd                                                                                                                       
:Usage 
@echo Usage:   RemoveServerFromDB "server" "database" "name_of_server_to_delete_from_ProcessNode.Name"  
@echo Example: RemoveServerFromDB . CCM0300 fred.cisco.com  
:endd 

Contents of the RemoveSubscriber.bat Script File

Example 2 displays the contents of the script file that removes the SQL replication information from the subscriber server.

Example 2 Script File Contents

@echo off 
@if "%2x" == "x" goto Usage 
echo Install stored procedure in database %2 
echo sp_removedbreplication @dbname = %2 > temp1.sql 
echo GO >> temp1.sql 
osql -S %1 -d %2 -E -e -i temp1.sql                                                        
del temp1.sql 
goto endd                                                                                                                                          
:Usage 
@echo Usage:   RemoveSubscription "server" "database"  
@echo Example: RemoveSubscription . CCM0300  
:endd 

Changes

This section contains changes that have occurred since the original release of the Cisco CallManager release 4.1 documentation. These changes do not currently appear in the current documentation or the online help for the Cisco CallManager application.

Associating H.323 Devices to Users

Associating H.323 Devices to Users

In Cisco CallManager release 4.0, administrators could not associate H.323 devices with a user; therefore, the administrator could not configure features on the H.323 endpoints in the Cisco CallManager Administration User Configuration window.

Cisco CallManager release 4.1(2) corrects this behavior by displaying all devices, in addition to CTI-controllable devices, and by allowing the administrator to choose H.323 devices in the Device Association window.

For devices that are not CTI-controllable, such as H.323 devices, an asterisk (*) displays next to the device icon. All device association behavior remains identical regardless of the type of device for which the feature is configured.

Omissions

This section lists new and additional information that the current Cisco CallManager documentation does not include:

? Icon Displays Incorrect Online Help for Region and Calling Search Space Pop p Windows

Name Change for the Cisco IAD 2400 Gateway Type in Cisco CallManager Administration

Route List Redundancy Configuration

Cisco IP Phone Models 7940/7960 Built-in Bridge and Device Security Considerations

CAPF Interaction When Cisco IP Phone Resets

Using Server Authentication, Third-Party CA Certificates

Using Shared Lines with Encrypted Devices

Reinstalling Dialed Number Analyzer after a Cisco CallManager Upgrade

Personal Directory

Support for the Cisco VG224 Gateway

? Icon Displays Incorrect Online Help for Region and Calling Search Space Pop p Windows

When you press the "?" bubble for online help in either the Regions or CSS popup search window, the online help for Partitions displays instead.

The online help for Regions/CSS should state the following information:

If more than 250 regions/calling search spaces exist, the ellipsis (...) button displays next to the Regions/CSS drop-down list box on the Cisco CallManager Administration windows where the button appears. You can click the (...) button to search for the region/CSS that you want.

Use the following procedure to search for a region/CSS:

Procedure


Step 1 Click the ... button next to the Region/Calling Search Space drop-down list box.

The Select Region/Select Calling Search Space window displays.

Step 2 In the List items where Name contains field, enter a partial region/calling search space name.

Step 3 In the list of regions/calling search spaces that displays in the Select item to use box, click the desired region/calling search space name.

Step 4 Click OK.


Name Change for the Cisco IAD 2400 Gateway Type in Cisco CallManager Administration

In the "Add a New Gateway" window in Cisco CallManager Administration, the "Cisco IAD 2420 (end-of-sale product)" gateway type replaced the Cisco IAD 2400 gateway type.

Use the Cisco IAD 2420 gateway type to add a new Cisco IAD 2420 gateway to Cisco CallManager.


Note The system does not support the Cisco IAD 2430 gateway for use with Cisco CallManager.


For more information, refer to http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef30742.

Route List Redundancy Configuration

The Cisco CallManager System Guide does not include the following information about route list redundancy.

From Cisco CallManager release 4.0(2), route list handling and redundancy was changed to improve performance. Pre-4.0(2) implementations included route lists on every server in a cluster. After upgrade to release 4.0(2) or later, only one instance of the active route list configuration associates with a Cisco CallManager group. This change requires that you configure the Cisco CallManager Group(s) to maintain load balancing and redundancy.

After you upgrade the Cisco CallManager servers to 4.0(2) or later, and if two or more primary Cisco CallManager servers exist in the cluster, the system creates new Cisco CallManager Group(s) with a default name of "RLCMG_<primary Cisco CallManager name>." The system creates one Cisco CallManager Group for each primary server and the secondary server in the Cisco CallManager Group, which is the dedicated backup server. Depending on the number of servers in the cluster, the system creates one or multiple Cisco CallManager Groups.

One instance of the active route list configuration then attaches to the primary Cisco CallManager server in the first CallManager Group. New Cisco CallManager Groups get assigned to the existing route list configuration by using a round-robin algorithm to ensure redundancy.

To complete the upgrade, you must perform the following tasks:

1. Create new Cisco CallManager Group(s) to replace the default Cisco CallManager Group(s) that are named "RLCMG_<primary Cisco CallManager name>" and that were created during the upgrade.

2. Evaluate the Cisco CallManager Group and route list configuration for load balancing and redundancy.

3. Reconfigure the route list(s) to the user-created Cisco CallManager Group(s).

4. Delete the default Cisco CallManager Group(s).


Caution These activities drop all dependent active calls and cause significant overhead while you perform the reconfiguration.

For more information, refer to http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCee30571.

Where to Find More Information

"Route List Configuration," Cisco CallManager Administration Guide

Cisco IP Phone Models 7940/7960 Built-in Bridge and Device Security Considerations

The "Cisco IP Phone Configuration" chapter in the Cisco CallManager Administration Guide, the "Barge" chapter in the Cisco CallManager Features and Services Guide, and the Cisco CallManager System Guide do not contain the following information about the configuration of the built-in bridge and device security for the Cisco IP Phones models 7940 and 7960.

Cisco IP Phone models 7940 and 7960 cannot support two media stream encryptions or SRTP streams simultaneously. This condition occurs when the phone is being barged from another phone and all of the phones in the call are using SRTP (the built-in bridge is enabled).


Note To prevent phone instability due to this condition, the system automatically disables the built-in-bridge for the Cisco IP Phone models 7940 and 7960 when the device security mode is set to encrypted.


If you attempt to configure barge for Cisco IP Phone models 7940 and 7960 that are configured for encryption, the following message displays:

If you configure encryption for Cisco IP Phone models 7940 and 7960, those encrypted devices cannot accept a barge request when they are participating in an encrypted call. When the call is encrypted, the barge attempt fails.

The message displays whenever you perform the following tasks in Cisco CallManager Administration:

In the Phone Configuration window, you choose Encrypted for the Device Security Mode (or System Default equals Encrypted), On for the Built In Bridge setting (or default setting equals On), and you click Insert or Update after you create this specific configuration.

In the Enterprise Parameter window, you update the Device Security Mode parameter.

In the Service Parameter window, you update the Built In Bridge Enable parameter.


Tip You must reset the dependent Cisco IP devices for changes to take effect.


Refer to the Cisco CallManager Security Guide for additional information.

CAPF Interaction When Cisco IP Phone Resets

The Cisco CallManager Security Guide does not contain the following information about how CAPF interacts with the Cisco IP Phone when the phone is reset by a user or by Cisco CallManager.

In the following examples, if an LSC does not already exist in the phone and if By Existing Certificate is chosen for the CAPF Authentication Mode, the CAPF certificate operation will fail.

Example —Nonsecure Device Security Mode

In this example, the phone resets after you configure the Device Security Mode to Nonsecure and the CAPF Authentication Mode to By Null String or By Existing Certificate (Precedence...). After the phone resets, it immediately registers with the primary Cisco CallManager and receives the configuration file. The phone then automatically initiates a session with CAPF to download the LSC. After the phone installs the LSC, configure the Device Support Mode to Authenticated or Encrypted.

Example—Authenticated/Encrypted Device Security Mode

In this example, the phone resets after you configure the Device Security Mode to Authenticated or Encrypted and the CAPF Authentication Mode to By Null String or By Existing Certificate (Precedence...). The phone does not register with the primary Cisco CallManager until the CAPF session ends and the phone installs the LSC. After the session ends, the phone registers and immediately runs in authenticated or encrypted mode.


Note You cannot configure By Authentication String in this example because the phone does not automatically contact the CAPF server; the registration fails if the phone does not have a valid LSC.


Using Server Authentication, Third-Party CA Certificates

The Cisco CallManager Security Guide does not contain the following information about using a server authentication, third-party CA certificate instead of the self-signed HTTPS certificate.

Follow these steps to ensure that Cisco CallManager HTTPS-enabled applications can download the third-party certificate when you use server authentication, third-party CA certificates for HTTPS:

1. Refer to the Cisco CallManager Security Guide for information about deleting the HTTPS certificate and installing the third-party CA certificate on the IIS default website.

2. Install the third-party CA certificate on the IIS default website, as documented in the Cisco CallManager Security Guide.

3. Rename the Root CA certificate to httpscert.cer.

4. Copy the certificate to C:\program files\cisco\certificates in DER format.

Using Shared Lines with Encrypted Devices

The Cisco CallManager Security Guide does not contain the following information about using shared lines with encrypted devices.

When you configure a shared line for an encrypted Cisco IP Phone model 7970, be sure to configure all devices that share the lines for encryption; that is, ensure the device security mode for all devices is set to encrypted.

Reinstalling Dialed Number Analyzer after a Cisco CallManager Upgrade

The Cisco CallManager Dialed Number Analyzer Guide does not contain the following information about reinstalling DNA after a Cisco CallManager upgrade.

If you upgrade Cisco CallManager on every server in a cluster, you must reinstall the Dialed Number Analyzer plugin on the required node in the cluster.

If you have installed Dialed Number Analyzer to use data from Cisco CallManager to perform analysis of a numbering plan, you must reinstall Dialed Number Analyzer plugin on the server that you are using for numbering plan analysis. Reinstalling the plugin synchronizes any additional data entries available in Cisco CallManager with the Dialed Number Analyzer database.

Follow this procedure to install Dialed Number Analyzer:

Procedure


Step 1 Access Cisco CallManager and choose Application > Install Plugins.

The Install Plugins window displays.

Step 2 Locate the Dialed Number Analyzer Plugin.

Step 3 Click the executable icon for Dialed Number Analyzer Plugin to launch the InstallShield Wizard.

Step 4 Click Open. The InstallShield Wizard for Cisco Dialed Number Analyzer window displays.

Step 5 Click Next at the Welcome to the InstallShield Wizard for Cisco Dialed Number Analyzer window.

The Enter Private Phrase window displays.

Step 6 Enter the private phrase for this cluster in the Enter Private Phrase window.

Step 7 Click Next.

If the private phrase is incorrect, a message displays. Return to Step 6. If the private phrase is correct, the Ready to Install the Program window displays.

Step 8 Click Install at the Ready to Install the Program window.

Step 9 Click Finish at the InstallShield Wizard Completed window.

The tool installs the Cisco Dialed Number Analyzer service on the machine.



Note When installation is successful, the Dialed Number Analyzer service installs and starts; the service sets the startup type to Automatic.


Personal Directory

Personal Directory provides a personal address book stored in the Cisco CallManager LDAP directory, a Cisco IP Phone synchronizer, and two Cisco IP Phone services: Personal Address Book and Personal Fast Dials.

The Cisco CallManager documentation does not contain the following information about configuring and using Personal Directory:

System Requirements

Configuring Personal Directory

Configuring the Personal Address Book Service

Configuring the Personal Fast Dials Service

Downloading the Cisco IP Phone Address Book Synchronizer

Preparing the Phone User for Personal Directory

System Requirements

The system requires the following components for use with Personal Directory:

Cisco IP Phones models 7940, 7960, 7970

A PC running Cisco CallManager 3.1 or later

A PC running Windows 2000

A Microsoft IIS Server

Microsoft Outlook and/or Outlook Express


Note Microsoft Outlook must be set up in Internet-only mode and the Windows Address Book must be configured to share entries.


Configuring Personal Directory

To configure the Personal Directory, you must configure the Personal Address Book Service and the Personal Fast Dials Service.

Configuring the Personal Address Book Service

Configuring the Personal Fast Dials Service

Configuring the Personal Address Book Service

You configure the Personal Address Book by adding the service to Cisco CallManager Administration and configuring the service parameters.

Follow this procedure to configure the Personal Address Book service:

Procedure


Step 1 Choose Feature > Cisco IP Phone Services.

The Cisco IP Phone Services Configuration window displays.

Step 2 In the Service Name field, enter the name of the service you want to display in the menu of available services on the Cisco IP Phone User Options window, for example, My Address Book.

Step 3 In the Service Description field, enter a description of the content provided by the service, for example, Personal Directory - Personal Address Book.

Step 4 In the Service URL field, enter the URL of the server where the application for the Personal Address Book service is located:

http://<CallManager hostname or IP address>/ccmpd/xmlAddressBookInput.asp

Step 5 Click Insert.

Step 6 Click the New button to the right of the Parameters list box.

The Configure Cisco IP Phone Service Parameter window appears.

Step 7 Add each parameter as described in Table 4, beginning with UserID. When specified, enter the parameter name exactly as it appears in the table.

Step 8 Click Insert to add the parameter.

Step 9 When you have added the last service parameter, click Insert and Close to insert that parameter and close the window.

The Cisco IP Phone Services Configuration window displays.

Step 10 Click Update Subscriptions.


Personal Address Book Service Parameter Settings

Table 4 shows the service parameter settings for the three service parameters required for the Personal Address Book service. Where indicated, use the exact parameter name.

Table 4 Personal Address Book Service Parameter Settings 

Field
Definition
Definition
Definition

Parameter Name

UserID

(Use this exact name.)

UserPIN

(Use this exact name.)

PreDial

Parameter Display Name

User Identification

PIN

Outside Access code

Default Value

None

None

None

Parameter Required

Yes

Yes

No

Parameter Description

This is the same user identification that is used with the Cisco IP Phone User Options window.

This is the same user PIN that is used with the Cisco IP Phone User Options window.

This access code is added as a prefix to the stored directory number to provide access to an outside line.

Parameter is a Password (mask contents)

None

None

None



Note To mask a parameter entry such as a password, check the Parameter is a Password (mask contents) check box.The default for this parameter specifies None. The parameter is provisioned at runtime.


Configuring the Personal Fast Dials Service

You configure Personal Fast Dials by adding the service to Cisco CallManager Administration and configuring the appropriate service parameters.

Follow this procedure to configure the Personal Fast Dials service:

Procedure


Step 1 Choose Feature > Cisco IP Phone Services.

The Cisco IP Phone Services Configuration window displays.

Step 2 In the Service Name field, enter the name of the service you want to display in the menu of available services on the Cisco IP Phone User Options window, for example, My Fast Dials.

Step 3 In the Service Description field, enter a description of the content provided by the service, for example, Personal Directory - Personal Fast Dials.

Step 4 In the Service URL field, enter the URL of the server where the application for the Personal Address Book service is located:

http://<CallManager hostname or IP address>/ccmpd/xmlFastDials.asp

Step 5 Click Insert.

Step 6 Click the New button to the right of the Parameters list box.

The Configure Cisco IP Phone Service Parameter window appears.

Step 7 Add each parameter as described in Table 5, beginning with UserID. When specified, enter the parameter name exactly as it appears in the table.

Step 8 Click Insert to add the parameter.

Step 9 When you have added the last service parameter, click Insert and Close to insert that parameter and close the window.

The Cisco IP Phone Services Configuration window displays.

Step 10 Click Update Subscriptions.


Personal Fast Dials Service Parameter Settings

Table 5 shows the service parameter settings for the three service parameters required for Personal Fast Dials service. Where indicated, use the exact parameter name.

Table 5 Personal Fast Dials Service Parameter Settings 

Field
Definition
Definition
Definition

Parameter Name

UserID

(Use this exact name.)

UserPIN

(Use this exact name.)

PreDial

Parameter Display Name

User Identification

PIN

Outside Access code

Default Value

None

None

None

Parameter Required

Yes

Yes

No

Parameter Description

This is the same user identification that is used with the Cisco IP Phone User Options window.

This is the same user PIN that is used with the Cisco IP Phone User Options window.

This access code is added as a prefix to the stored directory number to provide access to an outside line.

Parameter is a Password (mask contents)

None

None

None


Downloading the Cisco IP Phone Address Book Synchronizer

Users must install the Cisco IP Phone Address Book Synchronizer plugin on their computers before they can use the Personal Directory.

Use the following procedure to download the Cisco IP Phone Address Book Synchronizer installation file. Once you download the file, you can distribute it to the users in your network.

Procedure


Step 1 Choose Applications > Install Plugins.

Step 2 Choose Cisco IP Phone Address Book Synchronizer.

Follow the online instructions.

Step 3 Make the installation file available to the end users to install the Cisco IP Phone Address Book Synchronizer application on their own work station.

a. Include tabsync in the file downloads.asp to make the application available to the users.

b. Provide users with the following URL to download the application: http://<ccm>/ccmuser/downloads.asp


Preparing the Phone User for Personal Directory

Once you have added the Personal Directory services and configured the service parameters, provide the phone user with the following information:

Notification of the feature's availability

Access to the installation file for the Cisco IP Phone Address Book Synchronizer for users to install on their own work stations

Their user ID and PIN, if they do not already have it

The URL for the Cisco IP Phone User Options web page for the user, if they do not already have it

Information on using the Personal Directory services. Direct them to the Customizing Your Cisco IP Phone on the Web.

Support for the Cisco VG224 Gateway

The Cisco CallManager System Guide erroneously omitted information about the Cisco VG224 gateway, which is new in Cisco CallManager release 4.1, from the "Understanding Cisco CallManager Voice Gateways" chapter. The Cisco VG224 gateway uses both MGCP and SCCP gateway control protocols.

Configuration of the Cisco VG224 gateway is detailed in the "Gateway Configuration" chapter of the Cisco CallManager Administration Guide in the "Adding a Cisco IOS SCCP Gateway." The Cisco VG224 gateway should also be added to the list of gateways in the "Adding a Cisco IOS MGCP Gateway."

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 at this URL:

http://www.cisco.com/univercd/home/home.htm

You can access the Cisco website at this URL:

http://www.cisco.com

You can access international Cisco websites at 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 send 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-9883

We appreciate your comments.

Obtaining Technical Assistance

For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on Cisco.com features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service contract, contact your reseller.

Cisco Technical Support Website

The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year at this URL:

http://www.cisco.com/techsupport

Access to all tools on the Cisco Technical Support Website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:

http://tools.cisco.com/RPF/register/register.do

Submitting a Service Request

Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool automatically provides recommended solutions. If your issue is not resolved using the recommended resources, your service request will be assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL:

http://www.cisco.com/techsupport/servicerequest

For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.

To open a service request 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 2447

For a complete list of Cisco TAC contacts, go to this URL:

http://www.cisco.com/techsupport/contacts

Definitions of Service Request Severity

To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.

Severity 1 (S1)—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.

Severity 2 (S2)—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.

Severity 3 (S3)—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.

Severity 4 (S4)—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. Visit Cisco Marketplace, the company store, at this URL:

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 at this URL:

http://www.ciscopress.com

Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL:

http://www.cisco.com/packet

iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. 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:

http://www.cisco.com/ipj

World-class networking training is available from Cisco. You can view current offerings at this URL:

http://www.cisco.com/en/US/learning/index.html