Table Of Contents
Release Notes for Cisco CallManager Release 3.0
Contents
Introduction
System Requirements
New and Changed Information
New Hardware and Software Features in Release 3.0
Distributed Call Processing
Digit Analysis Replication
Multiple Line Appearance
Route Lists and Route Groups
Address Assignments (Route Pattern)
Number Transformations
Data Driven Dial Plan
Dial Plan Report
Pickup
Group Pickup
Select Ringing State for a Phone Device
Disable Ring Per Line
Database Layer/Replication
Device Reset Control
Device Recovery
Intra-Cluster Distributed Cisco CallManager Feature Transparency
Inter-Cluster Distributed Cisco CallManager Feature Transparency
Distributed Cisco CallManager Scalability
Cisco CallManager Redundancy on the Cisco ICS 7750
Digit Analysis Multi-Tenant
Digit Analysis Multi-Location
Digit Analysis Toll Restriction
MGCP Support for VG200
MGCP Device Recovery
Cisco IP Phone 7960 Support
Comfort Noise
IP Voice Streaming Application
Services Management
Global Directory User Pages
Empty Terminal Capability Set
MTP Selection Algorithm
CDR Modifications
Hold Feature Modifications
E-911 Support
VG200 Hook Flash Transfer
AMIS-A Support
Bulk Administration Tool (BAT)
DtSilenceFlag Service Parameter
Modems and Faxes
End User Interface
Important Notes
Caveats
Open Caveats for Cisco CallManager Release 3.0
Troubleshooting
Documentation Updates
New Service Parameters
Configuring the Microsoft Telnet Daemon for Bridged Telnet
Server Name Change
Running Show Tech
Changes
Default Value Changed for SdlTraceTotalNumFiles Service Parameter
Omissions
Cisco CallManager Service Parameters
Cisco TFTP Service Parameters
Cisco Messaging Interface Service Parameters
Cisco IP Voice Media Streaming Service Parameters
Cisco Enterprise Service Parameters
Errors
Incorrect Name of MwiSearchSpace Service Parameter
Service and Support
Obtaining Documentation
World Wide Web
Documentation CD-ROM
Ordering Documentation
Obtaining Technical Assistance
Cisco Connection Online
Technical Assistance Center
Documentation Feedback
Release Notes for Cisco CallManager Release 3.0
June 15, 2000
These release notes describe the new features and caveats for Cisco CallManager Release 3.0. Use these release notes in conjunction with the Installing Cisco CallManager Release 3.0 on the Cisco Media Convergence Server document, located on Cisco Connection Online (CCO), and the Cisco Documentation CD-ROM. The Installing Cisco CallManager Release 3.0 on the Cisco Media Convergence Server document is also packaged with your CDs or convergence server.
Contents
These release notes discuss the following topics:
•
Introduction
•System Requirements
•New and Changed Information
•Important Notes
•Caveats
•Troubleshooting
•Documentation Updates
•Service and Support
•Obtaining Documentation
•Obtaining Technical Assistance
Introduction
Cisco CallManager is a network business communication system providing high-quality telephony over IP networks. Cisco CallManager enables the conversion of conventional, proprietary circuit-switched PBXs to multi-service, open LAN systems.
System Requirements
Cisco CallManager Release 3.0 must be installed and configured on a Cisco Media Convergence Server. For system hardware component information and system requirements, refer to Installing Cisco CallManager Release 3.0 on the Cisco Media Convergence Server.
New and Changed Information
This section lists the features that are new or have changed for Cisco CallManager Release 3.0.
New Hardware and Software Features in Release 3.0
The following sections contain new and changed hardware and software features in Release 3.0 of Cisco CallManager.
Distributed Call Processing
Cisco CallManager (Release 3.0 and later) provides the capability for distributed call processing. With this feature, you can distribute the call processing load of your system across multiple Cisco CallManagers in a cluster. This feature allows for redundancy, feature transparency, and scalability in a distributed environment.
To support this functionality, a new distributed, replicated database layer has been added to the Cisco CallManager system. This layer allows for the transparent replication of configuration information across the coordinating Cisco CallManagers. The layer manages database consistency and recover ability. Configuration is simplified through a single web interface to the database for the entire system.
Digit Analysis Replication
Digit analysis facilitates the replication of route pattern to device process ID mapping across all Cisco CallManagers in a network.
Multiple Line Appearance
Cisco CallManager supports distributed multiple line appearance which allows multiple phones attached to multiple Cisco CallManagers to share one directory number (DN).
Route Lists and Route Groups
Release 3.0 introduces multiple Cisco CallManager nodes in a system. Access Devices may be registered in any of the nodes of the system, but must still be reachable using the configured RoutePlan. RouteLists (RL) and RouteGroups (RG) are configured in the same manner as in Cisco CallManager Release 2.4, with the same associations.
Address Assignments (Route Pattern)
This feature allows addresses of devices and virtual endpoints to be specified using a format that allows easy assignment of a range of matching values. This allows addresses to be easily blocked.
Number Transformations
This feature allows both called and calling numbers to be modified by truncation, replacement of individual digits, discarding named sub-strings (called number only) or pre-pending to arbitrary digits.
Data Driven Dial Plan
The Dial Plan Wizard enables you to create a dial plan quickly and easily. You can log into the Cisco CallManager Administration page using Internet Explorer or Netscape Browser.
Dial Plan Report
Dial Plan Report allows you to see the dial plan configuration at a glance. For each route partition, it lists the call park numbers, call pickup numbers, and conference numbers associated with the partition. For each route pattern, it shows the usage, route list, route group, device, and port numbers associated with the route pattern.
Pickup
Once Call Pickup groups have been established, this feature allows you to answer any call that is ringing for a directory number (DN) that is part of the Call Pickup Group associated with the DN from which the pickup attempt was originated.
Group Pickup
Group Pickup allows you to pick up a call that is ringing in any Call Pickup Group.
Select Ringing State for a Phone Device
This feature allows ringing to be either enabled or disabled from the database. If ringing is enabled, an incoming call is presented on the phone by using the display and/or lights as appropriate for that particular device, and ringing the phone. If ringing is disabled, an incoming call is presented on the phone by using the display and/or lights as appropriate for that particular device, but the phone does not ring audibly.
Disable Ring Per Line
If a DN appears on multiple phones, the database can be set to control which phone will ring or which will just flash, indicating that the phone is ringing, on a phone-by-phone basis.
Database Layer/Replication
The database layer provides a common API for accessing and updating the main data store for Cisco CallManager and supporting applications. This API performs tasks that all applications that update the database should perform.
Device Reset Control
This release of Cisco CallManager significantly reduces the number of database changes that require a Cisco CallManager restart in order to take effect.
Device Recovery
This section applies to Cisco CallManager through Media Gateway Control Protocol (MGCP), as well as Cisco CallManager to Cisco CallManager connections. Each Cisco CallManager device uses the steps in the following list to connect or reconnect to Cisco CallManagers:
•A configuration component provides a list of Cisco CallManagers for the device to use. The maximum number of Cisco CallManagers on the redundancy list is three.
•A TCP connection to two Cisco CallManagers in the list is maintained. Keep-alive messages are sent to both the active and the standby Cisco CallManager.
•If the active Cisco CallManager fails, an IP phone to IP phone call stays active if both phones are on the same Cisco CallManager. If the two IP phones are on different Cisco CallManagers, the call is dropped. IP phone to a gateway calls are also dropped regardless of which Cisco CallManagers the devices are registered. As soon as the IP phone to IP phone call ends, the phones register with their standby Cisco CallManager. This backup is only temporary, until the primary Cisco CallManager is restored.
•When keep-alive messages fail to the active Cisco CallManager, the device attempts to register with the standby Cisco CallManager. The device attempts to keep two TCP connections open and always tries to re-connect to the highest priority, available Cisco CallManager.
•If a registered device is not registered with the primary, available Cisco CallManager, and no calls are active, the device follows the list starting with the first Cisco CallManager on the list and attempts to re-make a TCP connection. Upon a successful connection, the device de-registers with the current active Cisco CallManager and registers with the new Cisco CallManager.
Intra-Cluster Distributed Cisco CallManager Feature Transparency
Feature transparency and a supplementary service across any number of Cisco CallManagers boils down to display management, lamp management, and media management across multiple Cisco CallManagers.
In Distributed SDL, feature transparency is provided by changing the call control interface so that it can extend feature-related intercepts to remote Cisco CallManagers as well as a locally-controlled device. Lamp and tone stimuli are propagated across Cisco CallManagers. The media layer supports media stream interruption without requiring a Media Termination Point (MTP).
Note MTP is not required for Inter-Cluster communication.
Inter-Cluster Distributed Cisco CallManager Feature Transparency
Clusters of Cisco CallManagers interconnect using H.323 protocol. A given cluster views another cluster as another H.323 device. When configuring one cluster to talk to another, the Configuration Database has an H.225 device configured that points to one of the Cisco CallManagers in the remote cluster. The Dial Plan structure associates the remote cluster's E.164 address range to the H.225 device and signals the remote cluster just as it would an H.323 gateway.
Distributed Cisco CallManager Scalability
Six Cisco CallManagers can reside in a Cisco CallManager cluster. The maximum number of users in a Cisco CallManager cluster is 10,000. A single Cisco CallManager can handle 2,500 phones. When multiple Cisco CallManagers are present in a cluster, the number of IP phones assigned to each Cisco CallManager in a normal state must be such that they can absorb the IP phones from a failed Cisco CallManager so that 2,500 phones on any Cisco CallManager is not exceeded.
Note For redundancy purposes, you could have a Cisco CallManager that only serves as a backup Cisco CallManager, and during normal operations, would have no registered phones. You can also install the Publisher database and TFTP servers on stand-alone platforms if desired.
Cisco CallManager Redundancy on the Cisco ICS 7750
Cisco CallManager redundancy is handled differently on the Cisco ICS 7750 than it is in a clustered environment. Only one instance of Cisco CallManager is active at any time on the Cisco ICS 7750. When a redundant System Processing Engine (SPE) runs a secondary instance of Cisco CallManager, the secondary instance is never active unless the primary Cisco CallManager fails. If a failover occurs, the secondary Cisco CallManager becomes active and takes over all call processing and Cisco CallManager database functions. Since only one instance of Cisco CallManager is active on the Cisco ICS 7750, load-balancing is not available, and each Cisco ICS 7750 must be administered separately. For more information about implementing and configuring Cisco CallManager on the Cisco ICS 7750, please refer to the Cisco ICS 7750 documentation.
Note Cisco CallManager clusters are not supported on the Cisco ICS 7750.
Digit Analysis Multi-Tenant
The Cisco CallManager is able to support multiple instances of the same DN, which are treated as independently reachable DNs.
Digit Analysis Multi-Location
The Cisco CallManager is able to support routing for devices that are in different geographical regions, of which belong to different area codes within the North American Numbering Plan (NANP). You can configure your dial plan in order to bypass the public network when feasible, and also to fall back to long distance routes when WAN or intranet is unavailable.
Digit Analysis Toll Restriction
Cisco CallManager is able to allow or prohibit types of calls based on the class of the calling user.
MGCP Support for VG200
Cisco CallManager is more tightly integrated with the VG200 series of gateways. Media Gateway Control Protocol (MGCP) is used to provide inter-working between Cisco CallManager and gateways. The Cisco CallManager is able to control analog interfaces (FXS and FXO).
MGCP Listen Port
MGCP messages are transmitted over UDP. The MGCP listen port represents the Cisco CallManager UDP listen port. The default for this port should be set to 2427.
MGCP Keep-alive Port
The VG200 gateways use TCP as a keep-alive mechanism with Cisco CallManagers. Each gateway can be configured with one active Cisco CallManager and up to two backup Cisco CallManagers. One TCP keep-alive connection exists between a gateway and an active or backup Cisco CallManager. The MGCP keep-alive port represents the Cisco CallManager TCP server port used for this keep-alive mechanism. The default for this port should be set to 2428.
MGCP Device Recovery
Cisco CallManager health monitoring is the responsibility of the gateway. Inter Cisco CallManager and gateway keep-alives track the health condition of the controlling Cisco CallManager. Once the gateway has detected an outage of the primary Cisco CallManager, it rehomes to the next highest priority Cisco CallManager.
Cisco IP Phone 7960 Support
The Cisco IP Phone 7960 uses the Skinny Station protocol with additional messages as required to support the new functionality of the Cisco IP Phone 7960. The Cisco CallManager controls the display on the Cisco IP Phone 7960 indirectly, by providing call and state information to the phone. The phone display processing itself is stateless. The Cisco IP Phone 7960 supports the G.711 u-law and a-law and the G.729, G.729B Codecs.
Comfort Noise
The Cisco IP Phone 7960 supports comfort noise when using G.711 protocol. When Voice Activity Detection (VAD) is enabled, the Cisco IP Phone 7960 generates a low level white noise hiss to simulate the background circuit noise users experience on non-IP connections. Generated comfort noise is only heard on the handset of the station generating the noise; it is not transmitted to the station at the other end of the call. If VAD is disabled, the Cisco IP Phone 7960 provides a continuously streaming, end-to-end connection. VAD is enabled by default.
Caution If VAD is disabled on a network that exhibits a significant amount of jitter (greater than 100 milliseconds per second), latency becomes noticeable to the user in the forms of delay and packet loss. Also, if the Codec clocks are out of sync among the devices participating in the call, latency increases for the duration of the call. For example, if the Codec clock at the transmitting end is 100 parts per million faster than the Codec clock at the receiving end, latency increases to one-half second over the course of a one hour long connection (at 8kHz).
The comfort noise level is determined either by information contained in Silence Information Description (SID) frames or by calculations performed on previous information packets. If a call is made from one Cisco IP Phone 7960 to another Cisco IP Phone 7960, the transmitting device sends SID frames that enable the comfort noise generator on the receiving device to generate the proper level of comfort noise. If a call is made between a Cisco IP Phone 7960 and a device that does not send SID frames, the Cisco IP Phone 7960 calculates and generates the proper comfort noise level based on the background noise of previous information packets.
IP Voice Streaming Application
The IP Voice Streaming Application (Media Application) combines the Conference Bridge and the Media Termination Point (MTP) components that were in the previous versions of the Cisco CallManager. The Media Application consists of two parts: an NT service and NT kernal mode driver. The NT service is responsible for registering with the Cisco CallManager and handling Device Recovery. The kernal driver processes and controls the voice data packets.
Services Management
The list of software processing elements for the Cisco IP Telephony Solutions for the Enterprise is Cisco CallManager, TFTP Server, Cisco Messaging Interface (CMI), and IP Streaming Application (replaces the previously separate applications for Conference Bridge and MTP). Each of the processing elements are managed consistently using well-known Microsoft NT system administration tools.
Service Parameters
This provides information required by a service that, in a previous Cisco CallManager release, might have been presented in an application configuration dialog, the registry, or in an ini-file. These parameters can now be obtained from the database.
Enterprise Parameters
This provides parameters required by multiple services within the enterprise.
Global Directory User Pages
In Release 3.0, an LDAP Directory (instead of the relational database) is used to store user data (for example, information like name and DN). The information in this directory is accessed by a variety of applications. This release provides password protected user access to speed dial.
Empty Terminal Capability Set
This feature allows the start and stop (re-direct) of streaming on an H.323 device without the use of MTP. This allows the use of supplementary services without losing the call or voice stream.
Empty Capabilities set is a technique used in H.323v2 to allow the Cisco CallManager to instruct an H.323 gateway to transfer a call to a new endpoint in mid-call. This is typically done upon no answer or if the IP phone user presses the transfer button on the set. Prior to this capability, it was necessary to send H.323 calls to an intermediate Media Termination Point (MTP) application before connecting to the IP phone.
Note The minimum IOS release required for Empty Terminal Capability set is 12.1(3)T.
MTP Selection Algorithm
Despite the implementation of the empty capability set, the Cisco CallManager will still need to use MTP when transcoding is required. This occurs when the Cisco CallManager is connecting a low bandwidth call to a device without a matching Codec.
Note Cisco CallManager Release 3.0 only supports low bandwidth to G.711. Currently, double transcoding is not supported.
CDR Modifications
Even when there are two or more Cisco CallManagers in a cluster, CDR records are written to a common database store. There may be more than one record logged per call.
Hold Feature Modifications
Table 1 contains the hold feature modifications with Release 3.0:
Table 1 Hold Feature Modifications
Scenarios
|
Initial State
(1st call ----- 2nd call)
|
Line Button Pressed
|
Final State
(1st call ----- 2nd call)
|
1
|
OnHook ----- OnHook
|
Pressed
|
Dial Tone ----- OnHook
|
2
|
Connected ----- OnHook
|
Pressed
|
Hold ----- Dial Tone
|
3
|
Hold ----- OnHook
|
Pressed
|
Connected ----- OnHook
|
4
|
Connected ----- Hold
|
Pressed
|
Hold ----- Connected
|
5
|
Hold ----- Hold
|
Pressed
|
Connected ----- Hold
|
6
|
Ring Out/Dial Tone ----- OnHook
|
Pressed
|
OnHook ----- OnHook
|
7
|
Ring Out/Dial Tone ----- Hold
|
Pressed
|
OnHook ----- Connected
|
8
|
Ring In ----- OnHook
|
Pressed
|
Connected ----- OnHook
|
9
|
Ring In ----- Hold
|
Pressed
|
Connected ----- Hold
|
10
|
Ring In ----- Connected
|
Pressed
|
Connected ----- Hold
|
11
|
Connected ----- OnHook
|
Pressed (Another Line)
|
Hold ----- OnHook
|
12
|
Ring Out ----- OnHook
|
Pressed (Another Line)
|
OnHook ----- OnHook
|
13
|
Ring In ----- OnHook
|
Pressed (Another Line)
|
Ring In ----- OnHook
|
14
|
Connected ----- Hold
|
Pressed (Another Line)
|
Hold ----- Hold
|
E-911 Support
The Cisco CallManager supports delivering the ANI (Automatic Number Identification) through an H.323 interface to the PSTN using two methods: PRI/ISDN trunks and third party CAMA (a 911 protocol) gateways. The CAMA protocol is supported using the third party, voice over IP gateway 8x8. That will send the calling line identification number to another third party device.
VG200 Hook Flash Transfer
VG200 to Cisco CallManager: The VG200 initiates a blind hook flash transfer and the Cisco CallManager transfers the call.
AMIS-A Support
AMIS-A support allows VoIP devices to exchange AMIS-A DTMF tones (A, B, C, and D) with the Cisco CallManager, in an out of band signal. The purpose of AMIS-A support is to facilitate uOne voice mail message exchange with legacy voice mail systems.
AMIS-A DTMF tones (A, B, C, and D) are transported in two different schemes. On the IP side, the tones are detected and generated in an out of band signaling format, whereas on the TDM side of the gateways, the tones are detected and generated inband along with the voice path.
The main role of Cisco CallManager is to make sure that DTMF digits received from the sending device are correctly mapped to the corresponding signal format (or API) of the terminating device.
The following existing APIs are impacted to include the AMIS-A DTMF tones (A, B, C, and D):
•Skinny Station Protocol—StationKeyPadButton and StationOutputKeyPadButton
•Skinny Gateway Protocol—GatewayToDeviceReportDigit, DeviceToGatewayPlayTone, and Q.931 and Information message (for analog access gateway).
•H323 Protocol—H245 User Input Indication (h245-signal)
•MGCP Protocol—NTFY and RQNT
Bulk Administration Tool (BAT)
The Bulk Administration Tool (BAT) is a plug-in application to the Cisco CallManager. BAT enables you to add up to 10,000 phones and users to the Cisco CallManager application. Using BAT, you can also perform bulk modifications to phones and delete several phones at one time. Launch BAT from the Cisco CallManager Administration main window by selecting Application and click on BAT. For more information, refer to the Configuring the Bulk Administration Tool (BAT) document.
DtSilenceFlag Service Parameter
The DtSilenceFlag service parameter controls whether or not silence is sent while a caller waits for the phone to be answered at the other end. By default, the DtSilenceFlag service parameter is set to False (disabled). When this parameter is set to False, the audio stream is sent on call proceeding instead of waiting for a connect from the other end. When this parameter is set to True, silence is sent until a connect is received from the phone at the other end.
There is, however, one side effect that occurs when the DtSilenceFlag parameter is set to 0 (disabled). When the DtSilenceFlag parameter is disabled and you are calling an analog phone, you may hear loopback (echo) of your audio until the phone on the other end is answered.
To eliminate this echo, you can manually add the DtSilenceFlag service parameter to the list of CallManager service parameters for each Cisco CallManager and set its value to T (enabled). The DtSilenceFlag service parameter does not automatically appear in the list of Cisco CallManager service parameters.
Caution Setting the DtSilenceFlag service parameter to T can result in one-way audio on 911 calls depending on the local carrier's configuration of the Central Office switch. The problem will only occur if the 911 switch fails to send a connect. If the 911 switch fails to send a connect, the calling phone continues to send silence, and the audio stream from the calling phone is never sent.
Therefore, it is strongly recommended that you schedule a test 911 call with your 911 service provider to verify that this problem does not occur. The test scenario should include the following steps:
1. Schedule a test call with your 911 service provider during off-peak hours.
2. Make sure that the test call will be routed over a Cisco Access Digital Trunk Gateway or a Catalyst 6000 T1/E1 8 Port Voice Service Module.
3. Enable the DtSilenceFlag parameter.
4. Make the 911 call.
5. If the 911 operator can hear you, the test passed, and you can leave the DtSilence setting enabled. If not, disable it immediately.
Perform the following steps only if you wish to enable the DtSilenceFlag service parameter:
Step 1 Open Cisco CallManager Administration.
Step 2 Select Service > Service Parameters
Step 3 Select Cisco CallManager from the list of Configured Services.
Step 4 Type DtSilenceFlag in the Param field. The service parameters are case-sensitive, so it must be typed exactly as it appears.
Step 5 Choose Boolean from the Type drop-down list.
Step 6 Choose T from the Value drop-down list to set it to True (enabled).
Step 7 Click Update.
The DtSilenceFlag service parameter is now added to the list of service parameters and its value is set to T (enabled).
Modems and Faxes
The following list contains the modems and faxes that are either supported or not in Release 3.0:
•g.723.1 fax between as/at/dt gateways = not supported
•g.711 fax between as/at/dt gateways = not supported
•g.729 fax-relay between IOS gateways = supported
•g.711 fax-relay between IOS gateways = supported
•g.729 fax-relay between cat6k gateways = supported
•g.711 fax passthrough between cat6k gateways = supported
•g.711 modem passthrough between cat6k gateways = supported
End User Interface
The end user interface for Cisco CallManager Release 3.0 database administration has changed. The new interface provides a system page divided into more precise categories, more links from one page to another, and faster search engines for devices (phones, gateways, etc.).
The main menu of the Cisco CallManager Administration user interface consists of the following:
•System
•Route Plan
•Service
•Feature
•Device
•User
•Application
•Help
Some configuration screens contain data that are associated with a particular Cisco CallManager. A drop-down menu with all Cisco CallManager names is displayed. To see the data associated with a particular Cisco CallManager, choose the Cisco CallManager from the drop-down list. Data is displayed accordingly.
The following sections contain the grouping of the different menu categories for the Cisco CallManager Database Administration.
System
The System category includes any system-related configurations that set the system's behaviors and options. It includes the following configurations:
•Server—Any machine that runs the Cisco CallManager and its application needs to be added in the Server Configuration page. The installation program automatically adds an entry on this page for the machine on which the Cisco CallManager is installed. A unique DNS host name or IP address is needed for each server.
•Cisco CallManager—Allows you to define Cisco CallManagers in the system. Each server defined in the system (under Server Configuration) can have only one Cisco CallManager running on it. Therefore, you must define the server on which the Cisco CallManager resides before defining the Cisco CallManager. In every system, there must be one primary Cisco CallManager. You can also configure the auto-registration and port settings for the Cisco CallManager.
•Cisco CallManager Group—This configuration page allows you to define groups of Cisco CallManagers. Only one Cisco CallManager Group in the system can be the default Cisco CallManager used by Trivial File Transfer Protocol (TFTP). A Cisco CallManager Group can have up to three Cisco CallManagers in a group.
•Date Time Group—The Date Time Group configuration page allows you to add, update and delete date time groups. Each group contains time zone, and date and time format preferences. There should be at least one date time group in the system.
•Device Defaults—For each Cisco CallManager, this is a load ID, keypad template, and device pool associated with each model type. When a device is created in the system, the system can automatically identify the appropriate load ID (if applicable), keypad template (if applicable), and device pool for the device based on the Cisco CallManager of which it is registered. This configuration page can be viewed based on each Cisco CallManager. This configuration page is impacted by N + 1.
•Region—The Regions feature in Data Administration can be used to limit the bandwidth usage between devices that are assigned to different (or the same) regions. The configuration pages allow you to define a region and set the bandwidth usage within the region and between the new region and all existing regions.
•Device Pool—All devices in the Cisco CallManager system associate with a device pool. A device pool contains the region, date time group, Cisco CallManager Group, and calling search space for auto-registration. You can create different device pools for devices in different regions, time zones for each Cisco CallManager Group, and calling search space combinations.
•Enterprise Parameters—This configuration page allows you to set parameter values for firmware load of all device types, LDAP settings, and Cisco IP Phone 7960-related settings in the system.
•Location—This configuration page allows you to define logical locations in the system and define bandwidth settings for the location.
Route Plan
This category allows you to configure Route Plans, partitions, and so on. It includes the following menu items:
•Partition—Partition has a collection of DNs. You can create route partitions and view a list of DNs associated with this partition.
•Calling Search Space—Calling Search Space contains a list of partitions. In each partition, there is a list of DNs that a device can call. When a device is assigned to a calling search space, this device can call any number which is contained in that calling search space's partition list. The ordering of partitions in a calling search space can be modified. This configuration page is impacted by N + 1.
•Route Filter—A route filter allows you to restrict what dial patterns are routed or blocked. The tags associated with the route filters can only be used by North American Numbering Plan (NANP) patterns. Modification to the database is needed if other numbering plans need to be supported.
•Route Group—A route group allows you to order a list of gateways and ports for outgoing trunk preference. Devices that can belong to a route group are: Analog Access ports, Digital Access PRI, Digital Access T1, and H.323 (network side) devices. All devices in a route group must have the same route pattern.
•Route List—A route list allows you to specify the order in which route groups are used.
•Route Pattern—You define the route patterns for the Cisco CallManager system. The Cisco CallManager uses the route patterns to route internal and outgoing calls.
•Translation Pattern—You define the translation patterns for the Cisco CallManager system.
•External Route Plan Wizard—The route plan wizard guides you through a number of configuration pages to configure the route plan. It creates route plans for NANP patterns only.
•Route Plan Report—Lists all the call park, call pickup, conference, route pattern, and translation patterns defined in the system. You select the pattern or DN and the corresponding configuration page is shown. Since this page can potentially show a long list of records, we recommend viewing only 50 records at a time. You can choose to view all items by clicking on the All button.
Service
The Service category includes any applications that are add-on components, such as the following:
•Cisco Messaging Interface—Allows you to configure trace and command line parameter settings for any server, and is most commonly used to interface via SMDI to a third-party voice mail system.
•Cisco TFTP—This configuration page allows you to configure Trivial File Transfer Protocol (TFTP) service parameters. The TFTP service must be installed on a server defined in the Server Configuration page.
•Conference Bridge—Allows you to define software and hardware conference bridge solutions, as well as Meet-Me numbers/patterns in the system. The initial page shows the Conference Bridge Configuration page. To navigate to other conference bridge-related configuration pages, select the links in the upper right corner. To set up conference bridge, you must define either a conference bridge software or hardware type. The hardware type supports more capabilities than the software type.
–Conference Bridge Parameters—Allows you to set the maximum number of users in one ad hoc conference, and the maximum number of users in one Meet-Me conference using Unicast for each Cisco CallManager. You must select the device pool, and the Cisco CallManager belonging to the selected device pool is shown on the item list.
–Meet-Me Number/Pattern—Allows you to configure the Meet-Me numbers and ranges for conference bridge calls.
Note You cannot have both hardware and software conference bridge or MTP devices on the same Cisco CallManager. If both exist, the Cisco CallManager will disable the software version.
•Media Termination Point—Allows you to configure the Media Termination Point (MTP) settings.
•Service Parameters—The configuration page allows you to configure settings for the services installed in the system. By selecting a server in the item list, the configuration page shows all the services that are installed on the selected server. You can select a service of the selected server and configure the service parameter settings. A server must be defined in the Server Configuration page and the services must be installed from the Install Plugins page.
•Trace—Allows you to configure trace settings for the services installed in the system. You can display all configured services that are installed on the selected server by selecting a server in the item list. You can select a service from the Configured Services drop-down list box and configure the trace settings for the selected service. A server must be defined in the Server Configuration page and the services must be installed from the Install Plugins page.
•Transcoder—Allows you to configure transcoder devices.
•Control Center—Allows you to stop and start any services on a selected server.
Feature
The Feature category contains configurations to add phone features and feature-related parameters to the system. It includes the following configurations:
•Call Park—This configuration page allows you to specify call park number or range in the system. Each partition has its own call park number/range.
•Call Pickup—This configuration page allows you to specify call pickup number or range in the system. Each partition has its own call pickup number or range.
Device
The Device category contains configuration pages to configure devices (phones, gateways, and so on.) for the Cisco CallManager. It includes the following configurations:
•Add a New Device—This page replaces the Device Wizard in release 2.4. You can create Gateway, MGCP Gateway, Phone, and Cisco uOne Port from this configuration page. Based on the device type selected, the corresponding configuration page is displayed. Complete the information and click the Insert button to add the device.
•Gateway—The release 2.4 Gateway configuration pages included limited devices only. In Release 3.0, the Gateway section of the user interface includes all gateways, including H.323 devices. Specific pages are used to configure different types of gateways. The overall structure of the Gateways user interface is similar to the new Phone interface.
–Selecting Gateways—The method of selecting gateways (listing all gateways in a separate menu frame) from Release 2.4, has been replaced with a basic lookup function. The lookup allows you to search for gateways by the following categories: device name, description, DN, calling search space, or device pool. For each category, you can specify whether the content of the selected category begins with specific letters, contains specific letters, ends with specific letters, matches specific letters, contains no empty strings, or contains empty strings. The results are shown in a list of devices from which you can select.
–Configuring Gateways—You can select a device from the list of devices that the lookup gives you, and click a link or button to show a detailed view of the device in a secondary window. Any information that can be modified is displayed with a form element so that it can be updated immediately. The only exceptions are the port, span, and trunk configuration details, which are not all shown at once. Instead, a summary of the ports is shown with links to edit the port details (for example, for an Analog Access device, a list of ports that have been configured and each port's type, Loop Start, POTS, and so on.). The actual look and feel of the Gateway configuration pages are similar to what is shown for Phones and Users.
–Adding Gateways—A New Gateway device option is included in the menu for Gateways. Clicking the link takes you to the Add a New Gateway page, where you can add a new gateway.
–Deleting Gateways—The interface provides a toolbar button in the configuration page that invokes a script AppleTalk Session Protocol (ASP) to delete the current device. A confirmation prompt asks if you are sure, and runs the delete script if you respond with yes. If you respond with no, you are returned to the configuration page with no changes made. When deleting a gateway device, the ASP script uses the Database Layer.
•MGCP—Due to the complexity of the MGCP gateways, the MGCP configuration is separated from the other gateway configurations.
•Phone—In Release 3.0, the phone list is limited to devices that can be classed appropriately as phones; that is, end user terminal devices. This includes the existing Cisco Phones and the new Cisco IP Phone 7960. Also included in this category is the H.323 Client (for example, NetMeeting), which is used as a phone.
•Phone Template—Allows you to select a phone button template based on an existing phone template, or to create a new button layout.
User
The User category contains configuration pages that allow you to display and maintain information about users on the network. This category includes the following configurations:
•Add a New User—Allows you to complete information for specific users and associate devices with those users.
•Global Directory—Allows you to use a basic or advanced search to locate users. The Global Directory contains every user within a Cisco CallManager directory. The Cisco CallManager directory is a Lightweight Directory Access Protocol (LDAP) directory that imports device and extension information from the database. Its primary purpose is to maintain the associations of devices with users.
Application
All plug-in applications are listed under the Application menu. Once the application is installed, the application name is shown under the application menu. You can jump from one application to another simply by selecting the application under the Application menu.
Help
The Help menu includes the following categories: Contents and Index, For this Page, and About Cisco CallManager.
•Contents and Index—This window shows an online documentation page. The documentation displayed here is not context-sensitive. It displays the top-level topics of the Cisco CallManager Administration Guide.
•For this Page (context-sensitive help)—Context sensitive online documentation is provided for all the Cisco CallManager Administration Guide pages. When you click on this menu item, the documentation related to the selected configuration page is shown in a separate window.
•About Cisco CallManager—This menu displays general information about Cisco CallManager. When the Details button is clicked, a list box shows the Cisco CallManager System version number (which is the Installation version), Cisco CallManager Administration version number, database information, and database dynamic link library (DLL) version numbers.
Important Notes
The menu items in the list boxes of the end user interface for Cisco CallManager Release 3.0 are ordered by dependency. Any menu item that is a dependency of another item in that menu appears higher in the list. If the items have no dependencies, then they are alphabetized.
The Cisco CallManager Database Administration interface is designed to allow you to retrieve and modify the information in the Cisco CallManager database. In Release 3.0, the Database Layer manages database connections, and all updates are managed using this layer.
Caveats
This section contains unresolved caveats for this release of Cisco Call Manager. Caveats describe unexpected behavior or defects in Cisco CallManager software and related hardware.
Open Caveats for Cisco CallManager Release 3.0
Table 2 describes possible unexpected behaviors by Cisco CallManager Release 3.0.
Table 2 Open Caveats for Cisco CallManager Release 3.0
DDTS number
|
Description
|
CSCdr59957
|
SNMP agent sends bad response packet for certain phone IP addresses.
Given any Cisco IP Phone, with IP address X.X.X.Y, where
•X is any valid IP address range, and
•Y ranges from 0 to 15
the Cisco CallManager SNMP Agent is unable to decode the LAST Byte of the IP address correctly (in the above case, the byte represented by `Y').
This causes the Cisco CallManager SNMP Agent to report an incorrect IP address for the Cisco IP Phone in question. The LAST Byte of the IP address for that phone would be reported incorrectly.
Workaround: None. The only case for which the IP address will be reported correctly is when a Cisco IP Phone is assigned a network address greater than 15 for its LAST byte. Using the above example of X.X.X.Y, if Y ranges from 16 to 255, the IP address of the phone will be reported correctly by the Cisco CallManager SNMP Agent.
|
CSCdr58199
|
Cisco TFTP stops building files and accepting database change requests. When deleting devices, Cisco TFTP does not serve a file for a device that is in the database.
Workaround: Stop and start Cisco TFTP.
|
CSCdr58051
|
During the customer installation process, the Domain Name field is limited to a "top-level" domain name (for example, cisco.com is acceptable, but selsius.cisco.com is not acceptable). This limitation will be removed in the next major release of Cisco CallManager.
Workaround: To work around this limitation, the domain name can be changed AFTER the Operating System Installation and Recovery CD-ROM installation is complete AND BEFORE you insert the Cisco CallManager 3.0 Installation and Recovery CD-ROM to complete the installation.
Therefore, the steps are as follows:
1. Install the operating system with the Operating System Installation and Recovery CD-ROM. During this part of the installation, make sure that you specify a top-level domain name.
2. After the operating system installation completes and before inserting the Cisco CallManager 3.0 installation and Recovery CD-ROM, change the domain name.
To change the domain name, right click on Network Neighborhood, select Properties, click the Identification tab, click Change, enter the new domain name, then click OK to accept the changes.
3. Reboot the system.
4. Log on to the server:
Username: Administrator
Password:
5. Insert the Cisco CallManager 3.0 Installation and Recovery CD to continue with the installation (the system does not prompt you to insert the CD).
Changing the domain name at any other time could cause system instability and is not recommended.
|
CSCdr57272
|
The "Not Enough Bandwidth" message that displays on a Cisco IP Phone when calling between locations that are out of bandwidth will not display on a Cisco IP Phone 7960. This text displays correctly on the Cisco IP Phone 12 SP and other Cisco IP Phones.
Workaround: If you suspect that you are out of bandwidth, make a call from the same location using a Cisco IP Phone 12 SP+ to see if you get the "Not Enough Bandwidth" message. You can also look at the Cisco CallManager logs to see if this text message was sent to the Cisco IP Phone 7960 at the time of the attempted call.
|
CSCdr57242
|
OutofBandwidthText is not on by default, but it should be.
A call from a Cisco IP Phone to another Cisco IP Phone gets a reorder tone intermittently. Nothing on the phone display indicates the reason. Further troubleshooting showed that the call was made between locations and it was out of bandwidth. The Cisco IP Phone should have displayed the "Not Enough Bandwidth" message by default.
Workaround: Configure the OutofBandwidthText message that displays on the phone when calling between locations that are out of bandwidth. This should be on by default on a new install but if it is not, then it must be configured.
|
CSCdr55189
|
When a Cisco IP Phone 7960 is attached to a Cisco Catalyst 6000 switch, if the pvid on the switch port is changed, the phone may take up to 7 minutes to reconfigure and connect to the Cisco CallManager.
Workaround: No workaround is available. After 7 minutes the phone should be online on the new VLAN.
|
CSCdr54928
|
Cisco CallManager stops using the conference bridge.
When a Cisco Catalyst 4000 conference bridge is registered with the Cisco CallManager, the CallManager will periodically stop using the conference bridge even though it is registered with the CallManager.
Workaround: None.
|
CSCdr53488
|
In a system with a single Cisco CallManager, after the Cisco CallManager is brought down and left down for a period of time before being brought back up (perhaps 30 minutes), a Cisco IP Phone appears to be out of operation and displays an "opening......" message.
Workaround: Use the **#** reset sequence on the Cisco IP Phone to bring it back into operation.
|
CSCdr51675
|
When using the Cisco CallManager Control Center web page, the services for a server do not appear when it is selected. The message "A connection to the server could not be established" is displayed on the screen.
This symptom can occur under any of the following conditions:
•The server hosting the Cisco CallManager Administration web pages can not resolve the name or IP address of the target server.
•The target server is offline.
•The target server no longer exists, but it is still configured in the Cisco CallManager Administration pages.
•The target server's name in DNS does not match the server's machine name.
Workaround: You can start and stop the services on any server by logging onto the server at its console. From the Start menu, open the Administrator Tools program group and double click Services. You can then select the desired service and use the Start, Stop, and Re-Start icons at the top of the window to control the service.
To use the Control Center web page you must correct the configuration in the Cisco CallManager Administration pages or correct the network configuration on either the target server or the web server hosting the Cisco CallManager Administration pages.
|
CSCdr50642
|
After the initial installation, changing a server name to an IP address will cause phones not to boot. Auto-registering phones will not connect to Cisco CallManager. The reason they do not connect is that the configuration file still contains the server name.
Workaround: After changing the server name to an IP address, you must stop and then restart the Cisco TFTP service.
|
CSCdr49680
|
When the Cisco Catalyst 6000 8 Port Voice T1 and Services Module is reset while conferences are in progress, the Cisco CallManager will not set up any more conferences. This occurs when the device re-registers with the Cisco CallManager, and the callers have not yet hung up the phones.
Workaround: Reset the Cisco CallManager.
|
CSCdr49092
|
The dialing plan script incorrectly blocks the n11 office code. This problem will cause the calls to get a re-order tone if the dialer enters the office code as X11.
Workaround: One way to work around the problem is to set a route pattern with 9.XXXX11XXXX for 10-digit local dialing, 9.X11XXXX for 7-digit local dialing, and 9.1XXXX11XXXX for domestic long distance dialing in addition to 9.@.
This workaround can introduce a 10-second delay to initiate the call. One way to prevent this delay is to introduce a new pattern, such as 9.XXXX11XXXX#, and select a Discard Digits option of PreDot 10D->10D Trailing-#.
|
CSCdr48343
|
If you remove the Cisco CallManager service using the Cisco Service Configuration tool and then try to re-add the CallManager service back in using the Cisco Service Configuration tool, the service is never added and Cisco CallManager will not run.
Workaround: To work around the problem, you can restart the Cisco CallManager using the following method:
1. Select Start > Run from the Windows Start menu.
2. Type cmd and click OK to open a DOS window.
3. Enter the following command at the C\: prompt:
C:\> ccm.exe -service
4. Press RETURN.
The CallManager service is now added.
5. Re-start the Cisco CallManager service.
|
CSCdr47810
|
On a Cisco ICS7700 or a server running Cisco CallManager Release 3.0(1), if you delete the Cisco Database Layer Monitor service from the Service Parameters Configuration screen, the system does not operate properly when you restart it.
Workaround: To correct the problem, re-install the Cisco CallManager software.
|
CSCdr47046
|
Route pattern @ without local area-code waits for interdigit timeout. Dialing 7-digit numbers will typically require an interdigit timeout of 10 seconds.
Workaround: Add an "End-Of-Dialing Does-Not-Exist" filter to the route pattern 9.@.
|
CSCdr46136
|
Calls between Cisco CallManager clusters do not work. This is due to a database configuration error related to intercluster trunks.
Workaround: Use the following recommended configuration for intercluster trunks.
Recommended configuration for intercluster trunks in Cisco CallManager 3.0 to achieve highest trunk availability:
Given: There are two Cisco CallManager clusters: Clstr-A and Clstr-B (a cluster is one or more CallManager nodes).
Clstr-A configuration:
1. In Clstr-A, create a CallManager group that is to be used for intercluster trunk devices that connect to Clstr-B (for example, "Clstr-A to Clstr-B CM group". Add CallManager nodes from Clstr-A to this group in the order desired (up to three CallManagers can be added to this group). As an example, add nodes 2, 4, and 5 to this group (Clstr-A2, Clstr-A4, and Clstr-A5).
2. In Clstr-A, create a device pool that uses the newly created CallManager group (for example, "Clstr-A to Clstr-B device pool").
3. In Clstr-A, create up to three inter-cluster trunk devices that 'connect' to nodes in Clstr-B.
The device names of these inter-cluster trunks are the IP addresses or computer names (if names can be resolved to IP addresses), of the nodes in Clstr-B with which you wish to connect.
For example: DEVICE NAMEs = Clstr-B1, Clstr-B3, Clstr-B5, for nodes 1, 3 and 5 of Clstr-B.
For these devices, assign the DEVICE POOL that was created in step 2 above.
Note You must reset these devices when you create them to bring them in-service.
Clstr-B configuration:
Note Clstr-B configuration depends on Clstr-A configuration.
4. In Clstr-B, create a CallManager group that is to be used for intercluster trunk devices that connect to Clstr-A (for example, "Clstr-B to Clstr-A CM group"). For each of the intercluster trunks that was created in Clstr-A that connect to Clstr-B (see step 3), add the Clstr-B CM node that corresponds to its DEVICE NAME to this group.
For this scenario, add CallManager nodes Clstr-B1, Clstr-B3, and Clstr-B5 to this newly created group (the "Clstr-B to Clstr-A CM group".
|
CSCdr46136
(continued)
|
5. In Clstr-B, create a device pool that uses the newly created CallManager group (for example,"Clstr-B to Clstr-A device pool").
6. In Clstr-B, create intercluster trunk devices that connect to the nodes in Clstr-A that are included in Clstr-A's CM group (that is, the CallManager group created in step 1). Device names of these intercluster trunks are the IP addresses or computer names (if names can be resolved to IP addresses) of the nodes in Clstr-A that were designated in the CallManager group created in step 1, that is, nodes 2, 4 and 5 of Clstr-A (Clstr-A2, Clstr-A4, and Clstr-A5).
For these devices, assign the DEVICE POOL that was created in step 5.
Note You must reset these devices when you create them to bring them in-service.
The configuration described above creates a "web" of intercluster trunks where there is always an available trunk between Clstr-A and Clstr-B, given the following:
•one of the nodes in Clstr-A that is designated in CallManager group "Clstr-A to Clstr-B CM group" is running, and
•one of the nodes in Clstr-B that is designated in CallManager group "Clstr-B to Clstr-A CM group" is running.
|
CSCdr43467
|
Intercluster communication will fail if
•A Cisco CallManager name or IP address is used, and the DNS server does not have a reverse lookup zone configured for the subnet in which the Cisco CallManager's IP address exists, and
•A DNS server is configured in the network control panel on the Windows 2000 Server on which the Cisco CallManager resides.
Workaround: Use one of the following methods to work around the problem:
•If you want to use DNS, make sure that the DNS has reverse-DNS lookup enabled and that the names and IP addresses of the Cisco CallManagers are in the DNS server.
•A second workaround is to use only IP addresses for the Cisco CallManagers in the cluster (instead of relying on DNS names) and remove any DNS entries from the network control panel. This ensures that no reverse DNS lookup is attempted on any device connected via IP to the Cisco CallManager.
•A third workaround is to modify the hosts file in the winnt/system32/drivers/etc/ directory and add entries for the Cisco CallManagers.
|
CSCdr42883
|
Memory leaks in the database occur as a result of normal operation of the system.
DLLHost.exe is the executable under which the Microsoft Transaction Server (MTS) runs. This executable grows in memory size as changes are made to the database via services or Cisco CallManager Administration. If a long enough period of time elapses, then the memory size will drop. However, if there are several services polling the database periodically, this may not occur.
Workaround: Perform the following steps to reset the DLLHost.exe memory
1. Select Start > Administrator Tools > Component Services. > Console > COM+ Components > DBL COM+.
2. Right click on the DBL icon and select Shutdown. This will reset the DLLHost.exe memory.
Note There could be multiple DLLHost.exe applications running and visible in the Task Manager. The other DLLHost.exe programs are for applications other than MTS.
|
CSCdr42238
|
When communicating to the PSTN via a Cisco Catalyst 6000 PRI Gateway, audio is lost and the call has to be reinitiated.
Workaround: On the Cisco Voice Gateway 200, enter the following command from the IOS global configuration prompt:
vg200(config)# mgcp modem passthru CA
This command disables FAX operations and should not be used for Cisco VG 200s connected to FAX machines.
|
CSCdr41623
|
When a port on a Cisco Unicast Conference Bridge is conferenced back to itself, a feedback loop is created in the conference bridge and all participants will experience audio feedback. Even if all phones involved in the conference hang up, the conference bridge still has a feedback loop because two or more ports of the conference bridge are conferenced together and neither has disconnect supervision.
Workaround: You must perform a conference bridge reset to clear the conference.
|
CSCdr41614
|
DTMF digits are not propagated to members of a conference. When a DTMF digit is pressed when a phone is connected to a conference, the digit is dropped.
For example, if a ringing phone is added to a conference, and the phone is subsequently not answered and forwards to voice mail, there is no way to remove that party from the conference, or to exit or shut down voice mail.
Workaround: None. If voice mail is conferenced in by mistake, the only way to correct the problem is to terminate the conference and set it up again.
|
CSCdr41545
|
The problems described here can occur during database conversion when migrating from Cisco CallManager Release 2.4 to Cisco CallManager Release 3.0.
|
Auto-registration and range was enabled in the Cisco CallManager Release 2.4 database, but the migrated Release 3.0 database shows auto-registration disabled.
Workaround: Enable auto-registration using Cisco CallManager Administration.
|
The default phone templates for a Cisco CallManager may not be what you expect.
This occurs because the defaults table does not migrate from Release 2.4 to Release 3.0. Defaults are inserted per Cisco CallManager when a Cisco CallManager is added. The Cisco CallManager inserts the first Cisco IP Phone model 12 SP+ and model 30 VIPs phone templates found.
Workaround: Change the default phone templates using Cisco CallManager Administration.
|
A route filter was added during the installation, even though a route filter was not migrated. This route filter has no setting.
Workaround: None needed. The installation adds a default route filter by design.
|
The Cisco Messaging Interface was set in Release 2.4, but in Release 3.0 the service parameter for the voice mail number is blank. This problem occurs because voice mail records do not migrate from Release 2.4. This is by design. The DBConvert.txt file in c:\ describes any records that do not migrate.
Workaround: Set up the Cisco Messaging Interface using Cisco CallManager Administration.
|
A Call Park number was migrated, but a Cisco Call Manager was not assigned. Therefore, the Call Park did not work. Call Park migrated, but when you try to edit the Call Park and select a Cisco CallManager, none are displayed in the list. The Cisco CallManager CallParkMap entry is not converted because the Cisco CallManagers are not converted. Cisco CallManager Release 3.0 assigns any parks migrated to the first Cisco CallManager inserted.
Workaround: Delete the Call Park and add another Call Park.
|
Cisco uOne ports did not migrate. This occurs because voice mail devices do not convert from Release 2.4 to Release 3.0.
Workaround: Add the voice mail ports using Cisco CallManager Administration.
|
An intercluster gateway migrates from Release 2.4, but is not shown as an intercluster gateway in Release 3.0.
Workaround: Change the gateway to an intercluster gateway using Cisco CallManager Administration.
|
CSCdr41545
(continued)
|
Route patterns set up as blocks do not display in the route pattern list. The problem occurs because Release 3.0 migrate these records, but they are listed in the Numplan table as devices instead of routes.
Workaround: To correct the problem, try to find a device that matches the blocking route pattern, delete it, and add it as a route pattern. Another possible workaround is to edit the Numplan entry in the SQL Server Enterprise Manager and change tkPatternUsage from 2 (Device) to 5 (Route) and copy fkDialPlan from another record into this record.
|
Phone locations are not migrating from Release 2.4 to Release 3.0
Workaround: Set the device location in Cisco CallManager Administration.
|
CSCdr40345
|
Errors are returned by the Cisco CallManager User Administration web pages.
These errors are returned when the directory does not contain a complete listing of the devices in the Cisco CallManager database. This occurs when the directory is first configured and there are a large number of devices to import from the database to the directory.
Workaround: Wait for the directory to finish importing the device information. This is indicated by the quiescence of the DCX500.exe process.
|
CSCdr40169
|
No SMDI information is sent to Voice Mail on forward busy if the phone is in a partition. When a call is forwarded due to busy destination, the destination identification information is not sent to the SMDI interface. The caller then gets the Voice Mail generic greeting instead of being mapped into a specific voice mailbox.
Workaround: None.
|
CSCdr40091
|
When you change the name of a region, no calls can be made to or from endpoint devices in that region.
Workaround: Use one of the following methods to resolve this issue:
•Change the name of the region back to what it was before the name was changed.
•Reset all Cisco CallManagers in the cluster that contains the region whose name was changed.
|
CSCdr39493
|
You can not assign the same extension to a Cisco Catalyst 6000 24 Port FXS Analog Interface Module and a Cisco IP Phone.
Workaround: None. For Cisco CallManager Release 3.0, only MGCP gateways (VG 200s) allow FXS ports to share the same phone number with a Cisco IP Phone. This shared line capability is not supported for other analog gateways in this release.
|
CSCdr39403
|
Database notification does not work in certain situations. Updates made from the Cisco CallManager administration page are registered, but not reflected in the MIB tables until the SNMP data collector or Cisco CallManager (depending on the type of update) is restarted.
In Cisco CallManager clusters, changes to global values in a cluster environment are reflected on the MIB table that is local to the change, but not in all of the MIB tables throughout the cluster. Updates will only be reflected on the MIB table that is local to the change, with the following exceptions:
•When deleting a time, region or any static item, no MIB tables will reflect the change.
•When adding groups and regions, no MIB tables will reflect the change.
Workaround:
Restart the SNMP data collector or Cisco CallManager in order to display updated values in the MIB tables. If a Cisco CallManager cluster is involved, you must restart all SNMP data collectors in order to show consistent values in the MIB tables throughout the cluster.
Examples (local):
To remedy the two exceptions to local MIB table updating:
•When deleting a time, region or any static item, restart the SNMP data collector for the local Cisco CallManager installation to see the update reflected in the MIB table.
•When adding groups and regions to a Cisco CallManager cluster, restart the SNMP data collector, which will help to update the MIB table.
In Cisco CallManager clusters, changes to global values in a cluster environment will not be reflected in all of the MIB tables. You must restart all SNMP data collectors in order to show consistent values in the MIB tables throughout the cluster.
Examples (cluster):
•When adding or deleting multi-line extensions of an existing telephone, you must restart the Cisco CallManager system associated with that particular phone to activate the change in the MIB table for phone extensions.
•When changing the primary Cisco CallManager name and description, you must restart Cisco CallManager to see the changes in the Primary MIB table. If the update involves a Cisco CallManager cluster, you must restart all Cisco CallManagers in the cluster to see the changes reflected in all of the tables.
|
CSCdr37312
|
For gatekeeper-controlled intercluster trunks to work properly, the GatekeeperControlRegistrationType flag in System Parameters must be set to T (true).
Workaround: The GatekeeperControlRegistrationType flag must be set to T (true) for each Cisco CallManager that has a gatekeeper-controlled intercluster trunk.
|
CSCdr36464
|
The implementation of the search limit for devices that can be associated with users can result in an inaccurate representation of which devices a user currently controls. When a subset of devices is shown that contains devices that the user controls, these devices may be inaccurately represented as not being associated with the user.
Workaround: The issue may be worked around by increasing the number of displayed devices in the DC Directory Administrator tool:
1. On the machine running Cisco CallManager, select Start > Programs > DC Directory Administrator.
2. In the default Default Profile, click Next.
3. Enter the following:
User Name: Directory Manager
Password: ciscocisco
4. Click Finish.
5. Expand Directory > cisco.com > CCN in the window on the left, then click systemProfile.
6. Double-click on System Profile in the window on the right.
7. Click Modify.
8. Change the value for Maximum Search Results as necessary.
9. Click OK.
10. Exit DC Directory Administrator.
|
CSCdr36406
|
A <CmdArg>[Object Error]<noCmdArg> error message is returned when adding a user via the Cisco CallManager User Administration web pages.
If users have been added to the system via private scripts, the directory may not allow some userid name conflicts to occur, but does not properly report the conflict. For example, a user with the userid of "jsmith@company.com" will conflict with the proposed userid of "jsmith". This problem should not appear through normal usage of the product.
Workaround: Use a different userid for the new user or access the directory directly to delete the conflicting user.
|
CSCdr36331
|
Going from low bit rate to low bit rate, the wrong counter is sent from a transcoder. The problem occurs when th |
