|
|
August 15, 2000
These release notes describe the new features and caveats for Cisco CallManager Release 3.0(2d). 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.
The latest software upgrades and release notes for Cisco CallManager 3.0(2d) are available on Cisco Connection Online (CCO) at:
http://www.cisco.com/kobayashi/sw-center/internet/callmgr/callmgr.html
These release notes discuss the following topics:
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.
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.
Cisco CallManager Release 3.0(2d) is a maintenance release that addresses Cisco Media Convergence Server installation issues and resolves other high-priority Caveats. No new features have been added. Refer to the "Resolved Caveats" section for more information.
The following sections contain new and changed hardware and software features in Release 3.0 of Cisco CallManager.
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 recoverability. Configuration is simplified through a single web interface to the database for the entire system.
Digit analysis is the process used by Cisco CallManager to collect, parse, and translate dialed numbers to destination device IP addresses. In Cisco CallManager Release 3.0 and later, the digit analysis function is distributed across all Cisco CallManager servers in a cluster. This distribution allows scalability, load balancing, and redundancy across the cluster.
Cisco CallManager supports distributed multiple line appearance which allows multiple phones attached to multiple Cisco CallManagers to share one directory number (DN).
Release 3.0 introduces multiple Cisco CallManager nodes in a system. Access devices (gateways) may be registered in any of the nodes of the system, but must still be reachable using the configured Route Plan. Route Lists (which were called Route Points in Cisco CallManager Release 2.4 and earlier) and Route Groups are configured in the same manner as in Cisco CallManager Release 2.4 and earlier, with the same associations.
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 ranges of addresses to be easily routed or blocked. New to Release 3.0 is the ability to associate a route pattern to a device through partitions and calling search spaces.
This new feature allows both called and calling numbers to be modified by truncation, replacement of individual digits, discarding named sub-strings (called number only), or by prepending or appending digits before digit analysis.
The new Dial Plan Wizard enables you to create a dial plan quickly and easily. Also, pre-configured, pre-tested, country-specific dial plans may be created and substituted for the NANP files.
A new 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.
Two types of call pickup can be configured with Cisco CallManager Release 3.0:
This new feature allows ringing to be either enabled or disabled on any Cisco IP phone in the database. If ringing is enabled, an incoming call is presented on the phone through the display and/or lights as appropriate for that particular device, and by ringing the phone. If ringing is disabled, an incoming call is presented on the phone through the display and/or lights as appropriate for that particular device, but the phone does not ring audibly.
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.
The database layer provides an abstraction layer between Cisco CallManager and supporting applications. The abstraction layer provides for single-point system configuration while hiding automated, underlying data store replication.
This release of Cisco CallManager significantly reduces the number of database changes that require a Cisco CallManager restart in order to take effect.
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:
The intra-cluster feature transparency provided in Cisco CallManager Release 3.0 allows features such as device display management, device lamp management, media management, call hold and transfer capabilities, call park and pickup capabilities, distributed dial plan, and shared route plan (in the form of partitions and calling search spaces) to be configured and shared across all Cisco CallManagers within a cluster.
 |
Note MTP is not required for intra-cluster communication. |
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. New to Release 3.0 are minor bug fixes and support for intercluster transfer, hold, and conferencing through the H.323 empty capabilities set.
Beginning with Release 3.0, multiple Cisco CallManagers can be supported per configuration database. This feature allows load distribution for registered devices, call processing, and other functions across all Cisco CallManager servers in a cluster.
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. For the most current information about Cisco IP telephony system design guidelines, refer to the Voice Product Documentation page on Cisco Connection Online, located at http://www.cisco.com/univercd/cc/td/doc/product/voice/ |
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. |
Through partitions, the Cisco CallManager is able to support multiple instances of the same DN at a single site which are treated as independently reachable DNs. Using translation patterns, inbound calls to different direct inward dialing (DID) numbers with common subscriber line identifiers (extensions) can be configured.
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.
Cisco CallManager is able to allow or prohibit types of calls based on the class of the individual device or DN.
Cisco CallManager is more tightly integrated with the VG200 series of gateways through Media Gateway Control Protocol (MGCP). MGCP is used to provide inter-working between Cisco CallManager and VG200 gateways. The Cisco CallManager is able to control analog interfaces (FXS and FXO) directly.
MGCP messages are transmitted over TCP. The MGCP listen port represents the Cisco CallManager TCP listen port. The default for this port should be set to 2427.
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.
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.
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.
The Cisco IP Phone 7960 supports comfort noise. 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 (for example, 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 8 kHz). |
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.
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: a Windows NT service and Windows NT kernel mode driver. The Windows NT service is responsible for registering with the Cisco CallManager and handling Device Recovery. The kernel driver processes and controls the voice data packets.
The list of software processing services 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 Windows NT system administration tools.
The behavior of system services is controlled by parametric value adjustment. In Cisco CallManager Release 3.0, the interface to these settings has been consolidated into two Cisco CallManager Administration web pages. These parameters can now be obtained from the database. In earlier versions of Cisco CallManager, these settings were adjusted in .ini files or the Registry, or presented in application configuration dialogs.
This feature provides system-wide parametric value adjustment for all services within the enterprise.
In Release 3.0, an embedded Directory (instead of the relational database) is used to store user data (for example, information such as 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 and Call Forward All numbers.
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. 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. |
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.
Table 1 contains the hold feature modifications with Release 3.0:
| 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 |
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 (Centralized Automated Message Accounting) gateways.
Cisco CallManager Release 3.0 provides the ability to initiate a hook-flash blind transfer from POTS devices connected to any VG200 FXS port that is controlled by Cisco CallManager through MGCP.
AMIS-A (Audio Messaging Interface Specification-Analog) support allows VoIP devices to exchange AMIS-A Dual Tone Multi-Frequency (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 Cisco uOne voice mail message exchange and feature transparency 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 destination 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):
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 (OL-4086-01).
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 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).
The following list contains the modems and faxes that are either supported or not in Release 3.0:
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:
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.
The System category includes any system-related configurations that set the system's behaviors and options. It includes the following configurations:
This category allows you to configureroute plans, partitions, and so on. It includes the following menu items:
The Service category includes any applications that are add-on components, such as the following:
|
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. |
The Feature category contains configurations to add phone features and feature-related parameters to the system. It includes the following configurations:
The Device category contains configuration pages to configure devices (phones, gateways, and so on.) for the Cisco CallManager. It includes the following configurations:
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:
All plug-in applications are listed under the Application menu. Once the application is installed, the application name is shown under the application menu.
The Help menu includes the following categories: Contents and Index, For this Page, and About Cisco CallManager.
You should perform regular system backups as described in the section "Performing Backup and Restore Procedures," of the Installing Cisco CallManager Release 3.0 on the Cisco Media Convergence Server document.
Table 2 lists and describes Caveats that are resolved in Cisco CallManager Release 3.0(2d).
| DDTS Number | Summary | Explanation |
|---|---|---|
| Automated Installation | ||
CSCdr80536 | The SQL license is set to per server with a default of 5 concurrent connections. | The automated install of SQL server sets the licensing to 'per server' with a default of 5 concurrent connections. Per our licensing there should be no restrictions on concurrent connections for systems supporting up to 10,000 phones. The current setting prohibits installs of more than 5 servers in a cluster. |
CSCdr71568 | The automated installation program does not cap SQL memory on the database publisher or subscriber. | When using the automated installation, SQL memory usage is not capped on publishers or subscribers. There is a potential of a Cisco CallManager crash if SQL consumes too much memory. |
CSCdr65911 | Installation CD does not install Compaq Utilities correctly on the Cisco Media Convergence Server MCS-7830. | Disc 1 of the Cisco CallManager 3.0(1) CDs does install the Compaq Utilities 39 MB partition. However, for some reason, when the user presses F10 during the boot sequence there is an error message: This error occurs on the MCS-7830 platform. |
CSCdr66413 | Cisco Call Manager will not start after being installed from the Cisco CallManager 3.0(1) installation CDs. | If the DNS suffix is populated in the My Computer > Properties > Network Identification tab, Cisco Call Manager will not start after being installed from the Cisco CallManager 3.0(1) installation CDs. |
CSCdr58051 | The automated installation program restricts users to top-level domain names without special characters. | During the automated installation, the Domain Name field is limited to a top-level domain name (for example, Cisco.com is acceptable, but selsius.cisco.com would not be acceptable). |
CSCdr46034 | The automated installation program does not allow you to use a dash (-) or an underscore (_) in a workgroup or server name. | When installing the operating system from the "Operating System Installation and Recovery CD-ROM," the machine name entry field is limited to only alpha/numeric characters. |
| Cisco CallManager | ||
CSCdr69851 | Timer T200 should be set to 1200 ms instead of 1000 ms. | In certain digital sessions, the default value of timer T200 may be too small to ensure proper operation. Therefore, the default value for this timer has been changed to 1300 ms. |
| Cisco TFTP | ||
CSCdr58199 | Cisco TFTP stops building files and accepting database requests. | When deleting devices, TFTP does not serve a file for a device that is in the database. |
| Cisco Catalyst 6000 24 Port FXS Analog Interface Module (WS-X6624-FXS) | ||
CSCdr64557 | VAD causes multiple audio dropouts with Octel voice mail. | The user complaint is that audio, when accessing the Octel voice mail system, drops out intermittently. The dropout was reported to be from a fraction of a second to several seconds in duration, of almost continuous frequency. The problem was noted to occur even during the Octel voice prompts at the beginning of the session, indicating a problem in the stream from the Octel to the IP phone through the Cisco Catalyst 6000 24 Port FXS Analog Interface Module (WS-X6624-FXS) gateway. |
CSCdr68352 | WS-X6624-FXS ports out of service. | Shortly after all ports become concurrently "off-hook," Cisco Call Manager will report some ports status as "d" or "3" for anywhere from an hour to all day. Dick Tracy will report ports as either "NormalTalking Undefined!!" or "CallClearing Loop Open." Status via Telnet shows the ports as either on-hook or off-hook. When the ports are in either of these two states, they appear to be unusable since Cisco CallManager is using the next analog gateways in the route list. |
| Cisco Catalyst 6000 8 Port Voice T1/E1 and Services Module (WS-X6608-T1/E1) | ||
CSCdr69871 | WS-X6608-T1/E1 did not pass ISDN PRI Layer 2 homologation test. | This was resolved by setting the T200 default timer to 1300 ms. |
CSCdr79799 | Hold tone not played out by DSPs when holding. | The WS-X6608 Digital Gateway will not play hold tones every 10 seconds when a Cisco IP Phone places the call on hold. There is no workaround. This problem was due to mis-processing of the DtHoldTone message. It has been fixed in D004C300. |
| Cisco IP Phone | ||
CSCdr69914 | Disabling VAD for G.729 by setting the service parameter SilenceSuppressionSystemWide to FALSE does not appear to work. | When VAD is disabled for G729 and a call is made between two Cisco IP Phones, there is no continuous streaming. |
CSCdr54497 | Cisco IP Phone 7960 displaying DSP keepalive timeout message. | The message "dsp keepalive timeout" appears after doing the following: 1. Create a Meet Me conference. 2. Ad-hoc the Meet Me into itself. 3. The word "connected" on the Cisco IP Phone 7960 is replaced by "dsp keepalive timeout." |
| SNMP | ||
CSCdr59957 | SNMP agent sends bad response packet for certain Cisco IP Phone addresses. | Given any IP Phone, with IP address X.X.X.Y, where
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. 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, where Y ranges from 16 to 255, the IP address of the phone will be reported correctly by the Cisco CallManager SNMP agent |
This section lists unresolved caveats for this release of Cisco Call Manager. Caveats describe unexpected behavior or defects in Cisco CallManager software and related hardware.
Table 3 describes possible unexpected behaviors by Cisco CallManager Release 3.0(2d). Unless otherwise noted, these caveats apply to all Cisco CallManager 3.0 releases up to and including Cisco CallManager Release 3.0(2d).
| DDTS number | Description | ||||
|---|---|---|---|---|---|
CSCdr93939 | In times of network congestion or high variable delay, the jitter buffer on a Cisco IP Phone 7960 will grow to a large value in an attempt to compensate for the large amount of jitter. When network conditions improve and the jitter returns to a low value, the phone will continue to buffer packets for a long time in its jitter buffer, thereby causing unacceptable voice delay. Workaround: Put the call on hold and then resume it; this will start a new RTP stream and reset the jitter buffer. | ||||
CSCdr92267 | One-way voice on consecutive calls; hold or reset will fix. One way audio can occur on consecutive calls from Cisco IP Phone to Cisco IP Phone. The problem has occurred on different phones at different times of the day to different users. Workaround: Reset the phone or, while in the call, put it on, then off hold. | ||||
CSCdr89545 | Incorrect help definitions for Hold service parameters.
Workaround: Use the definitions above instead of the definitions in the Cisco CallManager Administration Guide and online help. | ||||
CSCdr77184 | When the configured ranges of Call Park numbers are all used, users can no longer park calls. Workaround: Open Cisco CallManager Administration, choose Feature > Call Park, select a range, and click Update. You can also create a new range. | ||||
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:
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 re-add and restart the Cisco CallManager service using the following method: 1. Select Start > Run from the Windows Start menu. 2. Type 3. Enter the following command at the C\: prompt:
4. Press Return.
5. Reboot the system. 6. Log in to the system. 7. Select Start > Programs > Cisco CallManager > Cisco CallManager Service Configuration. 8. Click the check box for Cisco CallManager service. 9. Click OK. 10. Click OK to reboot the system when prompted. 11. Log in to the system and open Cisco CallManager Administration. 12. Select Services > Control Center. 13. Verify that the Cisco CallManager service is now listed as an available service. 14. 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.
Clstr-B 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.
| ||||
CSCdr46136 | 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).
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:
| ||||
CSCdr43467 | Intercluster communication will fail if
Workaround: Use one of the following methods to work around the problem:
| ||||
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.
| ||||
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 | 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. | ||||
CSCdr40194 | A route pattern containing more than 24 characters fails. This problem can occur under the following conditions: Create a route pattern in the Route Pattern Configuration Page. Associate this route pattern with a Route List or gateway. The route pattern may or may not be more than 24 characters. Attempt to make a call that matches the route pattern defined. The result is the calling party receives a reorder tone. The call cannot be completed. Background: Cisco CallManager expands the route pattern and analyze the resulting matching digit strings. If the digits are sent to public networks, the ISDN protocols have a limitation of 24 digits. If the expanded resulting digit string is more than 24 digits. the number will be truncated. This is the limitation of the ISDN protocols. For example, user enters a route pattern string that has less than 24 characters. The resulting matching digit string can end up being greater than 24 characters (wildcards can present numerous digits). If the resulting matching digit string is greater than 24 digits, only the first 24 digits will be sent. If the resulting matching digit string is less than 24 characters, Cisco CallManager will send all digits to the public networks. If the user enters in more than 24 characters for a route pattern, the resulting matching digit string can end up with less than 24 characters (for example, if there is a long access code and user selects a digit discard instruction to truncate the access code). If so, the resulted digits will be sent. However, if the resulting matching digit string is still greater than 24 characters, then, only the first 24 digits are sent. Workaround: Since the route pattern's allowable digits may or may not be exactly what the user enters in the Route Pattern field in the Route Pattern Configuration Page, the page does not limit the user's input to only 24 characters. The database has a limitation of 50 characters for the Route Pattern field, so this field has the number of allowable characters to be 50 characters. | ||||
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:
| ||||
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:
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:
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):
| ||||
CSCdr37312 | For gatekeeper-controlled intercluster trunks to work properly, the Workaround: The | ||||
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:
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 the system is configured so that a transcoder is invoked to transcode between two low-bit-rate codecs (for example, from a G.723 to a G.729).
When a transcoder is invoked to transcode between two low-bit-rate codecs, the transcoder consumes the internal resources of two transcoders, but only one transcoder is allocated. As a result, more transcoders are available to be allocated in the system than there are internal transcoding resources to support them. When all available internal transcoding resources are in use, and another transcoder is allocated and begins transcoding, the voice quality on all calls going through that transcoder device degrade noticeably, and sometimes severely. Workaround: It is highly recommended that the system be carefully configured so that transcoding between low-bit-rate codecs is not required. There is no workaround to this problem other than limiting the number of calls through a given transcoder device by expanding the number of transcoders available. If there are at least twice as many transcoders available as there are calls that need them at any given point in time, the problem should be eliminated. | ||||
CSCdr35751 | This problem occurs when Call Forward All is cleared from the user preference pages for a DN that is shared by multiple phones (that is, a multi-line). When Call Forward All is cleared on a multi-line, a reset is only sent down to one phone that shares the multi-line, and the call forward lights are cleared on that phone only. The call forward is cleared for the specified DN, but the forward lights on all other phones will remain on, thus giving a false indication that the phone is still forwarded, when it really is not. Workaround: To work around the problem:
| ||||
CSCdr35729 | Cisco CallManager with Cisco Catalyst 6000 does not support G.723.1 variable voice payload. One issue is that all components that support G.723 do not necessarily handle the lower bit rate of 5.3 kbps. This is of particular significance when trying to run with a Cisco 2600/3600/5300 Series voice-enabled router configured to use only 5.3 kbps. Another issue is that the Cisco CallManager negotiates a "maximum payload size" of 30 msec of data (24 bytes at 6.3 kbps) with the Cisco Catalyst 6000 8 Port Voice E1/T1 and Services Module. In the H.323 negotiations, it allows the other client to send packets larger than the number negotiated with Cisco Catalyst 6000 8 Port Voice E1/T1 and Services Module. Workaround: 1. Ensure that the low bit rate selection for G.723 is always configured for 6.3 kbps. 2. Configure devices to NOT pack multiple sample sets into a single packet-- that is, allow only 30 msec of data (24 bytes) per packet. | ||||
CSCdr35007 | The second Cisco IP Phone 7960 in a daisy chain loses connection after one minute. If you connect Cisco IP Phone 7960s together in a line (that is, daisy chain them), a problem with one phone can affect all subsequent phones in the line. The bandwidth is also shared among all phones in the line. Workaround: None. Daisy chaining of Cisco IP Phones is not supported. Each Cisco IP Phone should be directly connected to a switch port. | ||||
CSCdr34988 | The first Cisco IP Phone 7960 in a daisy chain stopped communicating with the Cisco CallManager. If you connect Cisco IP Phone 7960s together in a line (that is, daisy chain them), a problem with one phone can affect all subsequent phones in the line. The bandwidth is also shared among all phones in the line. Workaround: None. Daisy chaining of Cisco IP Phones is not supported. Each Cisco IP Phone should be directly connected to a switch port. | ||||
CSCdr34794 | With any connections involving two separate low-bit-rate voice compressions, such as calls between different cell-phone networks, connections from an external cell-phone through a VoIP gateway terminating at a Cisco IP Phone running G.729 may result in non-optimal voice quality. Workaround: It is recommended that calls between Cisco IP Phones and VoIP gateways that reach the external PSTN be configured for G.711 operation. | ||||
CSCdr32527 | After adding a device, you must close the browser to display the updated added device. If devices are associated with a user, the list of available devices is cached for faster retrieval. Consequently, if new devices are added after the device information for users is cached, the new devices will not be available for association with users. Workaround: Exit the browser and then restart it to clear the device information cache. | ||||
CSCdr31859 | Software conference bridges on a secondary Cisco CallManager are deactivated when a hardware conference bridge fails over to a secondary Cisco CallManager that only has software conference bridges registered. Hardware conference bridges and software conference bridges cannot be registered on the same Cisco CallManager at the same time. When a hardware conference bridge fails over to a secondary Cisco CallManager and registers with that Cisco CallManager, all software conference bridges currently registered on that Cisco CallManager are deactivated and only the resources of the hardware conference bridges are available. When the primary Cisco CallManager for that hardware conference bridge comes back up, the hardware conference bridge will un-register from its secondary Cisco CallManager, and re-register with its primary Cisco CallManager. The secondary Cisco CallManager is then left without any registered conference bridge resources, because they have all been deactivated. Workaround: Use one of the following methods to work around the problem:
| ||||
CSCdr30628 | The Cisco IP Phone 7960 speakerphone does not automatically save the volume level. Workaround: To save the current volume level setting, adjust the volume, select Settings, and then select Save. | ||||
CSCdr28947 | Transfers from Cisco uOne to invalid extensions by pressing * 8 leave the caller in silence. For example, if a user logs into a mailbox, presses * 8 to transfer, and enters an invalid extension, the transfer is attempted, but the user does not hear anything after the standard Cisco uOne prompt is played. In this situation, the caller is on hold pending transfer completion. The transfer is never completed because the extension was invalid, and re-order was returned to the uOne port. Re-order is not recognized by the Cisco uOne port, so no further action is taken, and the caller is left on hold. Workaround:
| ||||
CSCdr24500 | Cisco Access Digital Trunk Gateway DE-30+ generates ISDN errors (wrong IE) when connecting from IP to PSTN. For example: There is nothing wrong with the call that is due to the error responses generated. Cisco CallManager does not yet support the full range of ISDN features, and that is effectively what the trace is showing. The IE errors do not prevent the call from being completed. Workaround: None necessary. You can call the Central Office and ask them to turn off the extra IEs. | ||||
CSCdr20726 | H.323 phone does not hear progress tones during call setup. Workaround: None. This feature is not supported in Cisco CallManager Release 3.0. | ||||
CSCdr20006 | Incorrect search results are displayed in the User Directory search. The problem occurs when: 1. A search is executed from either the basic or advanced search pages. 2. The browser Back button is clicked. 3. A new search is entered and executed. After the above steps are performed, the results of the first search are displayed as the results for the second search, which is incorrect. Workaround: To avoid the problem, do not click the browser's Back button after executing a user search. Instead, click the Begin a New Search or Refine Search links. | ||||
CSCdr14562 | Clicking too rapidly on the Update button in the Cisco CallManager Administration Configuration screen can cause the browser to stop responding. The browser seems to be connecting to the server, but it remains in a wait state from which it can not recover. The browser does not respond to any user input. The status area at the bottom of the window displays the message Validating.... Workaround: Make sure that you only click Update once; the processing will proceed without errors. If the problem does occur, close the existing browser window, open a new browser window, and begin the procedure again. | ||||
CSCdr13641 | Cisco uOne is capable of playing a specific message to the calling party to inform the calling party that the called party was busy or did not answer. Cisco CallManager does not currently distinguish between call forward busy and call forward no answer calls when sending information to a voice mail system. The information sent to the voice mail is the same whether it is a busy or no answer condition. Workaround: There is no workaround other than to have the user make a generic greeting. Cisco CallManager Release 3.0 does not support this feature. | ||||
CSCdp97606 | 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. | ||||
CSCdp60775 | The Cisco CallManager User pages are not accessible or the user administration pages return errors when accessed. Under extreme conditions such as low memory, or network problems, it is possible that DCD Directory Server service may stop running. This will cause the web pages mentioned above to function incorrectly or not at all. Workaround: To work around the problem, restart the DC Directory service either from the Services administrative tool or by running the following command: |
For specific troubleshooting information, refer to the Cisco IP Telephony Troubleshooting Guide for Release 3.0. You can access this guide at the following website address:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_0/index.htm
This section contains the latest documentation updates for Release 3.0 of the Cisco CallManager. Included in these updates are any changes or late-breaking information that occurred after production of the Release 3.0 Cisco CallManager Administration Guide, Configuring Remote Serviceability for Cisco CallManager Release 3.0, and/or the online help for the Cisco CallManager application, as well as any information that was omitted from the Release 3.0 documents.
Table 4 contains new Cisco CallManager service parameters, with descriptions, that were not included in the Release 3.0 Cisco CallManager Administration Guide or the online help for the Cisco CallManager application.
|
Caution Please do not modify any of the defaults or settings of the following parameters without the assistance of the Cisco Technical Assistance Center (TAC). |
| ParamName | Description |
|---|---|
EnableSNMP | This parameter enables the collection of SNMP data from the Cisco CallManager. |
EnableStatistics | This parameter enables or disables collection of performance monitor statistics by the Cisco CallManager. |
Table 5 contains new Cisco Messaging Interface (CMI) service parameter definitions that were not included in the Release 3.0 Cisco CallManager Administration Guide or the online help for the Cisco CallManager application.
|
Caution Please do not modify any of the defaults or settings of the following parameters without the assistance of the Cisco Technical Assistance Center (TAC). |
| ParamName | Description | ||
|---|---|---|---|
BackupCallManagerName | This parameter is used to define the names of the Cisco CallManagers that are going to be used for the CMI backup. You can use either the name of a Cisco CallManager or its IP address. | ||
BaudRate | Cisco CMI connects to the voice mail system via an RS-232 connection. This parameter defines that connection. Recommended default value: 9600
| ||
CallManagerName | This parameter is used to define the names of the Cisco CallManagers that are going to be used for the CMI primary. You can use either the name of a Cisco CallManager or its IP address. | ||
DataBits | CMI connects to the voice mail system via an RS-232 connection. This parameter defines that connection. Recommended default value: 7 | ||
DialingPlan | This parameter is one of four that are required by CMI to register an intercept for the voice mail system with which CMI is going to work.
| ||
InputDnSignificantDigits | This parameter is designed to accommodate the differences between voice mail mailbox numbers and DNs. If a legacy voice mail system has mailbox numbers that are longer than the DNs on the system, this parameter can be used to strip the most significant digits. The numeric value of this parameter indicates how many digits should be used.
Recommended default value: 10 | ||
KeepAliveDn | This is a string parameter. For most voice mail systems a value of F is acceptable. However, some Octel systems periodically send an invalid DN specifically for the purpose of verifying that the attached Cisco CallManager is functioning properly. In this case, you can turn off ValidateDns if you know the DN that the Octel system will use as a keep-alive. By programming that DN into the KeepAliveDn parameter, you will ensure that the invalid DN message is returned to the voice mail system when needed. | ||
OutputDnFormat | This parameter is used to format the DNs sent to the voice mail system. Most numbers passed to the voice mail system are formatted using this parameter. Default value: %010s | ||
OutputExternalFormat | This parameter is also used to format the DNs sent to the voice mail system. Calling party DNs that are seven digits or longer are formatted using this parameter. Default value: %010s | ||
Parity | Cisco CMI connects to the voice mail system via an RS-232 connection. This parameter defines that connection. Recommended default value: Even
| ||
RouteFilter | This parameter is one of four that are required by CMI to register an intercept for the voice mail system with which CMI is going to work.
| ||
SerialPort | Cisco CMI connects to the voice mail system via an RS-232 connection. This parameter defines that connection. Recommended default value: COM1
| ||
SsapiKeepAliveInterval | This is a numeric parameter. During normal operations, CMI will be attached to a Cisco CallManager. When this is the case, CMI sends a keep-alive message to the Cisco CallManager at the rate specified by this parameter. Default value: 30 seconds
| ||
StopBits | Cisco CMI connects to the voice mail system via an RS-232 connection. This parameter defines that connection. Recommended default value: 1 | ||
ValidateDns | When CMI receives incoming lamp commands from the voice mail system, it normally validates the DN against the NumPlan table. This is an attempt to verify that the DN matches an existing DN known to Cisco CallManager. If the DN is not found in NumPlan, an invalid DN message is sent to the voice mailbox. Default value: T
| ||
VoiceMailPartition | This parameter is one of four that are required by CMI to register an intercept for the voice mail system with which CMI is going to work.
|
To make it possible for the Cisco Service Engineer (CSE) to log into the Telnet service on your Cisco CallManager system, you must configure the Microsoft Telnet daemon.
Use the tlntadmn command to accomplish this task.
Step 2 In the command window, enter the Telnet administration command:
tlntadmnStep 3 Enter the following options from the lists displayed at the prompt.
a. From the first list, select option number 3, Display/change registry settings
b. From the second list, select option number 7, NTLM
Step 4 Next, set the value of NTLM to zero by responding to the prompts.
Current value of NTLM = 2 Do you want to change this value ? [y/n]y NTLM [ current value = 2; acceptable values 0, 1 or 2 ] :0 Are you sure you want to set NTLM to :0 ? [y/n]y
Step 5 To finish, enter the following options from the lists displayed at the prompt.
a. From the first list, select option number 0, Exit this menu.
b. From the second list, select option number 0, Quit this application.
Step 6 Restart the Telnet service to enable the setting to take effect.
Change the CiscoWorks2000 server name by editing the SAenvproperties.ini file manually, then restarting the Cisco Syslog Collector service. In future releases, an administrative interface will be available for this purpose.
To run show tech correctly, use this example to construct your command:
show -f output.txt -v -w480 db
The example given in the Show Command chapter of Configuring Remote Serviceability for Cisco CallManager 3.0 (page 3-2) lacks a space before "db".
This section contains changes that have occurred since the original release of the Cisco CallManager Administration Guide Release 3.0. These changes do not currently appear in the Release 3.0 Cisco CallManager Administration Guide or the online help for the Cisco CallManager application.
SdlTraceTotalNumFiles is a service parameter for the Cisco CallManager service type. The default has been changed to 250. This is the correct default for this service parameter.
This section contains lists of service parameters for the Cisco CallManager that were not included in the initial production of the Release 3.0 Cisco CallManager Administration Guide and online help for the Cisco CallManager application. These parameters will be defined in a later release of the document.
|
Caution Please do not modify any of the defaults or settings of the following parameters without the assistance of the Cisco Technical Assistance Center (TAC). |
The following list contains the service parameters that can be configured for the Cisco CallManager service type that were omitted from the Release 3.0 Cisco CallManager Administration Guide and online help for the Cisco CallManager application:
The following list contains the service parameters that can be configured for the Cisco TFTP service type that were omitted from the Release 3.0 Cisco CallManager Administration Guide and online help for the Cisco CallManager application:
The following list contains the service parameters that can be configured for the Cisco Messaging Interface (CMI) service type that were omitted from the Release 3.0 Cisco CallManager Administration Guide and online help for the Cisco CallManager application.
The following list contains the service parameters that can be configured for the Cisco IP Voice Media Streaming service type that were omitted from the Release 3.0 Cisco CallManager Administration Guide and online help for the Cisco CallManager application:
The following list contains the service parameters that can be configured for the Cisco Enterprise service type that were omitted from the Release 3.0 Cisco CallManager Administration Guide and Online Help:
This section contains any errors contained in the Cisco CallManager Administration Guide for Release 3.0 and/or the online help for the Cisco CallManager application. These errors will be corrected in the upcoming release of the document and online help application.
The name of the Cisco Messaging Interface (CMI) service parameter appears incorrectly in the documentation and online help application. The parameter name should be MwiSearchSpace. The documentation is also missing a description of the value to be entered. The value to enter for MwiSearchSpace is a colon-separated list of partition names. For example, dallas01:dallas02:dallas03, where dallas01, dallas02, and dallas03 are names of partitions.
The definitions for the Cisco CallManager HoldType and ToneOnHoldTime service parameters are incorrect in the Cisco CallManager Administration Guide and online help for Cisco CallManager Release 3.0. The correct definitions are as follows:
For service and support, contact Cisco Technical Assistance Center (TAC) at:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
This section provides different methods of obtaining Cisco documentation.
You can access the most current Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM is updated monthly. Therefore, it is probably more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.
Registered CCO users can order the Documentation CD-ROM and other Cisco Product documentation through our online Subscription Services at http://www.cisco.com/cgi-bin/subcat/kaojump.cgi.
Nonregistered CCO users can order documentation through a local account representative by calling Cisco's corporate headquarters (California, USA) at 408 526-4000 or, in North America, call 800 553-NETS (6387).
Cisco provides Cisco Connection Online (CCO) as a starting point for all technical assistance. Warranty or maintenance contract customers can use the Technical Assistance Center. All customers can submit technical feedback on Cisco documentation using the web, e-mail, a self-addressed stamped response card included in many printed docs, or by sending mail to Cisco.
Cisco continues to revolutionize how business is done on the Internet. Cisco Connection Online is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at anytime, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.
CCO's broad range of features and services helps customers and partners to streamline business processes and improve productivity. Through CCO, you will find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online support services, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.
Customers and partners can self-register on CCO to obtain additional personalized information and services. Registered users may order products, check on the status of an order and view benefits specific to their relationships with Cisco.
You can access CCO in the following ways:
You can e-mail questions about using CCO to cco-team@cisco.com.
The Cisco Technical Assistance Center (TAC) is available to warranty or maintenance contract customers who need technical assistance with a Cisco product that is under warranty or covered by a maintenance contract.
To display the TAC web site that includes links to technical support information and software upgrades and for requesting TAC support, use www.cisco.com/techsupport.
To contact by e-mail, use one of the following:
Language | E-mail Address |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
In North America, TAC can be reached at 800 553-2447 or 408 526-7209. For other telephone numbers and TAC e-mail addresses worldwide, consult the following web site: http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml.
If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, for your convenience many documents contain a response card behind the front cover. Otherwise, you can mail your comments to the following address:
Cisco Systems, Inc.
Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate and value your comments.
Access Registrar, AccessPath, Any to Any, Are You Ready, AtmDirector, Browse with Me, CCDA, CCDE, CCDP, CCIE, CCNA, CCNP, CCSI, CD-PAC, the Cisco logo, Cisco Certified Internetwork Expert logo, CiscoLink, the Cisco Management Connection logo, the Cisco NetWorks logo, the Cisco Powered Network logo, Cisco Systems Capital, the Cisco Systems Capital logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, the Cisco Technologies logo, Fast Step, FireRunner, Follow Me Browsing, FormShare, GigaStack, IGX, Intelligence in the Optical Core, Internet Quotient, IP/VC, IQ Breakthrough, IQ Expertise, IQ FastTrack, IQ Readiness Scorecard, The IQ Logo, Kernel Proxy, MGX, Natural Network Viewer, NetSonar, Network Registrar, the Networkers logo, Packet, PIX, Point and Click Internetworking, Policy Builder, Precept, RateMUX, ReyMaster, ReyView, ScriptShare, Secure Script, Shop with Me, SlideCast, SMARTnet, SVX, The Cell, TrafficDirector, TransPath, VlanDirector, Voice LAN, Wavelength Router, Workgroup Director, and Workgroup Stack are trademarks; Changing the Way We Work, Live, Play, and Learn, Empowering the Internet Generation, The Internet Economy, and The New Internet Economy are service marks; and Aironet, ASIST, BPX, Catalyst, Cisco, Cisco IOS, the Cisco IOS logo, Cisco Systems, the Cisco Systems logo, the Cisco Systems Cisco Press logo, CollisionFree, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastLink, FastPAD, FastSwitch, GeoTel, IOS, IP/TV, IPX, LightStream, LightSwitch, MICA, NetRanger, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. or its affiliates in the U.S. and certain other countries. All other trademarks mentioned in this document 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. (0005R)
Copyright © 2000, Cisco Systems, Inc.
All rights reserved.
Posted: Tue Aug 15 08:46:08 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.