Cisco CallManager System Guide, Release 3.1(1)
Administrative Tools Overview

Table Of Contents

Administrative Tools Overview

Bulk Administration Tool (BAT)

Administrative Reporting Tool (ART)

Remote Serviceability for Cisco CallManager

SNMP Instrumentation on the Cisco CallManager Server

System Logging Components

Syslog Collector

Syslog Administrative Interface

CiscoWorks2000 Voice Management Features

Campus Manager

User Tracking

Trace Path Analysis

Resource Manager Essentials

Inventory Control and Reporting

System Logging Management

Syslog Message Filtering


Call Detail Records

Enabling CDR Collection

CDR-Related Service Parameters

Removing CDR Records

CDR Database Access

Where to Find More Information

Administrative Tools Overview

This section provides an overview of the following tools for Cisco CallManager administrators:

Bulk Administration Tool (BAT)

Administrative Reporting Tool (ART)

Remote Serviceability for Cisco CallManager

CiscoWorks2000 Voice Management Features

Call Detail Records

Where to Find More Information

Bulk Administration Tool (BAT)

The Bulk Administration Tool (BAT), a plug-in application to Cisco CallManager, lets you add, update, or delete a large number of phones, users, Cisco VG200 gateways and ports, and Cisco Catalyst 6000 24 Port FXS analog interface modules to the Cisco CallManager database. Where this was previously a manual operation, BAT helps you automate the process and achieve much faster add, update, and delete operations.

BAT is a web-based application that requires Internet Explorer 4.01 Service Pack 2 or later or Netscape 4.5 or later. Cisco CallManager Administration provided the model for the look and feel of BAT.

You can access BAT from Cisco CallManager Administration and vice versa using the Application menu.

For more information on BAT, refer to the Bulk Administration Tool Guide for Cisco CallManager.

Administrative Reporting Tool (ART)

The Administrative Reporting Tool (ART) for Cisco CallManager 1.0(1), a web-based reporting application, generates the following reports that provide information regarding voice quality and generates reports on the gateway performance.

Quality of service

Traffic details

User call details

Billing details

Gateway details

Call Detail Records

The Cisco CallManager records information regarding each call in Call Detail Records (CDRs) and Call Management Records (CMRs). CDRs and CMRs serve as the basic information source for ART and are stored in the ART database.

Retrieve the information that is not present in the CDR and CMRs, but is required for various reports, from the Light Weight Directory Access Protocol (LDAP), or the ART administrator must enter the information.

Access to ART is available only through a secured login to the package. The user ID and password for ART access are the same as the user profile set for Cisco CallManager.

Access ART using Internet Explorer 4.01 Service Pack 2 or later, or Netscape 4.5 or later.

To view the reports, ART requires the Adobe Acrobat reader, which you can download and install from the ART main screen.

For more information on ART, refer to the Administrative Reporting Tool Guide for Cisco CallManager.

Remote Serviceability for Cisco CallManager

Network management tools, if properly deployed, can provide the network administrator with a complete view into any enterprise network. With the advent of converged networks, it is imperative to have network management systems enable the following capabilities, at a minimum:

Network discovery and topology maps

Inventory control and configuration management of networked nodes

Report generation, system logging, and analysis of the respective data

Cisco CallManager Remote Serviceability and CiscoWorks2000 provide the above capabilities, as well as other mechanisms, which enable visibility into the health and availability of the Cisco AVVID network. Considerable management features have been added, starting with Cisco CallManager Release 3.0, to permit visibility into the operation and reporting capability of a Cisco AVVID network. Table 35-1 lists the features that have been provided for network management applications to export data and, particularly for CiscoWorks2000, to provide reporting, proactive management, debugging, and other capabilities.

Table 35-1 Remote Serviceability Features for Cisco CallManager 


Simple Network Management Protocol (SNMP) Instrumentation

Two Management Information Bases (MIBs) have been added to Cisco CallManager to permit a network management system to extract appropriate information.

Call Detail Record (CDR) Logging

Call Detail Record is used for accounting, debugging, and path analysis.

Cisco Discovery Protocol (CDP) Support (CDP MIB)

Cisco Discovery Protocol support for Cisco CallManager server advertisement and discovery via a network management system such as CiscoWorks2000. This is the "tell" side of CDP via SNMP enablement.

System Logging Components

Cisco Syslog Collector for message filtering, collection, and repository to a Syslog server.

The following sections describe some of these features in more detail.

SNMP Instrumentation on the Cisco CallManager Server

Simple Network Management Protocol (SNMP) features for Cisco CallManager enable network management applications to retrieve data from the Cisco CallManager server in a standard fashion. The SNMP agent on the Cisco CallManager server is a subagent (extension agent) of the Microsoft Windows 2000 system agent. Therefore, you must enable the SNMP service on the Windows 2000 system for the SNMP instrumentation to function on the Cisco CallManager server.

Two Management Information Bases (MIBs) were introduced in Cisco CallManager Release 3.0 to permit the export of data as well as to support server advertisement and discovery. Both MIBs are extension agents and are independent of each other to facilitate future applications and functionality:


This MIB exports data from the Cisco CallManager database and other data sources. Examples of the exported data include Cisco CallManager group tables, region tables, time zone group tables, device pool tables, phone detail tables, gateway information tables and status traps, CDR host log table, performance counters, and so on.


This MIB uses Cisco Discovery Protocol (CDP) to enable CiscoWorks2000 to discover the Cisco CallManager server and to retrieve information from variables such as the interface table, deviceID, and so on. This is a limited implementation of the MIB and is essentially a subset of the CDP MIB related to advertisement (that is, the "tell" side of the MIB).

More detailed information on the CDP MIB is available on Cisco Connection Online (CCO) at

System Logging Components

The primary objective of system logging components is to provide a working solution for a centralized event logging and debug trace scheme in the multiplatform, distributed Cisco AVVID environment. In an open, distributed system, you can have multiple applications running on multiple systems. For ease of maintenance, have a common event log and a common trace log where Cisco CallManager can report events.

The interface to log events must be usable with most common programming languages. Also, with a common logging interface, the format of the log messages must be uniform across the system for ease of readability. Finally, the system should also have a common administrative interface to display and control all the event traces. Cisco CallManager and CiscoWorks2000 provide this functionality for unified message logging, display, and management. The following are the two main components to the system logging mechanism:

Syslog Collector, which resides on Cisco CallManager

Syslog Receiver (The CiscoWorks2000 server can also function as a receiver, as described in the "Syslog Administrative Interface" section.)

Syslog Collector

A Syslog Analyzer Collector (SAC) program runs as a Windows NT service on the Cisco CallManager server or any processing node in the network. The SAC program uses a configuration (.ini) file to set the environment variables such as the CiscoWorks2000 hostname and other parameters. This configuration file, SAenvProperties.ini, and its directory path are specified in the Windows NT registry, and the Cisco CallManager installation program sets their values. During startup time, the SAC tries to check in with the CiscoWorks2000 server to get some configuration and message filter information using a Common Object Request Broker Architecture (CORBA) method call. Then, it sends an initialization message that consists of the SAC hostname, the name of the syslog file, and other information for CiscoWorks2000 to keep track of it.

During normal operation, SAC reads messages from User Datagram Protocol (UDP) port 514. When it receives new messages, SAC processes the messages (for example, by performing filtering and time zone conversions) and then sends them to the CiscoWorks2000 server for storage and analysis. SAC also sends a status or statistic message periodically to the CiscoWorks2000 server. Figure 35-1 illustrates the interoperability of CiscoWorks2000 and Cisco CallManager.

Figure 35-1 Syslog Architecture for the Interoperability of Cisco CallManager and CiscoWorks2000

During installation of Cisco CallManager, the installation program normally prompts you to enter CiscoWorks2000 server information (for example, hostname or IP address). You can skip this step during installation and add the information later by modifying the contents of the file SAenvProperties.ini, located in \Program Files\Cisco\Bin. Set the SAC_SERVER and BINDNAME to the CiscoWorks2000 server.

The contents of the SAenvProperties.ini file are as follows:

FILE= /var/log/syslog_info
SAC_PORT = 514
BINDNAME =<your_server_hostname>::SaReceiver

Syslog Administrative Interface

The Syslog administrative interface is a web-based interface that is part of Cisco Call Manager Administration, under Service > Trace. A new page shows the status of each trace flag and the trace output options of each service for each server in a Cisco CallManager cluster, as illustrated in Figure 35-2. You can enable or disable the trace flags from the administrative interface, which updates the trace configuration in the database layer.

Figure 35-2 Administrative User Interface for Syslog Trace Functions

Options also exist to enable the debug trace messages and to configure the Syslog server name. You should enable the debug trace message option only when there is little activity in the system. This method avoids putting excessive traffic on the network and lessens the burden on the system. You can send the debug trace messages to the Windows 2000 EventLog, to a local file, to the Syslog server, or to all three. Enter the Syslog server name only when using a syslog daemon other than the CiscoWorks2000 SAC as the Syslog server. Otherwise, leave the Syslog server name blank, and it will default to the local host name.

CiscoWorks2000 Voice Management Features

CiscoWorks2000 is a suite of products for network management, inventory control, analysis, and debugging. The Common Management Framework (CMF) in CiscoWorks2000 is a web-based application with various plug-in application suites that provide certain management feature sets.

Each application suite in the common web-based interface takes advantage of a common database. CiscoWorks2000 can run on either Windows NT or a Sun Solaris platform. Table 35-2 describes the respective components needed to complete the product suite for Cisco AVVID network management.

Table 35-2 Components of CiscoWorks2000 Product Suite

CiscoWorks2000 Components
Description and Function

Common Management Framework Release 1.1.1
(CD-ROM One, edition 3)

Serves as baseline web application for all components, single GUI manager for other CiscoWorks2000 components, and central database. This component is part of the LAN Management Solution (LMS) bundle.

Campus Manager Release 3.0.1 P1
(included with Voice update)

Provides various functionality such as discovery and topology map, central point for host management (console), user tracking, and path analysis.

Resource Manager Essentials Release 3.2
(included with Voice update)

Maintains the managed device inventory, configuration management, and system logging repository and analysis.

As mentioned, the CiscoWorks2000 architecture consists of a Common Management Framework (CMF) with a web-based desktop as a single point of management. An additional component, the asynchronous network interface (ANI), provides data collection services using Simple Network Management Protocol (SNMP), Cisco Discovery Protocol (CDP), and Interim Local Management Interface (ILMI) tables. Figure 35-3 illustrates this architecture.

Figure 35-3 CiscoWorks2000 Architecture

Discovery of the network occurs when you provide a seed device, preferably a router or a switch, through which the ANI can discover the network by reading its neighbors' CDP cache tables and SNMP variables, and can build a network topology map accordingly. The CMF also provides granular security, process control, and device information retrieval via SNMP. It uses CDP and the Cisco CallManager Management Information Bases to discover the Cisco CallManagers on the network and to retrieve and store their appropriate data tables.

Campus Manager

The ANI discovery process added the support for voice components of the Cisco AVVID network in Common Management Framework (CMF) Release 1.1.1. This CMF release supports the following voice devices and functions:

Cisco CallManager

Cisco CallManager Release 3.0 (and later) contains the CDP driver, and it supports partial CDP MIB and SNMP. This is the "tell" side of CDP, so it is always an edge device, and it displays as a Cisco CallManager icon in the topology map.

Cisco IOS voice gateways

The voice gateways are discovered in the same way as regular routers.

Cisco IP Phones (models 7960, 7940, and 7910)

Cisco IP Phones contain the "tell" side of the CDP driver, but they do not support SNMP.

VLAN management

This feature provides tools for graphical VLAN configuration and logical topology mapping.

End-station mobility and tracking

This feature provides tools for mobile user and dynamic VLAN tracking and configuration.

Trace path analysis

This feature traces Layer 2 and Layer 3 paths between two devices or end stations using IP address or directory number.

Because there are usually many Cisco IP Phones installed on a network, the ANI must handle the discovery of Cisco IP Phones separately to avoid overcrowding the network topology map. For this reason, CMF Release 1.1.1 ignores the CDP cache entries of the Cisco IP Phones in the neighboring switches and does not create any device objects for them; hence, daisy-chained IP phones are not discovered. The Cisco IP Phones are treated as end user devices and are discovered through User Tracking discovery, as described in the next section.

User Tracking

User Tracking (UT), a service module of the Campus Manager and ANI, specifically discovers end user nodes such as systems, Cisco CallManager hosts, Cisco IP Phones, and non-CDP systems as well. User Tracking performs an initial discovery of all hosts in the topology map and a subsequent discovery to maintain the user tracking table. You can specify a time limit for this subsequent discovery, and the default is 1 hour.

The initial UT discovery performs the following steps to generate a phone table:

1. UT reads the Content Addressable Memory (CAM) and Address Resolution Protocol (ARP) table of the switches and routers that have already been discovered by ANI and recorded in the topology map.

2. Based on information from CAM and ARP queries, UT generates an end-user table with device and port information. If the end user is a Cisco IP Phone, UT performs the following steps:

It reads the phone entry from the CCM hosts, using the management information base CISCO-CCM-MIB.

It generates a phone table that corresponds to values.

For older models of Cisco IP Phones (Cisco IP Phone models 12 SP+ and 30 VIP), UT uses the CCM-MIB to query Cisco CallManager, and it builds the phone table based on the device and port information gathered from the initial discovery.

Note For non-Cisco IP phones, query is made to Cisco CallManager via SNMP, and the returned information is cross-referenced with information obtained from standard queries made to switches to get MAC addresses and switch ports (query of CAM table) and from queries made to routers to map IP addresses to MAC addresses (query of ARP cache).

Trace Path Analysis

The Path Analysis tool, a part of the Campus Manager, traces IP connectivity between any managed devices in the network. The end points of the trace must be a managed device or end-user node in UT because there is a heavy reliance on accurate information for the trace to be performed. The trace displays end-to-end Layer 3 (IP) paths and, in some instances, the Layer 2 devices within the Layer 3 path. The Path Analysis tool offers two types of traces, data and voice. This chapter discusses only the voice trace.

A voice trace is performed using the call detail records (CDRs), and it also displays the IP path of the trace in case there is a need to discover the state of the network between two phones or between a phone and Cisco CallManager. The data path map can also display a reverse path, which is used if there is congruency in the Layer 3 IP routing paths. The non-CDR voice trace also performs a source-routed trace using the same IP precedence value as a voice call (RTP only). This trace is used if voice follows a different path than data and if it can take advantage of, or detect any problems with, any QoS that has been provisioned for voice.

The CDR-based voice trace can accept three values for a trace: time period to match the call, calling number, and called number. Matching of the data occurs with the right-most digits entered. The path analysis tools search the CDRs of all the managed Cisco CallManager hosts in the database, and matched records are returned. The tools can display and examine the records with best-effort suggestions for possible causes of a problem and corrective actions.

Figure 35-4 shows an example trace path analysis, with Layer 2 and Layer 3 devices displayed.

Figure 35-4 Example Trace Path Analysis

Resource Manager Essentials

The CiscoWorks2000 LAN management solution is also bundled with the Resource Manager Essentials (RME), which are primarily responsible for inventory control, system configuration repository and configuration management, syslog server and syslog analysis, and other reporting functions. RME Release  3.1 is the minimum release that supports detailed reporting capabilities and manageability for Cisco CallManager hosts that are imported.

System logging capabilities of Cisco CallManager, described in the "System Logging Components" section, are well integrated with CiscoWorks2000. RME serves as a single point of management for Syslog Collector message filter configuration and device detail reporting for Cisco CallManager and other Cisco managed devices.

Inventory Control and Reporting

Cisco CallManager is supported in RME in the same manner as any Cisco device. The MIBs supported by Cisco CallManager are accessible through a standard SNMP agent. RME identifies the Cisco CallManager via the Compaq sysObjectID, so it is imperative to avoid exporting a similar system that is not running Cisco CallManager; otherwise, RME will waste resources by periodically collecting configuration information from the non-CallManager system.

RME also creates a separate group in the device selector (a new system view named "Cisco CallManagers") once it detects that Cisco CallManager hosts have been imported for inventory and reporting management. Reports exposed for the device selector are intended to show data about the configuration and state of Cisco CallManager itself, and they do not report on information regarding the individual components configured on Cisco CallManager. Figure 35-5 shows an example device report from RME.

Figure 35-5 Example Device Report from RME

RME also supports report of Multi-Service Port Report (MSP). Essentially, RME evaluates, and the MSP report displays, all the managed Catalyst 4000 and 6000 switches that have inline power modules installed as well as their available ports for IP phone deployment.

System Logging Management

The server side (RME) of CiscoWorks2000 provides a web-based administrative interface to display the Syslog report from all of the devices in the managed network. There are two types of Syslog reports:

Standard Report

Unexpected Device Report

Any devices that support MIB II SNMP variables can be added to the device list of the CiscoWorks2000 configuration, and they are considered as managed devices. The Syslog messages from these managed devices are collected in the Syslog Standard Report. On the other hand, the Syslog messages from the unmanaged devices all go to the Unexpected Device Report. Figure 35-6 shows the administrative user interface for the Standard Report.

Figure 35-6 Standard Report in CiscoWorks2000

You can also use the administrative interface of CiscoWorks2000 to define custom reports such as user URL, automated action, and message filters (as shown in Figure 35-7). These features of the Syslog Analyzer and the administrative interface were updated in RME Release 3.1 to support Cisco CallManager and its suite of voice applications.

Syslog Message Filtering

In addition to System Diagnostic Interface (SDI) filtering, there are two places in the Syslog Analyzer where you can perform message filtering:

In the Syslog Analyzer Collector (SAC) process, before the message is sent to the network

In the CiscoWorks2000 server, where the administrator can define a custom report

Note If you set the Syslog filters on the CiscoWorks2000 server, all defined Syslog messages are sent to the server, thus creating erroneous network traffic. Cisco recommends that you use the SAC to create filters prior to sending them to a Syslog server.

The filtering mechanism allows you to define filters that are based on the source, the facility code, the subfacility codes, severity levels, mnemonic codes, or patterns in the message. Figure 35-7 shows an example of defining a message filter in the CiscoWorks2000 administrative interface.

Figure 35-7 Message Filter Defined for a Remote SAC


The Syslog Analyzer in CiscoWorks2000 has a web-based administrative interface to define an automatic action for a set of events or Syslog messages from particular devices. In future releases of CiscoWorks2000, this feature will be enhanced further to generate alarms or traps. Currently, the Syslog Analyzer can be used for event notification via either writing to a log file or generating an e-mail message. Cisco recommends that you configure the appropriate e-mail destination, whether that be to some e-mail receiver that can generate a page or to some Network Operation Center (NOC) alert e-mail alias. From an operational perspective, there would be a clear advantage to having event notification e-mails sent to an e-mail capable pager or cellular phone.

Call Detail Records

When CDR collection is enabled, Cisco CallManager writes call detail records (CDRs) to the SQL database as calls are made. CDR collection is enabled and configured through service parameters that are set in Cisco CallManager Administration. You must enable CDR collection on each Cisco CallManager in the cluster for which you want to generate records (see the "CDR-Related Service Parameters" section

All CDR records are written to the local database on each Cisco CallManager and then moved from the local database to the publisher database for the cluster in a low priority thread at 1-minute intervals.

If the local database is not available, then they are written to any of the other subscriber databases in the cluster. When the local database becomes available, the writing of new records resumes on the local database.

Enabling CDR Collection

CDR collection is enabled through a Cisco CallManager service parameter named CdrEnabled. To enable CDR collection:

1. Open Cisco CallManager Administration.

2. Select Service > Service Parameters.

3. Click on the Cisco CallManager server on which you wish to enable CDR collection.

4. Select Cisco CallManager from the list of configured services.

5. Select CdrEnabled from the list of service parameters.

6. Choose T (true, CDRs enabled) or F (false, CDRs disabled) from the Value drop-down list box.

7. Repeat this procedure on each Cisco CallManager in the cluster. You do not need to restart the CallManager for the change to take effect.

CDR-Related Service Parameters

The following tunable service parameters apply to CDRs:

MaxCdrRecords—Cisco TFTP service parameter that controls the maximum number of CDRs on the system. When this limit is exceeded, the oldest CDRs are automatically removed, along with the related CMR records, once a day. The default is 1.5 million records.

CdrEnabled—Cisco CallManager service parameter that controls whether or not CDRs are generated.

CdrLogCallsWithZeroDurationFlag—Cisco CallManager service parameter controls whether calls with zero duration are logged in CDRs. The default is False (zero duration calls not logged).

Removing CDR Records

The CallManager application relies on post-processing applications such as ART or other 3rd-party packages to analyze CDR data. The removal of the CDR data should be done by the administrator when all post-processing applications are through with the data. Because this involves modifying the database, the SQL user CiscoCCMCDR should be used.

If CDR records accumulate to a configured maximum (as set by the MaxCdrRecords service parameter, which defaults to 1.5 million records), then the oldest CDR records are removed along with related CMR records once a day.

When removing CDR data after analysis, be sure to remove all related CMR records also.

Tips It is best to remove CDR and CMR records often instead of once a day or week in a large system. Queries to remove records can consume CPU time and transaction log space relative to the size of the table. The smaller the table, the quicker the query. Large queries on a live database can adversely affect call processing.

CDR Database Access

The easiest way to read data from the SQL database is to use ODBC. A good connection string would look like one of the following examples depending on whether you need to get to the configuration data or CDRs:



Be sure to use the correct database name. Previous versions of the product had the CDR tables in the CCM0300 database. The tables have been moved to the CDR database. Also, you will need access to both the configuration database and CDR database to properly resolve the CDR information.

The machine that is the central collector of the CDR information is the machine serving the primary CCM0300 database. To determine the publisher database (machine and name) currently in use by the cluster

1. Choose Help > About Cisco CallManager.

2. Click the Details button.

The Database field in the Database Information area displays the name of the Cisco CallManager server that is the publisher database for the cluster.

Access to CDR records is controlled through SQL Users. Table 35-3 specifies the UserID and password that should be used when accessing the Cisco CallManager database.

Table 35-3 SQL Users for CDR Access

SQl UserID


CallDetailRecord, CallDetailRecordDiagnostic



Read/write access to CDR

Read access to CCM0300





Read only

Where to Find More Information

Related Topics

Cisco TFTP

Understanding Cisco WebAttendant

Understanding Voice Gateways

Cisco IP Phones

Call Admission Control

System Configuration Checklist

Additional Cisco Documentation

Device Defaults Configuration, Cisco CallManager Administration Guide

Device Pool Configuration, Cisco CallManager Administration Guide

Gateway Configuration, Cisco CallManager Administration Guide

Cisco IP Phone Configuration, Cisco CallManager Administration Guide

Cisco CallManager Group Configuration, Cisco CallManager Administration Guide

Cisco JTAPI Installation and Configuration, Cisco CallManager Administration Guide

Bulk Administration Tool Guide for Cisco CallManager

Administrative Reporting Tool Guide for Cisco CallManager