|
Table Of Contents
Release Notes for Cisco CallManager Release 4.1(2)
Determining the Software Version
Compatibility Matrix and Supported Upgrades
Cisco CallManager Installation, Upgrade, and Backup Enhancements
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
Cisco CallManager Administration Menu Changes
External Call Transfer Restrictions (Trunk-to-Trunk) Enhancements
Drop Ad Hoc Conference Enhancements
H.323 fastStart and T.38 Enhancements
MGCP BRI Endpoint Configuration
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
Cisco Unity Voice-Mail Port Adjustments and Unity User Integration
Multilevel Administration Access Enhancements
Compatibility with Older Versions of QSIG Protocol (ECMA)
Facility Selection and Reservation
Bulk Administration Tool Enhancements
External Call Transfer Restrictions (Trunk-to-Trunk Transfer)
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
New and Changed Information for Third-Party and SDK Applications
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)
Open Caveats for Cisco CallManager - Release 4.1(2)
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
Associating H.323 Devices to Users
? 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
Support for the Cisco VG224 Gateway
Obtaining Technical Assistance
Cisco Technical Support Website
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:
•Compatibility Matrix and Supported Upgrades
•New and Changed Information for Cisco CallManager Serviceability
•New and Changed Information for Third-Party and SDK Applications
•Resolved Caveats for Cisco CallManager - Release 4.1(2)
•Open Caveats for Cisco CallManager - Release 4.1(2)
•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
•External Call Transfer Restrictions (Trunk-to-Trunk) Enhancements
•Drop Ad Hoc Conference Enhancements
•H.323 fastStart and T.38 Enhancements
•MGCP BRI Endpoint Configuration
•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
•Cisco Unity Voice-Mail Port Adjustments and Unity User Integration
•Multilevel Administration Access Enhancements
•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:
•Compatibility with Older Versions of QSIG Protocol (ECMA)
•Facility Selection and Reservation
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:
•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:
•External Call Transfer Restrictions (Trunk-to-Trunk Transfer)
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:
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
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 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.
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
This section includes errors that the Cisco CallManager Documentation suite contains.
•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 Usageecho Install stored procedure in database %2echo USE %2 > temp.sqlecho GO >> temp.sqlecho DROP PROCEDURE dblRemoveServerFromDB >> temp.sqlecho GO >> temp.sqlecho CREATE PROCEDURE [dblRemoveServerFromDB] >> temp.sqlecho (@servername NVARCHAR(50),@ispublisher NVARCHAR(50)) AS >> temp.sqlecho BEGIN TRANSACTION >> temp.sqlecho DECLARE @nodeid NVARCHAR(50), @deviceid NVARCHAR(50), @pnsid NVARCHAR(50) >> temp.sqlecho -- >> temp.sqlecho PRINT 'Get the Node ID' >> temp.sqlecho SELECT @nodeid=pkid from ProcessNode where name=@servername >> temp.sqlecho -- >> temp.sqlecho PRINT 'Delete associated Device and MediaMixer' >> temp.sqlecho WHILE (SELECT COUNT(*) FROM Device WHERE fkProcessNode=@nodeid) ^> 0 >> temp.sqlecho BEGIN >> temp.sqlecho SELECT @deviceid=pkid from Device where fkProcessNode=@nodeid >> temp.sqlecho PRINT 'Delete MediaMixer' >> temp.sqlecho DELETE FROM MediaMixer WHERE fkDevice=@deviceid >> temp.sqlecho PRINT 'Delete MOHServer' >> temp.sqlecho DELETE FROM MOHServer WHERE fkDevice=@deviceid >> temp.sqlecho PRINT 'Delete Device' >> temp.sqlecho DELETE FROM Device WHERE pkid=@deviceid >> temp.sqlecho END >> temp.sqlecho -- >> temp.sqlecho PRINT 'Delete associated CallManager records' >> temp.sqlecho DELETE FROM CallManagerGroupMember FROM CallManagerGroupMember AS M >> temp.sqlecho JOIN CallManager AS C ON C.pkid=M.fkCallManager WHERE C.fkProcessNode=@nodeid >> temp.sqlecho DELETE FROM CallManager WHERE fkProcessNode=@nodeid >> temp.sqlecho -- >> temp.sqlecho PRINT 'Delete associated ProcessConfig records' >> temp.sqlecho DELETE FROM ProcessConfig WHERE fkProcessNode=@nodeid >> temp.sqlecho -- >> temp.sqlecho PRINT 'Delete associated AlarmConfig records' >> temp.sqlecho DELETE FROM AlarmConfig FROM AlarmConfig AS A JOIN ProcessNodeService >> temp.sqlecho AS S ON A.fkProcessNodeService=S.pkid WHERE S.fkProcessNode=@nodeid >> temp.sqlecho PRINT 'Delete associated ProcessNodeService records' >> temp.sqlecho DELETE FROM ProcessNodeService WHERE fkProcessNode=@nodeid >> temp.sqlecho -- >> temp.sqlecho PRINT 'Delete associated ComponentVersion records' >> temp.sqlecho DELETE FROM ComponentVersion WHERE fkProcessNode=@nodeid >> temp.sqlecho -- >> temp.sqlecho PRINT 'Delete the node' >> temp.sqlecho DELETE FROM ProcessNode WHERE pkid=@nodeid >> temp.sqlecho -- >> temp.sqlecho COMMIT TRANSACTION >> temp.sqlecho GO >> temp.sqlecho -- Execute procedure on server %1echo exec dblRemoveServerFromDB '%3' >> temp.sqlosql -S %1 -d %2 -E -e -i temp.sqldel temp.sqlecho USE %2 > temp1.sqlecho sp_dropsubscription @publication = %2, @subscriber = '%3', @article='all' >> temp1.sqlecho GO >> temp1.sqlosql -S %1 -d %2 -E -e -i temp1.sqldel temp1.sqlgoto endd:Usage@echo Usage: RemoveServerFromDB "server" "database" "name_of_server_to_delete_from_ProcessNode.Name"@echo Example: RemoveServerFromDB . CCM0300 fred.cisco.com:enddContents 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 Usageecho Install stored procedure in database %2echo sp_removedbreplication @dbname = %2 > temp1.sqlecho GO >> temp1.sqlosql -S %1 -d %2 -E -e -i temp1.sqldel temp1.sqlgoto endd:Usage@echo Usage: RemoveSubscription "server" "database"@echo Example: RemoveSubscription . CCM0300:enddChanges
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
•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:
•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.
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.
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:
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-9883We 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 2447For 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:
•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:
•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:
•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
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
CCSP, the Cisco Square Bridge logo, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0406R)
Copyright © 2004 Cisco Systems, Inc. All rights reserved.