Cisco Unified Communications Manager Managed Services Guide, Release 7.1
New and Changed Information
Downloads: This chapterpdf (PDF - 573.0KB) The complete bookPDF (PDF - 15.73MB) | Feedback

New and Changed Information

Table Of Contents

New and Changed Information

Cisco Unified Communications Manager Release 7.1

Cisco Unified Serviceability

IPv6 and Address Space

Service Manager Enhancements

Cisco Audit Event Service

New Audit Log CLI Commands

Logical Partitioning

Standard Audit Log

Table Out of Sync Detection

Unconfigured Device Registration Attempts Restricted

Always Use Prime Line and Voice Message

New Cisco Unified Serviceability Alarm Definition Catalogs

New Cisco Unified Serviceability Alarms

Cisco Unified Cisco Unified Real-Time Monitoring Tool

IPv6 Addressing and RTMT

Centralized Audit Logging and Security for Linux

Quality Report Tool Reports

System History Log

Cisco Unified Communications Manager CDR Analysis and Reporting

Customized Logon Message

Upgrade of CAR Data

Backup of CAR Data

FTP/SFTP Billing Servers

CAR Administrator Privileges Restored After Upgrade

Cisco Unified Communications Manager Call Detail Records

IPv6 and New CDR Fields

Video Channels and CDRs

New Call Termination Cause Codes

SIP Calls with URL in callingPartyNumber Field

GlobalCallId Survives Over Cisco Unified Communications Manager Restarts

Cisco Unified Reporting

Documentation Updates

New Fields in CISCO-CCM-MIB

Cisco Unified Communications Manager Release 7.0(x)

Cisco Unified Communications Manager Release 7.0(2)

Resolved Caveats

Important Notes

Cisco Unified Communications Manager Release 7.0(1)

Cisco Unified Serviceability

Cisco Unified Real-Time Monitoring Tool

Cisco Unified Communications Manager CDR Analysis and Reporting

Cisco Unified Communications Manager Call Detail Records

Cisco Unified Reporting

Cisco Unified Communications Manager Release 6.1(x)

Cisco Unified Communications Manager Release 6.1(3)

Cisco Unified Cisco Unified Real-Time Monitoring Tool

Cisco Unified Communications Manager CDR Analysis and Reporting

Cisco Unified Communications Manager Call Detail Records

Cisco Unified Communications Manager Release 6.1(2)

Cisco Unified Serviceability

Cisco Unified Communications Real-Time Monitoring Tool

Cisco Unified Communications Manager Release 6.1(1a)

CDR Analysis and Reporting Tool/Call Detail Record (CAR/CDR)

Cisco Unified Communciations Manager Release 6.1(1b)

Cisco Unified Communications Manager Release 6.0(1x)

Cisco Unified Communications Manager Release 6.0(1)

No Such Name Error in SNMP Response

Maximum Trace Settings

Terminal Server Causes RTMT to Display Repeating Syslog and Alert Messages

Secure Conferencing and CRD Data

Cisco Unified Serviceability

Cisco Unified Communications Real-Time Monitoring Tool

Cisco Unified Communications Manager CDR Analysis and Reporting

Cisco Unified Communications Manager Release 6.0(1a)

CSCsi75567 MCS-7825H2-IPC1 Reboots Randomly

Cisco Unified Communications Manager Release 6.0(1b)

Resolved Caveats


New and Changed Information


This chapter describes new and changed information in Cisco Unified Communications Manager (Cisco Unified CM) from release to release beginning with Release 6.x. It contains the following sections:

Cisco Unified Communications Manager Release 7.1

Cisco Unified Communications Manager Release 7.0(x)

Cisco Unified Communications Manager Release 6.1(x)

Cisco Unified Communications Manager Release 6.0(1x)

For complete release note information, refer to this index for your Cisco Unified CM release:

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_release_notes_list.html.

Cisco Unified Communications Manager Release 7.1

This section describes the new and changed information in Cisco Unified Communications Manager Release 7.1. It contains the following subsections:

Cisco Unified Serviceability

Cisco Unified Cisco Unified Real-Time Monitoring Tool

Cisco Unified Communications Manager CDR Analysis and Reporting

Cisco Unified Communications Manager Call Detail Records

Cisco Unified Reporting

Documentation Updates

New Fields in CISCO-CCM-MIB

Cisco Unified Serviceability

This section contains the following subsections:

IPv6 and Address Space

Service Manager Enhancements

Cisco Audit Event Service

New Audit Log CLI Commands

Logical Partitioning

Standard Audit Log

Table Out of Sync Detection

Unconfigured Device Registration Attempts Restricted

Always Use Prime Line and Voice Message

New Cisco Unified Serviceability Alarm Definition Catalogs

New Cisco Unified Serviceability Alarms

IPv6 and Address Space

IPv6 is the latest version of IP that uses packets to exchange data, voice, and video traffic over digital networks and that increases the number of network address bits from 32 bits in IPv4 to 128 bits. IPv6 support in the Cisco Unified Communications Manager network enables the network to transparently perform tasks in a dual-stack environment and provides additional IP address space and autoconfiguration capabilities to devices that are connected to the network.

Before you configure IPv6, review the "Internet Protocol Version 6 (IPv6)" chapter in the Cisco Unified Communications Manager Features and Services Guide carefully. Specifically review how to configure IPv6 the Cisco Unified Communications Manager server and phones in dual-stack mode and how Cisco Unified Communications Manager uses MTPs to translate IPv4 to IPv6 or vice versa.

SNMP supports IPv4, and the CISCO-CCM-MIB includes columns and storage for IPv6 addresses and preferences. IPv6 impacts the Cisco CallManager, CTIManager, and Certificate Authority Proxy Function services in Cisco Unified Serviceability. See "CISCO-CCM-MIB" section and the Cisco Unified Serviceability Administration Guide for more information.

Service Manager Enhancements

This release includes two new service states: Starting and Stopping. When the service state is stopping, a service cannot start. When a service state is starting, a service cannot stop. These states display in the Service Activation window in Cisco Unified Serviceability and in the command line interface (CLI).

This release also includes the following performance enhancements:

ServM can respond to 60 requests per minutes.

Blocking mode does not block a ServM script.

ServM responds within tens of milliseconds to any request to handle a single service.

ServM responds within hundreds of milliseconds to any request to handle all services.

ServM writes fewer logs per day. In idle state, it writes approximately 37 logs per day.

ServM maintains a single session with the Tomcat manager webapp.

ServM sends three requests to the Tomcat server under idle conditions.

ServM handles blocking in the request processing thread, which makes ServM available to most clients that request the service.

Common webapp health timer, which helps to improve system performance and allows reducing the number of requests that are sent to ServM.

Service Manager listens to port 8889 at the local host

Service Manager does not accept raw XML data

ServM resists to DOS attacks.

The Disaster Recovery Framework (DRF) backs up the services.conf and servM.conf files. The restore process restores all services to their original forms.

Table 1 describes new Service Manager return codes.

Table 1 New Service Manager Return Codes 

Code
Meaning

1078

Service start pending

1079

Service stop pending

1080

HTTP timed out

1081

Tomcat webapp deploy failed

1082

Invalid Tomcat application URL

1083

No such Tomcat command specified

1084

Tomcat webapp undeploy failed

1085

No such Tomcat manager user failed

1086

Tomcat manager failed to reload

1087

Tomcat manager failed

1088

Webapp start failed

1089

Unknown Tomcat command

1090

Connection refused


Cisco Audit Event Service

The Cisco Audit Event Service, which was added to the Control Center Network GUI in Cisco Unified Serviceability, starts or stops the Audit Log service. Only a user with an audit role has permission to change the Audit Log settings.

By default, CCMAdministrator takes the audit role after fresh installs and upgrades. This role can assign the "standard audit users" group to any new user that the administrator specifically creates for audit purposes. The CCMAdministrator role can then get removed from the audit user group.

The "standard audit log configuration" role provides the ability to delete audit logs, read/update access to Cisco Unified Real-Time Monitoring Tool, Trace Collection Tool, RTMT Alert Configuration, the Control Center - Network Services window, RTMT Profile Saving, the Audit Configuration window, and a new resource called Audit Traces.

New Audit Log CLI Commands

The following new audit log CLI commands are added. For more information about command syntax and parameters, see the Command Line Interface Reference Guide for Cisco Unified Solutions.

utils auditd {enable | disable | status}—Enables, disables, and provides the status of audit logging. When audit logging is enabled, the system monitors and records user actions in both Cisco Unified Communications Manager and Cisco Unified Serviceability.

file list activelog audit—Lists the audit logs.

file view activelog audit <filename>—Displays the active audit logs.

file dump activelog audit <filename>—Dumps the active audit logs.

file get activelog audit <filename>—Gets the active audit logs.

file search activelog audit <filename>—Searches for the active audit logs.

Logical Partitioning

The following serviceability consideration exists for the logical partitioning feature:

The Cisco Call Restriction counters specify a new group of performance monitoring counters that log the number of failures that result because of logical partitioning policy restrictions. The Cisco Call Restriction counters include the following performance monitoring counters:

AdHocConferenceFailures

BasicCallFailures

ForwardingFailures

LogicalPartitionFailuresTotal

MeetMeConferenceFailures

MidCallFailures

ParkRetrievalFailures

PickUpFailures

SharedLineFailures

TransferFailures

See the "Performance Monitoring in RTMT" section for details. For CAR/CDR and to support logical partitioning, call termination cause codes are added.

For details on CDR codes and codecs, refer to the "Cisco Call Detail Records Codes" chapter of the Cisco Unified Communications Manager Call Detail Records Administration Guide. The "CDR Examples" chapter provides examples of CDRs that are added to support the logical partitioning feature.

For more information on this feature, refer to the Cisco Unified Communications Manager Administration Guide.

Standard Audit Log

The Standard Audit Log can be configured in Cisco Unified Serviceability to read or update the Resource Access Information. The following resources are configurable:

Alarm Configuration web page

Alarm Definition web page

Audit Configuration

Audit Trace

CDR Management

Control Center - Feature Services web page

Control Center - Network Services web page

Log Partition Monitoring->Configuration web page

RTMT->Alert Config

RTMT->Profile Saving

Real Time Monitoring Tool

SNMP->V1/V2c->Configuration->Community String web page

SNMP->V1/V2c->Configuration->Notification Destination web page

SNMP->V3 Configuration->Notification Destination web page

SNMP->V3 Configuration->User web page

SNMP->system Group Configuration->MIB2 System Group Configuration web page

SOAP Backup and Restore APIs

SOAP CDR on Demand APIs

SOAP Control Center APIs

SOAP Log Collection APIs

SOAP Performance Informations APIs

SOAP Realtime Informations and Control Center APIs

SOAP SNMP Config API

Service Activation web page

Serviceability Report Archive

Trace Collection Tool

Trace Configuration web page

Troubleshoot Trace Settings web page

Table Out of Sync Detection

When the Table Out Of Sync parameter is turned on, the Database Replication Status summary gets collected every day during the maintenance window. The system compares the output of three consecutive days to determine whether the tables have been out of sync for all three days. If so, it triggers an alert. Enable the Alert in Cisco Unified Serviceability. To configure the Alert in RTMT, refer to the Setting Alert Properties in the Cisco Unified Real-time Monitoring Tool Guide. Cisco recommends that you call TAC if this alert gets generated.

Unconfigured Device Registration Attempts Restricted

Prior to Cisco Unified Communications Manager 6.1(3) and 7.1 (not 7.0(1)), if a Cisco Unified IP Phone had not been added to the Cisco Unified Communications Manager database and did not have auto-registration enabled, the phone would repeatedly attempt to register (unsuccessfully) with Cisco Unified Communications Manager.

In Cisco Unified Communications Manager 6.1(3) or 7.1, if auto-registration is disabled and the phone has not been added to the Cisco Unified Communications Manager database, the phone does not attempt to register with Cisco Unified Communications Manager. The phone continues to display the Configuring IP message until auto-registration gets enabled or until the phone gets added to the Cisco Unified Communications Manager database.

The Cisco RTMT and Cisco Unified Reporting display information on registered and unregistered devices. For more information, refer to the Cisco Unified Real-Time Monitoring Tool Administration Guide and the Cisco Unified Reporting Administration Guide.

Always Use Prime Line and Voice Message

The Always Use Prime Line feature relies on a Cisco CallManager service. After the feature is enabled, you can run SDI trace for the Cisco CallManager service. When you view the log in RTMT, you can see the device configured value; for example, alwaysPrimeLine=1, which indicates that the device uses On for the configuration.

The Always Use Prime Line for Voice Message feature relies on a Cisco CallManager service. After the feature is enabled, you can run SDI trace for the Cisco CallManager service. When you view the log in RTMT, you can see the device configured value; for example, alwaysUsePrimeLineForVM=2, which indicates that the device uses the default.

In previous releases of Cisco Unified Communications Manager, except Release 6.1(3), you configured the Always Use Prime Line and Always Use Prime Line for Voice Message service parameters that applied to the entire cluster. In Cisco Unified Communications Manager 6.1(3) and 7.1, you can configure both services for specific devices and device profiles.

New Cisco Unified Serviceability Alarm Definition Catalogs

The following catalogs have been added to Cisco Unified Serviceability:

System Alarm Catalog—CDPAlarmCatalog

CallManager Alarm Catalog—Phone

New Cisco Unified Serviceability Alarms

DUPLEX_MISMATCH—This alarm is generated by Cisco CDP whenever there is a duplex mismatch between local and switch interfaces. See "DUPLEX_MISMATCH" section for more information.

DeviceImageDownloadFailure—Cisco IP Phone failed to download its image. See "DeviceImageDownloadFailure" section for more information.

DeviceImageDownloadStart—Cisco IP Phone has started downloading its image. See "DeviceImageDownloadStart" section for more information.

DeviceImageDownloadSuccess—Cisco IP Phone has successfully downloaded its image. See "DeviceImageDownloadSuccess" section for more information.

DeviceApplyConfigResult—Cisco IP Phone has applied its configuration. See "DeviceApplyConfigResult" section for more information.

Cisco Unified Cisco Unified Real-Time Monitoring Tool

This section contains these subsections:

IPv6 Addressing and RTMT

Centralized Audit Logging and Security for Linux

Quality Report Tool Reports

System History Log

IPv6 Addressing and RTMT

In RTMT, you can monitor CTI applications, CTI devices, and CTI lines that use IPv6 addresses. When you search for the application, device, or line, enter the IPv6 address, and check the AppIpv6Addr check box in the attribute window or in the case of phones and SIP Trunks, check the Ipv6Address check box in the attributes window. Log files display IPv4 and IPv6 addresses depending on the configuration in your network.

Table 2-2 lists and describes the PerfMon counters that provide IPv6 statistics for your system.

Table 2-2 IPv6 PerfMon Counters 

Counters
Descriptions

Frag Creates

Number of IP datagrams fragments that have been generated as a result of fragmentation at this entity.

Frag Fails

Number of IP datagrams that have been discarded because they needed to be fragmented at this entity but could not, for example because their Do not Fragment flag was set.

Frag OKs

Number of IP datagrams that have been successfully fragmented at this entity.

In Delivers

Total number of input datagrams that were successfully delivered to IP user-protocols including Internet Control Message Protocol (ICMP).

In Discards

Number of input IP datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (for example, for lack of buffer space). This counter does not include any datagrams that were discarded while awaiting reassembly.

In HdrErrors

Number of input datagrams that were discarded due to errors in their IP header, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IP options, and so on.

In Receives

Number of input datagrams received from all network interfaces, including those received with errors.

In UnknownProtos

Number of locally addressed datagrams that were received successfully but discarded because of an unknown or unsupported protocol.

InOut Requests

Total number of IP datagrams that were received and the number of IP datagrams sent.

Out Discards

Number of output IP datagrams that were not transmitted and were discarded. One reason may be a lack of buffer space.

Out Requests

Total number of IP datagrams that local IP user-protocols (including Internet Control Message Protocol [ICMP]) supply to IP in requests transmission. This counter does not include any datagrams that are counted in ForwDatagrams.

Reasm Fails

Number of failures that were detected by the IP reassembly algorithm (for various reasons, for example timed out, errors, and so on). This does not necessarily comprise a count of discarded IP fragments because some algorithms, notably the algorithm in RFC 815, can lose track of the number of fragments by combining them as they are received.

Reasm OKs

Number of IP datagrams that have been successfully reassembled.

Reasm Reqds

Number of IP fragments received which needed to be reassembled at this entity.


Centralized Audit Logging and Security for Linux

Centralized audit logging reports any configuration change to the Cisco Unified Communications Manager system and creates log files. In addition to centralized audit logging, there are security features. The events occur in Cisco Unified Serviceability and the following events are logged:

Activation, deactivation, start, or stop of a service from any serviceability window.

Changes in trace configurations and alarm configurations.

Changes in SNMP configurations.

Changes in CDR Management.

Review of any report in the Serviceability Reports Archive. This log gets viewed on the reporter node.

Cisco Unified RTMT logs the following events with an audit event alarm:

Alert configuration.

Alert suspension.

E-mail configuration.

Set node alert status.

Alert addition.

Add alert action.

Clear alert.

Enable alert.

Remove alert action.

Remove alert.

All audit logs get collected, viewed, and deleted from Trace and Log Central in the Cisco Unified RTMT. and the Log Partition Monitor (LPM) manages the purging of these audit logs as needed.

By default, the LPM purges the audit logs, but the user can change this setting from the Audit User Configuration window in Cisco Unified Serviceability. The LPM sends an alert whenever the common partition disk usage exceeds the threshold; however, the alert does not have the information about whether the disk is full because of audit logs or trace files.

Quality Report Tool Reports

A change occurred in the Call State information that is collected from Cisco Unified Communications Manager/CTIManager and displayed in the Quality Report Tool (QRT) reports. Previously, the information included Connected, Connected Conference, Connected Transfer, and On Hook call state information. Now, the report only includes Connected and On Hook call state information.

System History Log

The system history log provides a central location for getting a quick overview of the initial system install, system upgrades, Cisco option installations, DRS backups and DRS restores, switch version, and reboot history.

The system history log exists as a simple ASCII file, system-history.log, and the data does not get maintained in the database. Because it does not get excessively large, the system history file does not get rotated. It logs the following information:

Initial software installation on a server.

Success and failure of every software upgrade (Cisco option files and patches).

Every DRS backup and restore performed.

Every invocation of Switch Version issued with the CLI or the GUI.

Every invocation of Restart and Shutdown issued with the CLI or the GUI.

Every boot of the system. If not correlated with a restart or shutdown entry, the boot constitutes the result of a manual reboot, power cycle, or kernel panic.

Maintains a single file that contains the system history, since initial installation or since feature availability.

Exists in the install folder. You can access the log by using the file CLI commands or by using RTMT.

Each system history log entry contains the <timestamp> <userid> <action> <description> <start/result> fields. The fields can contain the following values:

timestamp—Displays the local time and date on the server with the format mm/dd/yyyy hh:mm:ss.

userid—Displays the user name of the user who invokes the action.

action—Displays one of the following actions:

Basic Install

Windows Upgrade

Upgrade During Install

Upgrade

Cisco Option Install

Switch Version

System Restart

Shutdown

Boot

DRS Backup

DRS Restore

description—Displays one of the following messages:

Version: Displays for the Basic Install, Windows Upgrade, Upgrade During Install, Upgrade, and ServerPak Install actions.

Cisco Option file name: Displays for the Cisco Option Install action.

Timestamp: Displays for the DRS Backup and DRS Restore actions.

Active version to inactive version: Displays for the Switch Version action.

Active version: Displays for the System Restart, Shutdown, and Boot actions.

start/result—Displays the following results:

Start

Success or Failure

Cancel

The following example shows a system history log:

admin:file dump install system-history.log
=======================================
Product Name -    Cisco Unified Communications Manager
Product Version - 6.1.2.9901-117
Kernel Image -    2.4.21-47.EL.cs.3BOOT
=======================================
07/25/2008 14:20:06 | root: Install 6.1.2.9901-117 Start 
07/25/2008 15:05:37 | root: Install 6.1.2.9901-117 Success 
07/25/2008 15:05:38 | root: Boot 6.1.2.9901-117 Start 
07/30/2008 10:08:56 | root: Upgrade 6.1.2.9901-126 Start 
07/30/2008 10:46:31 | root: Upgrade 6.1.2.9901-126 Success 
07/30/2008 10:46:43 | root: Switch Version 6.1.2.9901-117 to 6.1.2.9901-126 Start 
07/30/2008 10:48:39 | root: Switch Version 6.1.2.9901-117 to 6.1.2.9901-126 Success 
07/30/2008 10:48:39 | root: Restart 6.1.2.9901-126 Start 
07/30/2008 10:51:27 | root: Boot 6.1.2.9901-126 Start 
08/01/2008 16:29:31 | root: Restart 6.1.2.9901-126 Start 
08/01/2008 16:32:31 | root: Boot 6.1.2.9901-126 Start 
 
   

You can access the system history log by using the following CLI file commands:

file view install system-history.log

file get install system-history.log

Cisco Unified Communications Manager CDR Analysis and Reporting

This section contains these subsections:

Customized Logon Message

Upgrade of CAR Data

Backup of CAR Data

FTP/SFTP Billing Servers

CAR Administrator Privileges Restored After Upgrade

Customized Logon Message

You can upload a text file that contains a customized logon message that displays on the initial Cisco Unified Communications Manager CDR Analysis and Reporting window.

Upgrade of CAR Data

When you upgrade to a later version of Cisco Unified Communications Manager, your CDR data may not be upgraded. The Cisco Unified Communications Manager installation program limits the time period for the migration of the CAR records from the CSV files in the Data Migration Assistant (DMA) TAR file to the CAR database on the upgraded system. The migration time period is 60 minutes.

To allow the migration of the highest number of CSV files in the allotted time period, CAR record migration uses the following process:

Begins with the migration of the billing records from the tbl_billing_data CSV file to the tbl_billing_data table of the CAR database.

Begins with the youngest record and proceeds to the oldest record in the CSV file.

Stops when there are no more billing records to migrate or the migration time period reaches 60 minutes.

Left-over migration time allows data migration of error records from the tbl_billing_error CSV file to the tbl_billing_error table of the CAR database.

Begins with the youngest record and proceeds toward the oldest record in the CSV file.

Stops when there are no more error records to migrate or the migration period reaches 60 minutes.

If the 60-minute migration time limit occurs at any point in the migration process, CAR data migration stops and the tbl_system_preferences of the CAR database get updated to reflect the data present in the upgraded system database.

Backup of CAR Data

The CAR and CDR Disaster Recovery Service (DRS) includes the backup of the CAR database, pregenerated reports, and the CDR preserved flat files. The CAR Web Service and CAR Scheduler automatically stop before the backup and restore process begins and automatically restarts after the backup and restore process completes.

Table 2-3 lists Cisco Unified CM features and components UCM that the DRS can back up and restore. For each feature that you choose, the system backs up all its components automatically.

Table 2-3 Cisco Unified CM Features and Components

Feature
Components

CCM—Cisco Unified Communications Manager

Cisco Unified Communications Manager database

Platform

Serviceability

Music On Hold (MOH)

Cisco Emergency Responder

Bulk Tool (BAT)

Preference

Phone device files (TFTP)

syslogagt (SNMP syslog agent)

cdpagent (SNMP cdp agent)

tct (trace collection tool)

Call Detail Records (CDRs)

CDR Reporting and Analysis (CAR)


FTP/SFTP Billing Servers

Cisco allows you to use any SFTP server product but recommends SFTP products that have been certified with Cisco through the Cisco Technology Developer Partner program (CTDP). CTDP partners, such as GlobalSCAPE, certify their products with specified version of Cisco Unified Communications Manager. For information on which vendors have certified their products with your version of Cisco Unified Communications Manager, refer to the following URL:

http://www.cisco.com/pcgi-bin/ctdp/Search.pl

For information on using GlobalSCAPE with supported Cisco Unified Communications versions, refer to the following URL:

http://www.globalscape.com/gsftps/cisco.aspx

Cisco uses the following servers for internal testing. You may use one of the servers, but you must contact the vendor for support:

Open SSH (refer to http://sshwindows.sourceforge.net/)

Cygwin (refer to http://www.cygwin.com/)

Titan (refer to http://www.titanftp.com/)


Note For issues with third-party products that have not been certified through the CTDP process, contact the third-party vendor for support


Cisco has tested and supports the following versions of FTP or SFTP for CAR billing servers:

Linux/Unix

FTP: Unix (SunOS 5.6 Generic_105181-10) and Linux server (2.4.21-47.ELsmp and 2.6.9-42.7.ELsmp)

SFTP: Unix (SunOS 5.6 Generic_105181-10) and Linux server (2.4.21-47.ELsmp and 2.6.9-42.7.ELsmp)

Windows

FTP: Microsoft FTP service (Windows 2000 5.00.2195 sp4, IIS 5.0), WAR FTP Daemon (1.82.0.10), and FreeFTPd (1.0.10 and 1.0.11). Use FreeFTPd only for files that are less than 1 GB in size.

SFTP: FreeFTPd (1.0.10 and 1.0.11). Use Free FTPd only for files that are less than 1 GB in size.

CAR Administrator Privileges Restored After Upgrade

When you use DMA to upgrade Cisco Unified Communications Manager, CAR users no longer have CAR administrator privileges after the upgrade and become standard end users. You must reset the CAR administrator privileges after the upgrade. Refer to the "Configuring CAR Administrators, Managers, and Users" chapter in the CDR Analysis and Reporting Administration Guide for more information on how to configure CAR administrators.

Cisco Unified Communications Manager Call Detail Records

This section contains these subsections:

IPv6 and New CDR Fields

Video Channels and CDRs

New Call Termination Cause Codes

SIP Calls with URL in callingPartyNumber Field

GlobalCallId Survives Over Cisco Unified Communications Manager Restarts

IPv6 and New CDR Fields

Cisco Unified Communications Manager supports IPv6 in this release. Table 2-4 describes two new CDR fields.

Table 2-4 IPv6 CDR Field Descriptions 

Field Name
Range of Values
Description

origIpv4v6Addr

Text string

Enables an alphanumeric string of up to 64 characters and identifies the IP address of the originating device. The field can be either IPv4 or IPv6 format. The IP address is either in dotted decimal format or in colon separated hexadecimal format.

For Cisco Unified IP Phones, this field is the address of the Cisco Unified IP Phone. For PSTN calls, this field is the address of the gateway. For intercluster calls, this field is the address of the remote Cisco Unified Communications Manager.

The default is the IP address of the originating device as reported by the device or used for the call after media negotiation.

destIpv4v6Addr

Text string

Enables an alphanumeric string of up to 64 characters. It identifies the IP address of the destination device. The field can be either in IPv4 or IPv6 format. The IP address is either in dotted decimal format or in colon separated hexadecimal format.

For Cisco Unified IP Phones, this field is the address of the Cisco Unified IP Phone. For PSTN calls, this field is the address of the gateway. For intercluster calls, this field is the address of the remote Cisco Unified Communications Manager.

The default is an empty string " " or null. If the destination does not get reached, this field stays empty.


Video Channels and CDRs

There are new CDR fields that support a second video channel for both the origination and destination devices. Table 2-5 describes the new fields.

Table 2-5 New CDR Field Descriptions for Video Channels 

Field Name
Range of Values
Description 1

origVideoCap_Codec_Channel2

0,

100 = H.261,

101 = H.263,

102 = Vieo,

103 = H.264

Identifies the codec type that the originator uses to transmit video (H.261, H.263, Vieo, H.264) for the second video channel.

origVideoCap_Bandwidth_Channel2

0, Positive integer

Identifies the bandwidth that is measured in units of kbs for the second video channel.

origVideoCap_Resolution_Channel2

0,

1 = SQCIF,

2 = QCIF,

3 = CIF,

4 = CIF4,

5 = CIF16

Identifies the video resolution for the second video channel.

origVideoTransportAddress_IP_Channel2

0, Integer

Identifies the v4 IP address of the device that originates the call for the second video channel.

origVideoTransportAddress_Port_Channel2

0, Positive integer

Identifies the video RTP port that is associated with the origH239VideoTransportAddress_IP field for the second video channel.

origVideoChannel_Role_Channel2

0 = Presentation role,

1 = Live role,

Positive integer

Identifies the H.239 video channel role of the device that originates.

destVideoCap_Codec_Channel2

0,

100 = H.261

101 = H.263

102 = Vieo

103 = H.265

Identifies the codec type that the terminating party uses to transmit video for the second video channel (H.261, H.263, Vieo, H.264).

destVideoCap_Bandwidth_Channel2

0, Positive integer

Identifies the bandwidth that is measured in units of kbs for the second video channel.

destVideoCap_Resolution_Channel2

0,

1 = SQCIF,

2 = QCIF,

3 = CIF,

4 = CIF4,

5 = CIF16

Identifies the video resolution for the second video channel.

destVideoTransportAddress_IP_Channel2

0, Integer

Identifies the IPv4 address of the device that receives the call.

destVideoTransportAddress_Port_Channel2

0, Positive integer

Identifies the video RTP port that is associated with the destH239VideoTransportAddress_IP field.

destVideoChannel_Role_Channel2

0 = Presentation role,

1 = Live role,

Positive integer

Identifies the H.239 video channel role of the device that receives the call.

1 The default is zero (0). If media does not get established, this field displays 0 and if H.239 is not supported, this field displays 0.


New Call Termination Cause Codes

Table 2-6 lists and describes new Cisco call termination cause codes that support logical partitioning.

Table 2-6 Cisco Specific Call Termination Cause Codes 

Decimal Value Code
Hex Value Code
Description

419430421

0x19000015

CCM_SIP_424_BAD_LOCATION_INFO

-1493172161

0xA700003F

CCM_SIP_503_SERVICE_UNAVAILABLE_SER_OPTION_
NOAVAIL


SIP Calls with URL in callingPartyNumber Field

A new CDR example exists for an incoming call received through a SIP trunk by the Cisco Unified Communications Manager. The call contains a SIP URL for the callingPartyNumber CDR field.

GlobalCallId Survives Over Cisco Unified Communications Manager Restarts

In Release 4.x and earlier releases, the GlobalCallId field was time-based, so the field got reused under conditions of heavy traffic. Because of this behavior, problems occurred with customer billing applications and the ability of CAR to correlate CMRs with CDRs and to correlate conference call CDRs.

For Cisco Unified Communications Manager Release 5.x and later releases, the value in the GlobalCallId CDR field survives over Cisco Unified Communications Manager restarts because it retains a unique value for a certain number of days. The last used globalCallId_callId value gets written to disk periodically (for every x number of calls). The value gets retrieved after a Cisco Unified Communications Manager restart, and the new globalCallId_callId value begins with this number plus x.

Cisco Unified Reporting

For a complete description of reports that are available on your system and the data that gets captured in a report, access Report Descriptions. Table 2-7 describes the new standard reports.

Table 2-7 New Standard Reports in Cisco Unified Reporting 

Report
Description

Cisco Unified CM GeoLocation Policy

Provides a list of records from the GeoLocation Logical Partitioning Policy Matrix.

Cisco Unified CM GeoLocation Policy with Filter

Provides a list of records from the GeoLocation Logical Partitioning Policy Matrix for the selected GeoLocation policy.

Cisco Unified CM Phone Feature List

Provides a list of supported features for each device type in Cisco Unified Communications Manager Administration.

Cisco Unified CM Phones With Mismatched Load

Provides a list of all phones that have mismatched firmware load.


Documentation Updates

In the Cisco Unified Communications Manager CDR Analysis and Reporting Administration Guide, the configuration for the Department Bills Users Reports, the following note was added to Step 6 of the Configuring Department Bills Reports procedure:


Note Click the Down radio button to view your direct reports. Use the Up and Down radio buttons to move up and down the report chain.


New Fields in CISCO-CCM-MIB

In the CISCO-CCM-MIB, the CTI InetAddress ccmCTIDeviceInetAddressType and ccmCTIDeviceInetAddress fields are deprecated.

There are two new IPv4/IPv6 fields added to the ccmCTIDeviceTable to improve the SNMP query performance when there are a huge number of entries in the table. The new fields are ccmCTIDeviceInetAddressIPv4 and ccmCTIDeviceInetAddressIPv6 .The definitions are as follows:

ccmCTIDeviceInetAddressIPv4 OBJECT-TYPE

SYNTAX InetAddressIPv4

MAX-ACCESS read-only

STATUS current

DESCRIPTION—This object identifies the last known primary IPv4 address of the CTI device. This object contains value zero if IPV4 address is not available.

::= { ccmCTIDeviceEntry 14 }

ccmCTIDeviceInetAddressIPv6 OBJECT-TYPE

SYNTAX InetAddressIPv6

MAX-ACCESS read-only

STATUS current

DESCRIPTION—This object identifies the last known primary IPv6 address of the CTI device. This object contains value zero if IPV6 address is not available.

::= { ccmCTIDeviceEntry 15 }

With these changes, the ccmCTIDeviceEntry looks like the following:

CcmCTIDeviceEntry ::= SEQUENCE {

ccmCTIDeviceIndex CcmIndex,

ccmCTIDeviceName SnmpAdminString,

ccmCTIDeviceType INTEGER ,

ccmCTIDeviceDescription SnmpAdminString,

ccmCTIDeviceStatus CcmDeviceStatus,

ccmCTIDevicePoolIndex CcmIndexOrZero,

ccmCTIDeviceInetAddressType InetAddressType,

ccmCTIDeviceInetAddress InetAddress,

ccmCTIDeviceAppInfo SnmpAdminString,

ccmCTIDeviceStatusReason CcmDevFailCauseCode,

ccmCTIDeviceTimeLastStatusUpdt DateAndTime,

ccmCTIDeviceTimeLastRegistered DateAndTime,

ccmCTIDeviceProductTypeIndex CcmIndexOrZero,

ccmCTIDeviceInetAddressIPv4 InetAddressIPv4,

ccmCTIDeviceInetAddressIPv6 InetAddressIPv6

}

Cisco Unified Communications Manager Release 7.0(x)

This section contains the following subsections:

Cisco Unified Communications Manager Release 7.0(2)

Cisco Unified Communications Manager Release 7.0(1)

Cisco Unified Communications Manager Release 7.0(2)

This section describes the new and changed information in Cisco Unified Communications Manager Release 7.0(2). It contains the following subsections:

Resolved Caveats

Important Notes

Resolved Caveats

CAR

CSCsv35554 From CAR > Bills > Department report, when user goes up in the report chain, "30029 Direct access to this screen is not allowed" displays.

CSCsv39851 After a hostname gets changed, CAR fails to update the database URL.

CSCsv47100 Changes made for Brazil DST.

CCM Serviceability

CSCsw27176 Because the trace maximum number of files that are configured does not get enforced, LPM purging and alarms occur.

CDR Management

CSCsv84484 When a user pushes CDR files to the SFTP server by using GETFILE request, an exception occurs.

Call Control

CSCsv03084 CallControl should not generate CDR when the CallPickUp feature intercepts a call.

RTMT

CSCsk86985 Service names differ between RTMT TCT and the trace configuration window.

CSCsv47036 RTMT collects gzip traces files without closing them.

SDL

CSCsr69611 Network services get blocked after heavy load.

CSCsu78475 SMDI link server does not work.

Syslog

CSCsr92354 After reboot, "Waiting on IPMI Initialization" message displays.

Unknown

CSCsm26758 Database tables out-of-sync do not trigger an alert.

CSCso69307 DMA installation does not populate the SIP profile field on SIP trunks.

CSCsq36823 CLI improperly displays query results.

CSCsq38430 Cluster reboot should not be required after a server gets deleted.

CSCsq74528 After a DMA upgrade from Cisco Unified CM Release 4.1(3) to Cisco Unified CM Release 7.0, some original trace configuration settings get lost in the reset troubleshooting after upgrade.

CSCsr02780 CLI does not object to dbrep reset all when dbrep clusterreset is running.

CSCsr16701 Alarm 36 interferes with reset all.

Important Notes

Serviceability Session Timeout Not Graceful

When a session has been idle for more than 30 minutes, the Cisco Unified Serviceability user interface allows you to make changes before it indicates that the session timed out and redirects you to the login window. After you log in again, you may have to repeat those changes. This behavior occurs in the Alarm, Trace, Service Activation, Control Center, and SNMP windows.

Workaround—If you know that the session has been idle for more than 30 minutes, log out by using the Logout button before making any changes in the user interface.

RTMT Perfmon Counters and Cisco Unified Communications Manager Upgrade

If you are running the RTMT client and monitoring performance counters during a Cisco Unified Communications Manager upgrade, the performance counters will not update during and after the upgrade. To continue monitoring performance counters accurately after the upgrade completes, you must either reload the RTMT profile or restart the RTMT client.

Installation of RTMT on Microsoft Vista Platform

When you install RTMT on the Microsoft Vista platform, the system displays the User Account Control pop-up window to indicate that an unidentified program wants access to your computer. This occurs because of a limitation in the InstallAnywhere software. This one-time pop-up displays only when you are installing RTMT. Choose Allow to continue.

Serviceability Administrator Created during Installation

Removing the Administrator that is created during installation or upgrade can cause communication with remote nodes via Serviceability Administration to fail.

Best Practices for Assigning Roles to Serviceability Administrators

When starting and stopping services, Cisco recommends that you configure application users, rather than end users, to access remote nodes to perform tasks. Starting and stopping services requires that the Standard SERVICEABILITY Administration and Standard RealtimeAndTraceCollection roles be assigned.

CSCsq22385 Database Replication Failure Alert

The primary AMC server, which by default is the publisher node, raises the DBReplicationFailure alert after you add a new subscriber node to an existing cluster. After the install completes, the following alert displays.

May 7 16:02:09 lg-pub-1 local7 2 : 116: May 07 20:02:09.491 UTC : 
%CCM_RTMT-RTMT-2-RTMT-ERROR-ALERT: RTMT Alert Name:DBReplicationFailure Detail: 
DBReplicationFailure occurred. CallManager database replication errors, Reason code: 
Replication setup failed. The alert is generated on Wed May 07 16:02:09 EDT 2008 on node 
10.1.1.1. App ID:Cisco AMC Service Cluster ID: Node ID:xxx
 
   

You can observe this alert by using RTMT Alert Central or Summary view. You can also find the alerts in the EventViewer - Application Logs (CiscoSyslog) by using RTMT syslog viewer or by using the file view activelog syslog/CiscoSyslog CLI.

The following list gives more symptoms of DBReplicationFailure that you may experience:

In the database replicator traces that are available on the publisher node, you may see the following error when you attempt to get the subscriber DB replication set up.

dbl_repl_cdr_define_lg_sub_8_ccm6_1_2_1000_13-2008_05_07_12_00_20.log
 
   
sucmd_err [su -c 'ulimit -c 0;cdr err --zap' - informix ]
Executing [su -c 'ulimit -c 0;cdr define server --connect=lg_sub_8_ccm6_1_2_1000_13 
--idle=0 --init --sync=g_lg_pub_1_ccm6_1_2_1000_13 g_lg_sub_8_ccm6_1_2_1000_13 
--ats=/var/log/active/cm/log/informix/ats --ris=/var/log/active/cm/log/informix/ris;' 
- informix]
We got exception in Cdr define
Exception from cdr define e.value[100] e.msg [Error executing [su -c 'ulimit -c 0;cdr 
define server --connect=lg_sub_8_ccm6_1_2_1000_13 --idle=0 --init 
--sync=g_lg_pub_1_ccm6_1_2_1000_13 g_lg_sub_8_ccm6_1_2_1000_13 
--ats=/var/log/active/cm/log/informix/ats --ris=/var/log/active/cm/log/informix/ris;' 
- informix] returned [25600]]
 
   

The subscriber node Cisco DB logs (ccm.log) may include the following error:

11:47:51 CDR GC: GC could not verify the local server identity in CDR catalog with 
that in sqlhost file during CDR recovery.
 
   

You cannot register any devices on the newly installed subscriber node because replication is not set up to the node.

By default, the publisher node DB replicator service continuously attempts to define the new server and generates a new log every 5 minutes. Use the following workaround for a single node.


Step 1 Identify the exact subscriber server that is affected by reviewing the alert to confirm the node (IP) and the Node ID (hostname). In the example below, the alert displays node IP address as 10.1.1.1, App ID:Cisco AMC Service, and Cluster ID: Node ID:xxx.

May 7 16:02:09 lg-pub-1 local7 2 : 116: May 07 20:02:09.491 UTC : 
%CCM_RTMT-RTMT-2-RTMT-ERROR-ALERT: RTMT Alert Name:DBReplicationFailure Detail: 
DBReplicationFailure occured. CallManager database replication errors, Reason code: 
Replication setup failed. The alert is generated on Wed May 07 16:02:09 EDT 2008 on 
node 10.1.1.1. App ID:Cisco AMC Service Cluster ID: Node ID:xxx
 
   

Step 2 Confirm that the reason for the DB replication failure is cdr define.

Step 3 On the subscriber server, enter the utils dbreplication stop command.


Note This process can take 5 minutes or more to complete. Wait for it to finish before you continue.


Step 4 On the subscriber server, enter the utils dbreplication dropadmindb command.

Step 5 On the publisher server, enter the utils dbreplication reset <subname> (<subname> equals the name of the subscriber server) command.


At the end of the command output, the following message displays:

admin:utils dbreplication reset nw104a-195
Repairing of replication is in progress.
Background repair of replication will continue after that for 30 minutes.
command failed -- Enterprise Replication not active  (62)
 
   

This output does not indicate a failure in the reset command. It serves as an informational message that gets generated when you drop the admindb on the subscriber. The reset completes successfully but the operation can take 30 minutes or more to finish.

If you revert the servers in a cluster to run a prior release, you must manually reset database replication within the cluster. To reset database replication after you revert all the cluster servers to the prior release, enter the utils dbreplication reset all command on the publisher server.

When you switch versions by using Cisco Unified Communications Operating System Administration or the CLI, you get a message that reminds you about the requirement to reset database replication if you are reverting to an older product release. The caveats CSCsl57629 and CSCsl57655 also document this behavior.

For information about the utils dbreplication clusterreset, utils dbreplication dropadmindb, and utils dbreplication forcedatasyncsub commands, see the Command Line Interface Reference Guide for Cisco Unified Communications Solutions Release 7.0(1) document at http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/cli_ref/7_0_1/cli_ref.html.

Serviceability Inaccessible

If you cannot access Cisco Unified Serviceability from Cisco Unified OS Administration, "Loading, please wait" message displays indefinitely. Log out from Cisco Unified OS Administration, select Cisco Unified Serviceability from the navigation menu, and log into Cisco Unified Serviceability.

Cisco Unified Communications Manager Release 7.0(1)

This section describes the new and changed information in Cisco Unified Communications Manager Release 7.0(1). It contains the following subsections:

Cisco Unified Serviceability

Cisco Unified Communications Manager CDR Analysis and Reporting

Cisco Unified Communications Manager Call Detail Records

Cisco Unified Reporting

Cisco Unified Serviceability

This section contains the following subsections:

Browser Requirements

New Enterprise Parameters for Cisco Syslog Agent

Configuring the Application Billing Servers

Vendor-Supported MIB OIDs

Cluster Service Activation Node Recommendations

Alarm Additions and Changes

Removed Alarms

Browser Requirements

The following browser requirements apply to Cisco Unified Communications Manager Administration, Cisco Unified Serviceability, Bulk Administration Tool, Cisco Unified Communications Operating System, Disaster Recovery System, and Cisco Unified Reporting:

Netscape 7.1

Microsoft Internet Explorer (IE) 6 and 7—IE 7 adds security features that change the way that the browser handles Cisco certificates for website access. Cisco provides a self-signed certificate for the Cisco Unified Communications Manager server and IE 7 flags this certificate as untrusted and provides a certificate error, even when the trust store contains the server certificate. Refer to the Cisco Unified Communications Manager Security Guide for the certificate download procedure.

New Enterprise Parameters for Cisco Syslog Agent

Cisco Syslog Agent forwards all alarms that meet or exceed the configured threshold to a remote syslog server with two settings: remote syslog server name and syslog severity. The alarms include system (OS/hardware platform), application (services), and security alarms. If the server name is not specified, Cisco Unified Serviceability does not send any syslog messages.

The following tips should be considered:

Do not configure a Cisco Unified Communications Manager server as a remote syslog server. The Cisco Unified Communications Manager server does not accept Syslog messages from another server.

If you configure both the Cisco Syslog Agent alarm enterprise parameters and application (service) alarms in Cisco Unified Serviceability, the system can send the same alarm to the remote syslog twice.

If local syslog is enabled for an application alarm, the system sends the alarm to the enterprise remote syslog server only when the alarm exceeds both the local syslog threshold and the enterprise threshold.

If remote syslog is also enabled in Cisco Unified Serviceability, the system forwards the alarm to the remote syslog server by using the application threshold that is configured in Cisco Unified Serviceability, which may result in the alarm getting sent to the remote syslog server twice.

Configuring the Application Billing Servers

There are two new billing application server configuration parameters:

Resend on Failure—This option informs the CDR Repository Manager (CDRM) not to send outdated CDR and CMR files to the billing server after the FTP or SFTP connection is restored.

Generate New Key—This option generates new keys and resets the connection to the SFTP server.

Vendor-Supported MIB OIDs

See Chapter 9 "Vendor-Specific Management Information Base" to find the Object IDs (OIDs) for vendor-supported MIBS.

Cluster Service Activation Node Recommendations

The "Configuring Services" chapter in the Cisco Unified Serviceability Administration Guide describes the recommendations for cluster service activation for specific nodes in a cluster.

Alarm Additions and Changes

TFTP Catalog

Table 2-8 lists the differences in the TFTP alarm names from Cisco Unified CM Release 6.1(2) to Release 7.0(1).

Table 2-8 Differences in TFTP Alarm Names

Cisco Unified CM Release 6.1(2) TFTP Alarm Name
Cisco Unified CM Release 7.0(1) TFTP Alarm Name

kCreareThreadFailed

CreateThreadFailed

kSDIControlLayerFailed

SDIControlLayerFailed

kConfigThreadReadConfigurationFailed

ConfigThreadReadConfigurationFailed

kConfigThreadBuildFileFailed

ConfigThreadBuildFileFailed

kConfigThreadChangeNotifyServerInstanceFailed

ConfigThreadChangeNotifyServerInstanceFailed

kConfigThreadChangeNotifyServerSingleFailed

ConfigThreadChangeNotifyServerSingleFailed

kConfigThreadChangeNotifyServerStartFailed

ConfigThreadChangeNotifyServerStartFailed

kConfigThreadCNCMGrpBuildFileFailed

ConfigThreadCNCMGrpBuildFileFailed

kConfigThreadCNGrpBuildFileFailed

ConfigThreadCNGrpBuildFileFailed

kConfigThreadUnknownExceptionCaught

ConfigThreadUnknownExceptionCaught

kReadConfigurationUnknownException

ReadConfigurationUnknownException

kConfigItAllReadConfigurationFailed

ConfigItAllReadConfigurationFailed

kConfigItAllBuildFilesFailed

ConfigItAllBuildFilesFailed

kSocketError

SocketError

kTFTPServerListenSetSockOptFailed

TFTPServerListenSetSockOptFailed

kTFTPServerListenBindFailed

TFTPServerListenBindFailed

kNoCallManagerFound

NoCallManagerFound

kCNFFBuffWriteToFilefopenfailed

CNFFBuffWriteToFilefopenfailed

kCNFFBuffWriteToFilefwritefailed

CNFFBuffWriteToFilefwritefailed

kServingFileWarning

ServingFileWarning

kThreadPoolProxyUnknownException

ThreadPoolProxyUnknownException


LPM TCT Catalog—The following new LPM TCT alarms are added:

SparePartitionLowWaterMarkExceeded—The percentage of used disk space in the spare partition has exceeded the configured low water mark. Severity level is Error(3). See SparePartitionLowWaterMarkExceeded for more information.

SparePartitionHighWaterMarkExceeded—The percentage of used disk space in the spare partition has exceeded the configured high water mark. Severity level is Error(3). See SparePartitionHighWaterMarkExceeded for more information.

DB Catalog—The ErrorStartingThreads DB alarm is removed from DB Alarm Catalog.

DRF Catalog—The CiscoDRFUnknownClient and CiscoDRFTruststoreMissing alarms are removed from the DRF Alarm Catalog.

CAR Catalog—The following new CAR alarms are added:

CARSchedulerJobFailed—Critical CAR scheduled job failed. Severity level is Error(3). See CARSchedulerJobFailed for more information.

CARSchedulerJobError—CAR scheduled job failed. Severity level is Error(3). See CARSchedulerJobError for more information.

BadCDRFileFound—Bad CDR or CMR flat file found during CDR Load to CAR database. Severity level is Error(3). See BadCDRFileFound for more information.

CertMonitor Catalog—The following new CertMonitor alarms are added:

CertExpiryEmergency—A certificate has expired. Severity is Emergency (0). See for more information.

CertExpiryAlert—Certificate is about to expire in 1 day. Name of the service generating this alarm is Cisco Certificate Expiry Monitor.Severity level is Alert(1). See for more information.

CertExpiryCritical—Certificate is about to expire in less than 7 days. Regenerate or reimport certificate. Name of the service generating this alarm is Cisco Certificate Expiry Monitor. Severity level is Critical(2). See for more information.

CertExpiryError—Certificate is expiring. Regenerate or reimport certificate. Name of the service generating this alarm is Cisco Certificate Expiry Monitor. Severity level is Error(3). See for more information.

CertExpiryWarning—Certificate is about to expire in less than 30 days. Regenerate or reimport certificate. Name of the service generating this alarm is Cisco Certificate Expiry Monitor. Severity level is Warning(4). See for more information.

CertExpiryNotice—Certificate is expiring. Regenerate or reimport certificate. Name of the service generating this alarm is Cisco Certificate Expiry Monitor. Severity level is Notice (5). See for more information.

CertExpiryInformation—Certificate is expiring. Regenerate or reimport certificate. Name of the service generating this alarm is Cisco Certificate Expiry Monitor. Severity level is Informational(6). See for more information.

CertExpiryDebug—Certificate is expiring. Regenerate or reimport certificate. Name of the service generating this alarm is Cisco Certificate Expiry Monitor. Severity level is Debug(7). See for more information.

IMS Catalog—The following new IMS alarms are added:

authFail—Failed to authenticate this user

authSuccess—Successfully authenticated this user

authLdapInactive—A directory sync was likely done in the immediate past (1 day), This user has yet to be removed from the database

authAdminLock—User is locked out by administrator

authHackLock—User attempted too many incorrect authentications in certain time frame

authExpired—This user credentials have expired

authInactiveLock—User has been inactive for some specified time, and credential is locked

authMustChange—User Must Change is set on this credential

credUpdateFailure—Some problem updating the credential

credUpdateSuccessCredential—Successfully updated

credFullUpdateSuccess—Credential was successfully updated

credFullUpdateFailure—An error was encountered during update of credential fields

credReadFailure—Error occurred attempting to read a credential

credReadSuccess—Successfully read a credential

AdminPassword—ims-auth

CallManager Catalog—The following existing CallManager alarms updated to include new alarm parameters:

DeviceTransientConnection:

IPV6Address

IPAddrAttributes

IPV6AddrAttributes

Additional Reason codes

DeviceRegistered

IPV6Address

IPAddrAttributes

IPV6AddrAttributes

ActiveLoadId

Additional Perfmon types and Device types

DeviceUnregistered

IPV6Address

IPAddrAttributes

IPV6AddrAttributes

Additional Device types

SIPStarted

IPV6Address

SIPStopped

IPV6Address

Removed Alarms


Note IpVms Catalog alarms that were unused got removed because design changes made them obsolete.


TCPInitError

DatabaseDefaultsReadFailure

TcpCommError

OperatingSystemFailure

CdrWriteError

COMException

kRECICMPErrorNotification

kMCBICMPErrorNotification

kRECDeviceRecordNotFound

kMCBDeviceRecordNotFound

kRECDistMoveAbort

kRECDistSecRSSRecResuming

kRECDistSecRSSCritRecStopping

kRECDistPrimRSSRevertFromSecRSS

kRECDistPrimRSSRecResuming

kRECDistPrimRSSCritRecStopping

kRECDistPrimRSSCritSwitchSecRSS

kRECDistFindNextChgFailed

kRECDistThreadException

kRECDistThreadxFailed

kRECDistExitEventCreationFailed

kRECSessMoveFileFailed

kRECSessCreateWavFailed

kRECSessLocalPathFull

kRECSessCreateEventError

kRECMgrRecordSessionException

kRECMgrThreadException

kRECMgrThreadxFailed

kRECMgrExitEventCreationFailed

kRECMgrDeleteFileFailed

kRECMgrCreateDirFailed

RECDeviceRecoveryCreateFailed

MCBDeviceRecoveryCreateFailed

kDbCheckRECUnknownException

kDbCheckRECComException

kDbCheckRECDblException

kDbCheckRECListUnknownException

kDbCheckRECListComException

kDbCheckRECListDblException

kDbCheckMCBUnknownException

kDbCheckMCBComException

kDbCheckMCBDblException

kDbCheckMCBListUnknownException

kDbCheckMCBListComException

kDbCheckMCBListDblException

kDbCheckANNUnknownException

kDbCheckANNComException

kDbCheckANNDblException

kDbCheckANNListUnknownException

kDbCheckANNListComException

kDbCheckANNListDblException

kDbCheckANNEnterpriseComException

kDbCheckANNEnterpriseDblException

kDbCheckANNEnterpriseUnknownException

kReadCfgRECListUnknownException

kReadCfgRECListComException

kReadCfgRECListDblException

kReadCfgRECUnknownException

kReadCfgRECComException

kReadCfgRECDblException

kReadCfgMCBListUnknownException

kReadCfgMCBListComException

kReadCfgMCBListDblException

kReadCfgMCBUnknownException

kReadCfgMCBComException

kReadCfgMCBDblException

kReadCfgANNXmlFileNotFound

kRECDeviceStartingDefaults

kMCBDeviceStartingDefaults

kRequestedRECStreamsFailed

kRequestedMCBStreamsFailed

kANNAudioTftpMgrStartFailed

kANNAudioTftpMgrCreate

kANNAudioOpenFailed

kANNAudioInvalidLocale

kANNAudioUndefinedLocale

kANNAudioUndefinedAnnID

kANNAudioComException

kANNAudioXmlLoadFailed

kANNAudioXmlSyntax

kANNAudioXmlComErr

kANNAudioTftpFileMissing

kDbCheckCFBComException

kDbCheckCFBConfigComException

kDbCheckCFBConfigDblException

kDbCheckCFBConfigUnknownException

kDbCheckCFBDblException

kDbCheckCFBListComException

kDbCheckCFBListDblException

kDbCheckCFBListUnknownException

kDbCheckCFBUnknownException

kDBCheckDblGetNodeNameFailed

kDbCheckMOHAudioSourceComException

kDbCheckMOHAudioSourceDblException

kDbCheckMOHAudioSourceUnknownException

kDbCheckMOHComException

kDbCheckMOHListDblException

kDbCheckMOHListUnknownException

kDbCheckMOHServerComException

kDbCheckMOHServerDblException

kDbCheckMOHServerUnknownException

kDbCheckMOHUnknownException

kDbCheckMTPComException

kDbCheckMTPConfigComException

kDbCheckMTPConfigDblException

kDbCheckMTPConfigUnknownException

kDbCheckMTPDblException

kDbCheckMTPListComException

kDbCheckMTPListDblException

kDbCheckMTPListUnknownException

kDbCheckMTPUnknownException

kDeviceDriverCFBConfigurationFailed

kDeviceDriverMOHConfigurationFailed

kDeviceDriverMTPConfigurationFailed

kIPVMSMgrThreadException

kSDITraceStartFailed

kDbCheckMOHEnterpriseComException

kDbCheckMOHEnterpriseDblException

kDbCheckMOHEnterpriseUnknownException

kDbCheckMOHListComException

Existing/Inapplicable Alarms

The following alarms exist but no longer apply to Cisco Unified CM Release 6.1 or Release 7.0(1):

kPWavMgrExitEventCreateFailed

kAddIpVmsRenderFailed

kCreateGraphManagerFailed

kFixedInputAddAudioCaptureDeviceFailed

kFixedInputAddG711AlawIpVmsRenderFailed

kFixedInputAddG711UlawIpVmsRenderFailed

kFixedInputAddG729IpVmsRenderFailed

kFixedInputAddMOHEncoderFailed

kFixedInputAddWideBandIpVmsRenderFailed

kFixedInputAudioCapMOHEncoderConnFailed

kFixedInputAudioCaptureCreateFailed

kFixedInputClassEnumeratorCreateFailed

kFixedInputCreateGraphManagerFailed

kFixedInputFindAudioCaptureDeviceFailed

kFixedInputGetEventNotificationFailed

kFixedInputGetFileNameFailed

kFixedInputGetG711AlawIpVmsRenderFailed

kFixedInputGetG711AlawIpVmsRendInfFailed

kFixedInputGetG711UlawIpVmsRenderFailed

kFixedInputGetG711UlawIpVmsRendInfFailed

kFixedInputGetG729IpVmsRenderFailed

kFixedInputGetG729IpVmsRendInfFailed

kFixedInputGetMediaControlFailed

kFixedInputGetMediaPositionFailed

kFixedInputGetMOHEncoderFailed

kFixedInputGetWideBandIpVmsRenderFailed

kFixedInputGetWideBandIpVmsRendInfFailed

kFixedInputMOHEncG711AlawRenderConnFail

kFixedInputMOHEncG711UlawRenderConnFail

kFixedInputMOHEncG729RenderConnFailed

kFixedInputMOHEncWidebandRenderConnFail

kFixedInputSetNotifyWindowFailed

kGetEventNotificationFailed

kGetIpVmsRenderFailed

kGetIpVmsRenderInterfaceFailed

kGetMediaControlFailed

kGetMediaPositionFailed

kMOHMgrThreadCreateWindowExFailed

kMOHPlayStreamControlNull

kMOHPlayStreamMediaControlObjectNull

kMTPICMPErrorNotification

kRenderFileFailed

MTPDeviceRecoveryCreateFailed

Cisco Unified Real-Time Monitoring Tool

This section contains these subsections:

Perfmon Counters Added

Preconfigured Perfmons Added

CTIManager Improved Throughput

Simultaneous Alert Configuration

Perfmon Counters Added

Four new perfmon counters are added and are described in the following paragraphs:

CM_MediaTermPointsRequestsThrottled—Represents the total number of media termination point (MTP) resource requests that have been denied due to throttling. A resource did not get allocated because the MTP was used beyond the configured Transcoder Resource Throttling Percentage. This counter increments each time a request and denial are performed. A running total is kept since the start of the Cisco CallManager service.

CM_TranscoderRequestsThrottled—Represents the total number of transcoder resource requests that have been denied due to throttling. A resource did not get allocated because the MTP was used beyond the configured Transcoder Resource Throttling Percentage. This counter increments each time a request and denial are performed. A running total is kept since the start of the Cisco CallManager service.

MTP_RequestsThrottled—Represents the total number of MTP resource requests that have been denied due to throttling. A resource did not get allocated because the MTP was used beyond the configured Transcoder Resource Throttling Percentage. This counter increments each time a request and denial are performed. A running total is kept since the start of the Cisco CallManager service.

XCODE_RequestsThrottled—Represents the total number of transcoder resource requests that have been denied due to throttling. A resource was not allocated because the MTP was used beyond the configured Transcoder Resource Throttling Percentage. This counter increments each time a request and denial are performed. A running total is kept since the start of the Cisco CallManager service.

Preconfigured Perfmons Added

Table 2-9 describes new preconfigured perfmons.

Table 2-9 Preconfigured Perfmons 

Counter
Description

Faults Per Sec

Number of page faults (both major and minor) that the system made per second (post 2.5 kernels only). This does not necessarily represent a count of page faults that generate I/O because some page faults can get resolved without I/O.

Low Total

Total low (non-paged) memory for kernel.

Low Free

Total free low (non-paged) memory for kernel.

Major Faults Per Sec

Number of major faults that the system made per second that have required loading a memory page from disk (post 2.5 kernels only).

Pages Input Per Sec

Total number of kilobytes that the system paged in from the disk per second.

Pages Output Per Sec

Total number of kilobytes that the system paged out to the disk per second.

Wchan

Displays the channel (system call) in which the process is waiting.


CTIManager Improved Throughput

The following new alarms, counters, and alerts support the spare partition:

System LpmTct Catalog Alarms

SparePartitionLowWaterMarkExceeded—The percentage of used disk space in the spare partition exceeded the configured low water mark. Severity equals ERROR_ALARM.

SparePartitionHighWaterMarkExceeded—The percentage of used disk space in the spare partition exceeded the configured high water mark. Severity equals ERROR_ALARM.

Preconfigured System Disk Usage Perfmons

Spare Partition Usage—The disk usage monitoring category displays the percentage of disk usage for the Spare partition in each host.

Preconfigured System Alerts

SparePartitionHighWaterMarkExceeded—This alert occurs when the SparePartitionHighWaterMarkExceeded event gets generated. It indicates that the percentage of used disk space in the spare partition exceeds the configured high water mark. Table 2-10 lists the default values and configurations.

Table 2-10 Default Configuration for the SparePartitionHighWaterMarkExceeded 

Value
Default Configuration

Enable Alert

Selected

Severity

Critical

Enable/Disable this alert on the following servers

Enabled on listed servers

Threshold

Trigger alert occurs when following condition is met:

Spare Partition Used Disk Space Exceeds High Water Mark (95%)

Duration

Trigger alert immediately

Frequency

Trigger alert on every poll

Schedule

24 hours daily

Enable E-mail-mail

Selected

Trigger Alert Action

Default


SparePartitionLowWaterMarkExceeded: This alert occurs when the SparePartitionLowWaterMarkExceeded event gets generated. It indicates that the percentage of used disk space in the spare partition exceeds equals less than the low water mark. Table 2-11 lists the default values and configurations.

Table 2-11 Default Configuration for the SparePartitionLowWaterMarkExceeded 

Value
Default Configuration

Enable Alert

Selected

Severity

Critical

Enable/Disable this alert on the following servers

Enabled on listed servers

Threshold

Trigger alert occurs when following condition is met:

Spare Partition Used Disk Space Exceeds Low Water Mark (90%)

Duration

Trigger alert immediately

Frequency

Trigger alert on every poll

Schedule

24 hours daily

Enable E-mail

Selected

Trigger Alert Action

Default


Simultaneous Alert Configuration

All pre-canned alerts initially get assigned a default alert action. The default alert action configures the alerts for syslog and alert logging. When you add e-mail destinations to the default alert action, all precanned alerts get sent to those recipients. Updating the default alert action impacts all alerts that you configured. You cannot remove the default alert action.

Refer to the Cisco Unified Real-Time Monitoring Tool Administration Guide for the configuration procedure that adds the default alert action for all precanned alerts simultaneously.

Cisco Unified Communications Manager CDR Analysis and Reporting

This section contains the following subsections:

Backup of CAR Database

New CDR Service Parameters

Supported Versions of FTP/SFTP for Billing Servers

Configuring Individual and Department Bills Reports

Configuring CDR Error Reports

Configuring the CDR Load Schedule

Manual Purging or Reloading the CAR Database

Task Monitor and Database Maintenance

Enabling or Customizing Reports for Automatic Generation

Backup of CAR Database

The CAR and CDR Disaster Recovery Service (DRS) now integrates into the Disaster Recovery System (DRS). The DRS includes the backup of the CAR database, pregenerated reports, and the CDR preserved flat files.

New CDR Service Parameters

The following new service parameters can affect CDR/CMR records:

Show Line Group Member DN in finalCalledPartyNumber CDR Field—Determines whether the finalCalledPartyNumber field in CDRs shows the directory number (DN) of the line group member who answered the call or the hunt pilot DN.

Add Incoming Number Prefix to CDR —Determines whether Cisco Unified Communications Manager adds the incoming prefix (as specified in the National Number Prefix, International Number Prefix, Subscriber Number Prefix, and Unknown Number Prefix service parameters) to the calling party number in the CDRs for that call.

Use Global Call ID of Parked Call Enabled—Determines whether the globalCallId that is reported in the CDRs and Cisco Unified JTAPI applications changes to a new globalCallId when a call gets retrieved from park.

Supported Versions of FTP/SFTP for Billing Servers

The CDR Repository Manager sends CDR files to preconfigured destinations (up to three billing servers) that are using FTP/SFTP. Ensure that your billing server uses one of the following Cisco tested and supported versions of FTP or SFTP:

Linux/Unix

FTP: Unix (SunOS 5.6 Generic_105181-10) and Linux server (2.4.21-47.ELsmp and 2.6.9-42.7.ELsmp)

SFTP: Unix (SunOS 5.6 Generic_105181-10) and Linux server (2.4.21-47.ELsmp and 2.6.9-42.7.ELsmp)

Windows

FTP: Microsoft FTP service (Windows 2000 5.00.2195 sp4, IIS 5.0) and WAR FTP Daemon (1.82.0.10) and FreeFTPd (1.0.10 and 1.0.11)

SFTP: FreeFTPd (1.0.10 and 1.0.11)

Configuring Individual and Department Bills Reports

Before you can configure the Individual or Department Bills reports, you must ensure that a device with an assigned Owner User ID exists, in the case of the Individual Bills reports, in Cisco Unified Communications Manager Administration for each user that is included in the report. In the case of the the Department Bills report, you must ensure that a device with an assigned Owner User ID and Manager User ID exists in Cisco Unified Communications Manager Administration for each user that is included in the report.

For both individual bills and department bills, if the Extension Mobility feature is enabled on the device and the user logs into the phone and places a call, the User ID that gets recorded in the CDRs represents the logged in User ID. If Cisco Extension Mobility is not enabled on the device, the User ID that gets recorded in the CDRs specifies the Owner User ID that is configured for the device.

In the situation in which the User ID or the Owner User ID are not configured (that is, Cisco Extension Mobility is not enabled, and the Owner User ID is not configured), the User ID field in the CDRs gets recorded as blank. CAR uses the default User ID of "_unspecified user" when it loads the CDRs, and the CDRs do not display in the Individual Bills User reports because no user by the name of "_unspecifieduser" exists in the Cisco Unified Communications Manager database.

If you look for the reports for a particular end user in the directory, the User ID for the particular end user must be configured as the Owner User ID for the device or the particular end user must have logged in to the device with the Cisco Extension Mobility feature enabled.

Configuring CDR Error Reports

To determine why the error records failed the CDR Load, you must review the information in the tbl_error_id_map table. Refer to the CDR Analysis and Reporting Administration Guide.

Configuring the CDR Load Schedule

The default batch size specifies 600 CDR or CMR. The default sleep time between each CDR batch equals 2500 ms and 3000 ms for each CMR batch. However, you can configure the batch size from the tbl_system_preferences table "Loader Batch" column to have any value between 50 and 2000.

Manual Purging or Reloading the CAR Database

Manual purging of the CDRs stops if the CAR Web Service is stopped during the manual purge process. Manual purging cannot begin again until the CAR Web Service restarts. Then, you must begin the manual purge process again. The CDR Loader cannot begin again until either the CAR Web Service or the CAR Scheduler gets restarted. Refer to the CDR Analysis and Reporting Administration Guide.

Task Monitor and Database Maintenance

Cisco Unified Communications Manager introduced the Task Monitor and Database Maintenance features. The Task Monitor begins about 1 minute after the Scheduler starts, and 1 minute after the Scheduler repopulates the schedules every day at midnight (00.00). The Task Monitor periodically (every 5 minutes) monitors the status of all jobs for the day from the tbl_event_log with the exception of the following jobs: PopulateSchedules, TaskMonitor, DatabaseMaintenance, and DailyCdrLoad.

When a task does not start on schedule because an earlier task is still running, you may see something like the following trace message:

2008-02-14 08:00:04, 602 WARN [main] services. Scheduler - runTasks(): Job [DailyCdrLoad] 
thread is busy, hence it will be removed from today's schedule and not be started!"
 
   

The Scheduler has a grace period for 10 seconds to check whether the task thread is complete. The Scheduler sleeps up to 2 minutes total. If the task thread does not complete after the 2 minutes of wait time, the next task gets removed from the current schedule and does not run until its next scheduled time.

A new field, Scheduled, exists in the Event Log report status that includes tasks that have been scheduled but have not yet started. When the Scheduler restarts, all unfinished jobs with a status of Scheduled get deleted. Current jobs with the status of In Progress or Scheduled get changed to Unsuccessful.

Enabling or Customizing Reports for Automatic Generation

For all new installations of Cisco Unified Communications Manager, you must first enable the e-mail alerts and reports for automatic generation. The default status for all reports and alerts is "Disabled." For all Cisco Unified Communications Manager upgrades from Release 5.x to a later release of Cisco Unified Communications Manager, the tbl_pregenmail_option table data migrates only if the CAR Scheduler service is active.

Cisco Unified Communications Manager Call Detail Records

This section contains the following subsections:

Partition/Extension Numbers in CDRs

Calling Party Normalization and Support for Dialing "+" in CDRs

Call Park CDR Examples of New Service Parameters

Partition/Extension Numbers in CDRs

The following new partition/extension numbers fields exist in a CDR record:

outpulsedCallingPartyNumber

outpulsedCalledPartyNumber

Calling Party Normalization and Support for Dialing "+" in CDRs

Cisco Unified Communications Manager supports Calling Party Normalization and dialing "+". The callingPartyNumber, originalCalledPartyNumber, finalCalledPartyNumber, lastRedirectDN, and the fields, outpulsedCallingPartyNumber and outpulsedCalledPartyNumber can now contain a "+" in the CDR. The device reports the calling party number that it outpulses to call control only if calling party normalization/localization takes place.

Call Park CDR Examples of New Service Parameters

The useGcidOfParkedCallEnabled service parameter includes the default value of False that provides, when a call is retrieved from park, Cisco Unified Communications Manager creates a new globalCallId. The value of True provides that, when the call is retrieved from park, Cisco Unified Communications Manager retains the original globalCallId. The following CDRs are examples of these scenarios.

Example 1

50003 calls 50002; 50002 presses the Park softkey. 50001 picks up the parked call by dialing the park code (44444).

Field Names
Original Park Call CDR
Parked Picked Up Call CDR

globalCallID_callId

1

2

origLegCallIdentifier

20863957

20863961

destLegCallIdentifier

20863958

20863957

callingPartyNumber

50003

50001

originalCalledPartyNumber

50002

50003

finalCalledPartyNumber

50002

50003

lastRedirectDn

50002

44444

origCause_Value

393216

0

dest_CauseValue

393216

16

origCalledPartyRedirectReason

0

0

lastRedirectRedirectReason

0

8

origCalledPartyRedirectOnBehalfOf

0

0

lastRedirectRedirectOnBehalfOf

0

3

origTerminationOnBehalfOf

3

0

destTerminationOnBehalfOf

3

12

joinOnBehalfOf

0

3

duration

4

60


Example 2

50003 calls 50002; 50002 presses the Park softkey. 50001 picks up the parked call by dialing the park code (44444).

Field Names
Original Parked Call CDR
Parked Picked Up Call CDR

globalCallID_callId

1

1

origLegCallIdentifier

20863957

20863961

destLegCallIdentifier

20863958

20863957

callingPartyNumber

50003

50001

originalCalledPartyNumber

50002

50003

finalCalledPartyNumber

50002

50003

lastRedirectDn

50002

44444

origCause_Value

393216

0

dest_CauseValue

393216

16

origCalledPartyRedirectReason

0

0

lastRedirectRedirectReason

0

8

origCalledPartyRedirectOnBehalfOf

0

0

lastRedirectRedirectOnBehalfOf

0

3

origTerminationOnBehalfOf

3

0

destTerminationOnBehalfOf

3

12

joinOnBehalfOf

0

3

duration

4

60


Cisco Unified Reporting

In Cisco Unified Reporting, trace settings for the publisher server and cluster servers that do not match the publisher trace settings display in the Cisco Unified CM Cluster Overview report under Cisco Unified CM Trace Information.

For Cisco Unified CMBE, trace settings for the server display in the Cisco Unified CM Cluster Overview report under Cisco Unified CM Trace Information.

For a complete description of reports that are available on your system and the data that gets captured in a report, access the Report Descriptions report, as described in the Cisco Unified Reporting Administration Guide.

Cisco Unified Communications Manager Release 6.1(x)

This section describes the new and changed information in Cisco Unified Communications Manager Release 6.x . It contains the following subsections:

Cisco Unified Communications Manager Release 6.1(3)

Cisco Unified Communications Manager Release 6.1(2)

Cisco Unified Communications Manager Release 6.1(1a)

Cisco Unified Communciations Manager Release 6.1(1b)

Cisco Unified Communications Manager Release 6.1(3)

This section contains the following subsections:

Cisco Unified Cisco Unified Real-Time Monitoring Tool

Cisco Unified Communications Manager CDR Analysis and Reporting

Cisco Unified Communications Manager Call Detail Records

Cisco Unified Communications Manager Release 6.1(2)

Cisco Unified Cisco Unified Real-Time Monitoring Tool

A change occurred in the Call State information that is collected from Cisco Unified Communications Manager/CTIManager and displayed in the Quality Report Tool (QRT) reports. Previously, the information included Connected, Connected Conference, Connected Transfer, and On Hook call state information. Now, the report only includes Connected and On Hook call state information.

Cisco Unified Communications Manager CDR Analysis and Reporting

This section contains these subsections:

Unavailable Reports to CAR Administrator

CDR Search by User Extension Supports "+" and URLs for SIP Calls

Change in Supported FTP/SFTP Versions for CAR Billing Servers

Effects on CAR Data and Upgrade Cisco Unified Communications Manager

Configuring CDR Error Reports

New Error Message for Data in Invalid or Remainder Partitions

Unavailable Reports to CAR Administrator

A CAR administrator can no longer generate CAR reports when a manual purge of the CAR database is in process or CDR records are reloading. The following message displays when you try to run reports during these processes:

10023: Manual Purge/Reload is in process. Please run the reports once the Manual 
Purge/Reload is over.
 
   

Both the Purge button and the Reload All Call Detail Records button get disabled, and the following message displays on the Manual Purge window, when either a manual purge or CDR reload occurs:

Manual Purge/Reload is still running. User will not be allowed to run another instance of 
Manual Purge/Reload. So, both Purge and Reload All Call Detail Records buttons are 
disabled.
 
   

Before this enhancement, a CAR administrator could request CAR reports during the purge, but message 10012 displayed.

CDR Search by User Extension Supports "+" and URLs for SIP Calls

When you use the CDR Search by User Extension feature, you may use the "+" in any position of the user extension number; however, the "+" cannot be used in any dial plan configurations. When the user extension number is a SIP call with a URL, the system allows no space in the URL.

Change in Supported FTP/SFTP Versions for CAR Billing Servers

Cisco allows you to use any SFTP server product but recommends SFTP products that have been certified with Cisco through the Cisco Technology Developer Partner program (CTDP). CTDP partners, such as GlobalSCAPE, certify their products with specified version of Cisco Unified Communications Manager. For information on which vendors have certified their products with your version of Cisco Unified Communications Manager, refer to the following URL:

http://www.cisco.com/pcgi-bin/ctdp/Search.pl

For information on using GlobalSCAPE with supported Cisco Unified Communications versions, refer to the following URL:

http://www.globalscape.com/gsftps/cisco.aspx

Cisco uses the following servers for internal testing. You may use one of the servers, but you must contact the vendor for support:

Open SSH (refer to http://sshwindows.sourceforge.net/)

Cygwin (refer to http://www.cygwin.com/)

Titan (refer to http://www.titanftp.com/)


Note For issues with third-party products that have not been certified through the CTDP process, contact the third-party vendor for support


Cisco has tested and will support the following versions of FTP or SFTP for CAR billing servers:

Linux/Unix—FTP: Unix (SunOS 5.6 Generic_105181-10) and Linux server (2.4.21-47.ELsmp and 2.6.9-42.7.ELsmp). SFTP: Unix (SunOS 5.6 Generic_105181-10) and Linux server (2.4.21-47.ELsmp and 2.6.9-42.7.ELsmp)

Windows—FTP: Microsoft FTP service (Windows 2000 5.00.2195 sp4, IIS 5.0) and WAR FTP Daemon (1.82.0.10)

Effects on CAR Data and Upgrade Cisco Unified Communications Manager

If you do not need to carry over your CAR data to Cisco Unified Communications Manager 6.1(3), Cisco recommends that you purge the CAR data before you run the Data Migration Assistant (DMA). Purging the CDR data speeds up the migration process and decreases the size of the DMA TAR file. Ensure that you purge any CAR records that are older than 180 days. See Upgrade of CAR Data for more information.

Ensure CAR Administrator Privileges Are Restored After Upgrade

When you use DMA to upgrade Cisco Unified Communications Manager, CAR users no longer have CAR administrator privileges after the upgrade and become standard end users. You must reset the CAR administrator privileges after the upgrade. Refer to the "Configuring CAR Administrators, Managers, and Users" section in the CDR Analysis and Reporting Administration Guide for more information on how to configure CAR administrators.

Configuring CDR Error Reports

To determine why the error records fail the CDR load, you must review the information in the tbl_error_id_map table.

Table 2-12 lists the CDR error codes and the definition of the error.

Table 2-12 CDR Error Codes 

Error Code
Definition

CDRs

31101

CDR globalCallID_callManagerId <= 0

31102

CDR globalCallID_callId <= 0

31103

CDR origLegCallIdentifier <= 0

31105

CDR dateTimeOrigination <= 0

31108

CDR destLegIdentifier <= 0

31110

CDR dateTimeConnect <= 0

31111

CDR dateTimeDisconnect <= 0

31119

CDR originalCalledPartyNumber is empty

31120

CDR finalCalledPartyNumber is empty

31122

CDR duration < 0

31137

CDR LDAP error while retrieving UserID or ManagerID

31139

CDR callingPartyNumber is empty

31147

CDR origDeviceName is empty

31148

CDR destDeviceName is empty

31151

CDR origCallTerminationOnBehalfOf < 0

31152

CDR destCallTerminationOnBehalfOf < 0

31153

CDR lastRedirectRedirectOnBehalfOf < 0

31155

CDR destConversationId < 0

31156

CDR globalCallId_ClusterID is empty1

Orig CMR

31123

Orig CMR globalCallID_callManagerId <= 0

31124

Orig CMR globalCallID_callId <= 0

31125

Orig CMR numberPacketsSent < 0

31126

Orig CMR numberPacketsReceived < 0

31127

Orig CMR jitter < 0

31129

Orig CMR callIdentifier <= 0

31149

Orig CMR deviceName is empty

31157

Orig CMR globalCallId_ClusterID is empty1

Dest CMR

31140

Dest CMR globalCallID_callManagerId <= 0

31141

Dest CMR globalCallID_callId <= 0

31142

Dest CMR numberPacketsSent < 0

31143

Dest CMR numberPacketsReceived < 0

31144

Dest CMR jitter < 0

31145

Dest CMR callIdentifier <= 0

31150

Dest CMR deviceName is empty

31158

Dest CMR globalCallId_ClusterID is empty1

1 Applies to Cisco Unified CM only and not to Cisco Unified CMBE.


New Error Message for Data in Invalid or Remainder Partitions

A message gets logged in the CAR Scheduler traces if data is present in invalid and remainder partitions of the tbl_billing_data and tbl_billing_error files.

The LWM/HWM/2M e-mail alerts that get sent to the CAR administrator when CAR detects records in either the part_invalid or part_remainder partitions will contain the following information:

Data is present in invalid/remainder partition also, which cannot be removed by 
Automatic-Purge. Please delete these record(s) manually from Manual-Purge.

Cisco Unified Communications Manager Call Detail Records

For Cisco Unified Communications Manager Release 5.x and later releases, the value in the GlobalCallId CDR field survives over Cisco Unified Communications Manager restarts. In Release 4.x and earlier releases, even though the GlobalCallId field is time-based, the field gets reused under conditions of heavy traffic.

Because of this behavior, problems can occur with customer billing applications and the ability of CAR to correlate CMRs with CDRs and to correlate conference call CDRs. For Release 5.x and later releases, GlobalCallId redesign ensures the field retains a unique value, at least for a certain number of days.

Now, the last used globalCallId_callId value gets written to disk periodically (for every x number of calls). The value gets retrieved after a Cisco Unified Communications Manager restart, and the new globalCallId_callId value begins with this number plus x.

Cisco Unified Communications Manager Release 6.1(2)

This section contains the following subsections:

Cisco Unified Serviceability

Cisco Unified Communications Real-Time Monitoring Tool

Cisco Unified Serviceability

The following list shows preconfigured alerts that are now available in Cisco Unified Serviceability:

ServerDown: This alert gets triggered whenever the active AMC is unable to talk to a remote host.

HardwareFailure: This alert gets triggered whenever a corresponding HardwareFailure alarm/event occurs.

SDLLinkOutOfService: This alert gets triggered whenever a corresponding SDLLinkOOS alarm/event occurs.

DBReplicationFailure: This alert gets triggered whenever the corresponding perfmon counter "replication status" has values other than zero (init) and two (success).

SystemVersionMismatched: This alert gets triggered whenever a mismatch exists in system version.

Cisco Unified Communications Real-Time Monitoring Tool

Database Summary Includes Database Replication Information

RTMT displays information on predefined Cisco Unified Communications Manager objects in the monitoring pane when you select Communications Manager in the quick launch channel. It monitors the predefined objects on all nodes in the cluster. The Service category includes the Database Summary that now provides the number of replicates that have been created and the status of the replication in addition to the other types of connection information that was previously provided.

For more information, see the Cisco Unified Communications Manager Real-Time Monitoring Tool Administration Guide.

RTMT Critical Services

Cisco Unified Communications Manager Real-Time Monitoring Tool (RTMT) provides new states for the critical services that display in RTMT. The Critical Services monitoring category (choose Monitor > Server > Critical Services or click the Server button and Critical Services icon) provides the name of the critical service, the status (whether the service is starting, up, stopping, down, stopped by the administrator, not activated, or in an unknown state), and the elapsed time during which the services have existed in a particular state for the Cisco Unified Communications Manager server. For a specific description of each state, review the following information:

starting (new state)—This state indicates that the service is currently starting, as indicated in the Critical Services pane and in Control Center in Cisco Unified Serviceability.

up—This state indicates that the service is currently running, as indicated in the Critical Services pane and in Control Center in Cisco Unified Serviceability.

stopping (new state)—This state indicates that the service is currently stopping, as indicated in the Critical Services pane and in Control Center in Cisco Unified Serviceability.

down—This state indicates that the service stopped running unexpectedly; that is, you did not perform a task that stopped the service. The Critical Services pane indicates that the service is down.


Tip The CriticalServiceDown alert gets generated when the service status equals down (not for other states).


stopped by Admin (new state)—This state indicates that you performed a task that intentionally stopped the service; for example, the service stopped because you backed up or restored Cisco Unified Communications Manager, performed an upgrade, stopped the service in Cisco Unified Serviceability or the Command Line Interface (CLI), and so on. The Critical Services pane indicates the status.

not activated—This state indicates that the service is not currently activated, as indicated in the Critical Services pane and in Service Activation in Cisco Unified Serviceability.

unknown state—This state indicates that the system cannot determine the state of the service, as indicated in the Critical Services pane.

Adding RTMT Performance Counters in Bulk

On the RTMT Perfmon Monitoring pane, in table format only (not in chart format), you can now select multiple counters and multiple instances of counters, and add them all with a single click. Prior to this enhancement, you could add them only one at a time.

For more information, see the Cisco Unified Communications Manager Real-Time Monitoring Administration Tool Guide.

RTMT Trace and Log Central Disk IO and CPU Throttling

RTMT now supports the throttling of critical Trace and Log Central operations and jobs, whether they are running on demand, scheduled, or automatic. The effect of the throttling slows the operations when IO utilization is in high demand for call processing, so that call processing can take precedence.

For more information, see the Cisco Unified Communications Manager Real-Time Monitoring Administration Tool Guide.

Cisco Unified Communications Manager Release 6.1(1a)

This contains the following subsections:

CDR Analysis and Reporting Tool/Call Detail Record (CAR/CDR)

Cisco Unified Communciations Manager Release 6.1(1b)

CDR Analysis and Reporting Tool/Call Detail Record (CAR/CDR)

The following sections detail changes in CAR/CDR in release 6.1(1a) of Cisco Unified Communications Manager.

CAR System Scheduler Default Status

Automatically Generated Reports

Tbl_pregenmail_option Table Data

Tbl_pregenmail_option Table Data

Calculation of the Utilization of H.323 Gateways

CDR Search Reports Display Time in Two Ways

CAR Scheduler Now a Network Service

CAR System Scheduler Default Status

The CAR System Scheduler default status now specifies that CAR processes CDRs continuously 24 hours per day and 7 days per week. However, you can set the loading time, interval, and duration as needed. In addition, the default setting loads only CDR records. Call Management Records (CMR) records do not get loaded.

An option allows you to uncheck the "Load CDR Only" check box in the CAR System Scheduler window to allow CMR records to load.

Automatically Generated Reports

You can schedule CAR reports to generate automatically at a regular time. Each report that can be scheduled has its own report generation interval. In previous releases of Cisco Unified Communications Manager, the automatically generated reports default status specified Enabled. Beginning with Cisco Unified Communications Manager Release 6.1(1a), the default status specifies Disabled for the automatically generated reports. You must enable each automatically generated report after CAR is activated on your system.

Tbl_pregenmail_option Table Data

For all Cisco Unified Communications Manager upgrades from Release 5.x to a later release of Cisco Unified Communications Manager, the tbl_pregenmail_option table data migrates only if the CAR Scheduler service is active.

Calculation of the Utilization of H.323 Gateways

For calculation of the utilization of H.323 gateways, the system uses the port numbers from the CAR Gateway Configuration window. To find this window, choose System > System Parameters > Gateway Configuration. You cannot take port details for H.323 gateways from the Cisco Unified Communications Manager database because the H.323 port number always equals zero in the database. The user must update H.323 gateway ports information in the CAR Gateway Configuration window.

Be aware that the only port detail information that is taken from the CAR Gateway Configuration window is for those gateways that do not have port details that are available or that show zero in the Cisco Unified Communications Manager database.

CDR Search Reports Display Time in Two Ways

The CDR Search by User Extension, CDR Search by Gateway, CDR Search by Call Precedence Levels, and CDR Search for Malicious Calls reports now display current time in both Coordinated Universal Time (UTC) and local time and use the following rules:

The UTC and local time comprise a numeric string of mmddyyyy hhmmss, as in January 15, 2007 12:00:00.

The default FromDate and ToDate values display in UTC.

The default ToDate specifies the current time of the server in UTC.

The default FromDate value specifies the ToDate value minus 1 hour. For example, if ToDate = January 15, 2007 12:00:00, the FromDate default value = January 15, 2007 11:00:00 (all times in UTC).

CAR Scheduler Now a Network Service

Installed automatically, network services include services that the Cisco Unified Communications Manager Business edition system requires to function. Because these services are required for basic functionality, you cannot activate them in the Service Activation window. Cisco CAR Scheduler now represents a network service. In the previous release of Cisco Unified Communications Manager Business Edition the Cisco CAR Scheduler represented a feature service.

Cisco Unified Communciations Manager Release 6.1(1b)

This section contains the following noncomprehensive list of caveats that were resolved in this release of Cisco Unified CM:

CSCsm37017 - Prior to this release, when you configured traces in the serviceability window, no CCMUser option existed, which meant that you could not change the default CCMuser trace level.

CSCso11097 - Prior to this release, when you upgraded from Release 6.0 to 6.1, a corruption of the RAID controller firmware on a MCS-7845-I2 server existed. After the reboot that the upgrade required, the restart failed with this error "ATTENTION: The Firmware image in the controller is corrupted! Please run the Firmware Update Utility from the OS to update the firmware. Error code: 86."

CSCso53771 - According to Cisco Security, several products in the Cisco Unified Communications family of products contained a command execution vulnerability in the Disaster Recovery Framework (DRF) feature. A remote, unauthenticated user could exploit this vulnerability to execute arbitrary commands that may allow full administrative access to affected systems.

CSCso45910 - Prior to this release, after an upgrade, the server would not boot to the new partition.

CSCsm47603 - Prior to this release, the BIOS that is bundled with Release 6.1 did not support the E6400 processor that IBM put into their 7825I3 servers, and the BIOS got downrevved to the unsupported version during install/upgrade.

CSCsl31392 - Prior to this release, in DMA messages intended to identify problems in the user data could be misinterpreted as logging errors. Even if the user correctly identified the problem, the required user action was not evident. Release 6.1(1b) includes expanded explanations for five additional error cases DMA. The resulting user visible error messages provide a better understanding of cause and resolution.

CSCsm15075 In 6.1(1), when you click the Find button an Access Denied error got generated on systems with more than 250 gateways and/or route lists provisioned. In 6.1(1a) permissions were changed to allow the Find and List window to be loaded from the Route Pattern window.

Cisco Unified Communications Manager Release 6.0(1x)

This section describes the new and changed information in Cisco Unified Communications Manager Release 6.0(1x). It contains the following subsections:

Cisco Unified Communications Manager Release 6.0(1)

Cisco Unified Communications Manager Release 6.0(1a)

Cisco Unified Communications Manager Release 6.0(1b)

Cisco Unified Communications Manager Release 6.0(1)

This section describes the new and changed information in Cisco Unified Communications Manager Release 6.0(1). It contains the following subsections:

No Such Name Error in SNMP Response

Maximum Trace Settings

Terminal Server Causes RTMT to Display Repeating Syslog and Alert Messages

Secure Conferencing and CRD Data

Cisco Unified Serviceability

Cisco Unified Communications Real-Time Monitoring Tool

Cisco Unified Communications Manager CDR Analysis and Reporting

No Such Name Error in SNMP Response

If the getbulk/getnext/getmany request contains multiple OID variables in its request PDU and the subsequent tables appear empty in the CISCO-CCM MIB, the responses may include NO_SUCH_NAME, for SNMP v1 version or GENERIC_ERROR, for SNMP v2c or v3 version because the time that it takes to process the SNMP requests exceeds the MasterAgent timeout duration (currently set at 25 seconds).

Perform the following workaround:

Use the available scalar variables (1.3.6.1.4.1.9.9.156.1.5) to determine the table size before you access the table or perform the get operation on the desired table first and then query the non-empty tables.

Reduce the number of variables that are queried in a single request. For example, if the management application specifies timeout at 3 seconds for empty tables, Cisco recommends that you specify no more than 1 OID. For non-empty tables, it takes 1 second to retrieve one row of data.

Increase the response timeout.

Reduce the number of retries.

Do not use getbulk SNMP API. Getbulk API gets the number of records that is specified by MaxRepetitions. This means that, even if the next object goes outside the table or MIB, it gets those objects. So, if the Cisco Unified Communications Manager MIB has empty tables, it goes to next MIB and so will require more time to respond. When you know that the table is not empty, use getbulk API. Under these conditions, limit the maximum repetition counts to 5 to get a response within 5 seconds.

Structure SNMP queries to reflect current limits.


Note The SNMP standard requires that getnext and getbulk APIs return the next available object even if the end of the table has been reached. In the case of empty tables, the CCMAgent keeps traversing the MIB tree until it finds data to return.


Maximum Trace Settings

The maximum recommended Cisco Unified Communications Manager trace settings specifies 2,500 files of 2 MB each, for SDI and SDL traces, for a combined total of 5000 files. You can increase SDI traces to 5,000 files if SDL traces are disabled, but not vice versa. All other components should stay within 126 MB bucket (for example, 63 files of 2 MB). If you increase logs past the recommended limit, system performance gets reduced due to IOWAIT. After the system experiences IOWAIT related performance degradation, the only solution requires you to lower traces and use RTMT to remove all CCM/CTI SDI/SDL traces. For that reason, you should limit tracing to 5 GB for CCM and 5 GB for CTI.

Terminal Server Causes RTMT to Display Repeating Syslog and Alert Messages

When a terminal server is connected to the serial port of a Cisco Unified Communications Manager server, the system generates a repeating alert message and corresponding syslog message similar to the following examples:

Alert Message—SeverityMatch - Alert login(pam_unix)[12916]: check pass; user unknown

Syslog Message—May 16 04:44:44 azo-cm-uc auth 5 mgetty[23127]: failed dev=ttyS0, pid=23127, login time out

This includes a router that is being used as a terminal server.

Cisco recommended that you configure no exec on the lines that are connected to the console of the other devices.

Secure Conferencing and CRD Data

The Secure Conferencing feature provides authentication and encryption to secure a conference. CDR data provides the security status of each call leg from the phone endpoint to the conference bridge as well as the security status of the conference itself. The two values use two different fields inside the CDR database. CDR data provides termination cause code 58 (Bearer capability not presently available) when a Meet-Me conference rejects a join attempt that does not meet the minimum security level requirement. There are no new performance objects, counters, or alarms.

Cisco Unified Serviceability

Cisco Unified Serviceability allows you to perform such tasks as configuring trace parameters, configuring alarms, and activating, starting, and stopping services for Cisco Unified Communications Manager.

The Cisco Unified Serviceability GUI contains the following additions and changes:

System Alarm Catalog (new)—Contains the following alarm catalogs:

ClusterManagerAlarmCatalog—Contains all cluster manager alarm definitions that are related to the establishment of security associations between nodes in a cluster.

DBAlarmCatalog

DRFAlarmCatalog

GenericAlarmCatalog

JavaApplications

LoginAlarmCatalog

LpmTctCatalog

RTMTAlarmCatalog

SystemAccessCatalog—Contains all alarm definitions that are used for tracking whether System Access provides all thread statistic counters together with all the process statistic counters.

ServiceManagerAlarmCatalogs—Contains all service manager alarm definitions that are related to the activation, deactivation, starting, restarting, and stopping of services.

TFTPAlarmCatalog

TestAlarmCatalog

LoginAlarmCatalog (new)—Replaces the MLAAlarmCatalog and contains all login alarm definitions. The AuthenticationFailed alarm replaces the MLAUserLoginFailed alarm.

CallManager Alarm Catalog (changed)—Contains the following alarm catalogs:

CDRRepAlarm Catalog

CEFAlarmCatalog

CMIAlarmCatalog

CtiManagerAlarmCatalog

IpVmsAlarmCatalog

TCDSRVAlarm Catalog

The Cisco Unified Serviceability Administration Guide describes all the other catalogs, which existed in previous releases.

Cisco Unified Communications Real-Time Monitoring Tool

The Cisco Unified Communications Manager Cisco Unified Real-Time Monitoring Tool contains the following changes:

Trace and Log Central added an option that allows you to collect installation and upgrade log files on your local computer.

The new LogFileSearchStringFound alert replaces the TraceCollectionToolEvent alert. If you want to generate an alarm when the specified search string exists in a monitored trace file, enable the LogFileSearchStringFound alert.

The new CpuPegging alert replaces the NonCallProcessingNodeCpuPegging alert. The existing threshold setting for NonCallProcessingNodeCpuPegging does not get preserved, but the default CPU threshold settings for CpuPegging will remain the same as the NonCallProcessingNodeCpuPegging alert.

RTMT added the following performance objects:

Cisco MGCP BRI Device—The Cisco Media Gateway Control Protocol (MGCP) Foreign Exchange Office (FXO) Device object includes performance counters with information about registered Cisco MGCP BRI devices.

Cisco MobilityManager—The Cisco Mobility Manager object includes performance counters with information on registered Cisco Unified Mobility Manager devices.

Cisco SIP Station—The Cisco SIP Station object includes performance counters with information about registered Cisco SIP Stations.

Cisco Signaling Performance—The Cisco Signaling Performance object provides call signaling data on transport communications on Cisco Unified Communications Manager.

RTMT added the following performance counters (object):

SIPTrunkAuthorizationFailures (Cisco CallManager)

SIPTrunkAuthorizations (Cisco CallManager)

CallsRejectedDueToICTCallThrottling (Cisco H.323)

CCBsAllocated (Cisco SIP Stack)

PublishIns (Cisco SIP Stack)

PublishOuts (Cisco SIP Stack)

SCBsAllocated (Cisco SIP Stack)

SIPHandlerSDLQueueSignalsPresent (Cisco SIP Stack)

SIPGenericCounter1 through SIPGenericCounter4 (Cisco SIP Stack)

Cisco Unified Communications Manager CDR Analysis and Reporting

The Cisco Unified Communications Manager CDR Analysis and Reporting (CAR) application The following changes apply to CAR:

When a logged-in Cisco Extension Mobility user makes a call, CAR uses the user ID that is configured for the Cisco Extension Mobility user in all reports that display a user ID. When the call is made by a non-Cisco Extension Mobility user (or logged-out Cisco Extension Mobility user) and when the call is made with a device that does not have a configured Owner User ID, CAR uses the default user ID, unspecifieduser, in the report.

CDR Search includes several changes:

Mobility and Silent Monitoring and Recording calls comprise additions as new call features. The resulting CDR Search report window will show the new call types in the CallType column.

The origConversationID and callSecuredStatus fields display in the CDR detail reports.

A Busy Hour Call Completion (BHCC) number with the percentage of traffic during the busy hour now displays in the header of the Traffic Summary (hour of day) report.

Application users that have been added to the Standard CAR Administration group as a CAR Administrator can log in to CAR as an administrator with access to all CAR reports except the Individual Bill Report. If non-CAR Administrator application users try to log in, the following message displays: "Either the User Name or the Password entered is invalid. Ensure that you are logging into CAR as a CAR administrator or a regular End User."

The CAR Loader feature redesign for Cisco Unified Communications Manager Release 6.0(1) improves the overall CAR loader performance. The loading rate of CDRs and CMRs into the CAR database improved. A new option exists to load only CDRs into the CAR database and not load the CMRs. The CAR Loader will now load all CDRs into the CAR database first, and those CDRs will get updated with the CMR information after all CDRs within the same date are loaded into the database. Also, a new Unfinished-Processing-File-Recovery capability allows the CAR Loader to recover loading unfinished-processing CDR/CMR flat files properly.

When administrators configure phones from Cisco Unified Communications Manager Administration and do not specify the Owner User ID, the CAR Loader cannot determine the user_id that is associated with the device during load. For all these calls, CAR will assign the value of "unspecifieduser" to the user_id column of the CAR database. When you run a report, you will see a user that is called _unspecifieduser in the CAR reports.

CAR now supports the new error codes that the Identity Management System (IMS) returns and the corresponding error messages. The user sees the appropriate error message on the CAR Invalid Logon window.

New CAR report algorithms that have been implemented reduce the user-selected date and time range, so the number of records in the newly narrowed date and time range fall between 5000 and 10,000 records for PDF reports, between 20,000 and 30,000 records for CSV reports, and between 100 and 200 records for CDR Search reports. The narrowed date and time range that get returned from the algorithm provides the basis for report generation, and not the user-selected date and time range that users input.

Under Device Reports, changes reduce the number of gateways that can be searched in the Gateway Utilization Report from 15 to 5. The manner of calculating the gateway utilization also changed. Gateway utilization now gets calculated based on the duration of calls instead of the number of calls.

The method for configuring the H.323 Gateway Utilization report changed. The Cisco Unified Communications Manager database stores no port information for H.323 gateways. You must obtain the H.323 gateway port information from the Gateway Configuration window in CAR.

This change applies mainly to H.323 gateways and to any other gateways that have no port information available in the Cisco Unified Communications Manager database. The Cisco Unified Communications Manager database includes port information for most of the other types of gateways.

When the Forced Authorization Code (FAC) feature is invoked, the authorizationCodeValue field gets written into the CDR. To display the authorizationCodeValue field information in the CDR, ensure the "Display FAC in CDR" service parameter is set to True. The default value of the parameter specifies False.

Call Detail Record Definitions

This section describes the changes to the CDRs and CMRs with this release.

With Cisco Unified CallManager Release 4.2(1), you can configure Cisco Unified CallManager to report the directory number (DN) of the hunt group member who answered a direct call to the hunt pilot number in the final called party number field in the CDR. Previously, Cisco Unified CallManager reported the hunt pilot DN in the final called party number field in the CDR.

Cisco Unified CallManager Release 4.2(3) provides advanced ad hoc conference enhancements including the addition of the origConversationID field to the CDR.This field identifies the conference ID that is associated with the originating leg of the call. In most cases, this field equals 0. Default equals 0. The destConversationID field was added in previous releases. For conference chaining scenarios, the origConversationID and destConversationID fields identify which conferences are chained together.

The requestor party (party that requested the removal of a participant) appears in the CDR comment field to track the drop requestor because the requestor can be a participant other than the controller. The following tags apply for the originator information: ConfRequestorDn and ConfRequestorDeviceName. The tags for the drop requestor information include DropConfRequestorDn and DropConfRequestorDeviceName.

Cisco Unified Communications Manager Release 6.0(1) eliminates CDR Configuration Enterprise Parameters that were available in previous releases. To locate the CDR Configuration Enterprise Parameters, open Cisco Unified CallManager Administration and choose System > Enterprise Parameters. The release eliminates the following parameters:

Local CDR Path

Primary CDR UNC Path

CDR Format

Primary CDR DSN

Cisco Unified Communications Manager Release 6.0(1) supports the Call Monitoring and Call Recording features. No new CDR fields exist for these features. A CDR gets generated by using existing fields. For both monitoring and recording, the monitoring and recording calls have one-way media. The media fields remain empty for one side of the call for one-way media CDRs.

Two new redirect reasons exist:

SS_RFR_RECORDING (value = 354)

SS_RFR_MONITORING (value = 370)

Two new OnBehalfOf values exist:

Recording (value = 27)

Monitoring (value = 28)

The destconversationID field of the Monitoring call CDR will match the agent call leg identifier in the CDR of the call that is monitored. This will link the monitored call CDR and the monitoring call CDR together.

The origconversationID field of the two Recording call CDRs will match the agent call leg identifier in the recorded call CDR. This conversation ID will link the recorded call CDR and the CDRs that the recording calls generate.

The Secure Conference feature includes a new CDR field, callSecuredStatus. CAR will use the existing call termination cause code value of 58 to show those calls that were cleared because they failed to meet the security level for the Secure Conference feature.

AAC and iLBC comprise new codecs that are supported in Cisco Unified Communications Manager Release 6.0(1). For AAC calls, the codec specifies Media_Payload_AAC = 42, and the maxFramesPer Packet equals 1. For iLBC calls, the codec specifies Media_Payload_ILBC = 86.

The release adds the following new bandwidth fields to the CDR:

origMediaCap_bandwidth: This represents an integer field that contains the audio bandwidth.

destMediaCap_bandwidth: This represents an integer field that contains the audio bandwidth.

Cisco Unified Communications Manager Release 6.0(1) supports the Mobility feature. This feature includes Hand-In, Hand-Out, Cell Pickup, and Interactive Voice Response (IVR). No new CDR fields exist for these features, but a new OnBehalfOf field value and new Redirect Reason codes apply.

One new OnBehalfOf value exists:

Mobility (value = 24)

Four new Redirect Reason values exist:

SS_RFR_MOBILITY_HANDIN (value = 303)

SS_RFR_MOBILITY_HANDOUT (value = 319)

SS_RFR_MOBILITY_CELL_PICKUP (value = 335)

SS_RFR_MOBILITY_IVR (value = 399)

Cisco Unified Communications Manager Release 6.0(1) supports the Intercom feature. No new CDR fields exist for this feature. For intercom, one-way audio exists, and the CDR reflects the one-way audio. For talk-back intercom, two-way audio exists, and the CDR reflects two-way audio. Because the Intercom feature requires a partition (intercom partition), you can use the existing CDR fields to identify intercom calls.

The CDR for the Calling Party on Transfer consultation call of a Cisco Unity-initiated transfer changed in this release. The CDR of the consultation call will show that the original caller calls the transfer destination. Previously, the CDR showed that the Cisco Unity port called the transfer destination.

Cisco Unified Communications Manager Release 6.0(1) reassigns the following OnBehalfOf code values:

Aar—current value = 25. Previous value specified 17.

Directed Call Park—current value = 26. Previous value specified 22.

Table 13 shows the following changes occurred to existing CDR fields:

Table 13 Changes to Existing CDR Fields 

Field Name
Description of Change

cdrRecordType

Add: value 1 = End call detail record (CDR)

origSpan

For calls that originate at a gateway, this field indicates the B-channel number of the T1 or PRI trunk where the call originated.

destSpan

For calls that are received at a gateway, this field indicates the B-channel number of the T1 or PRI trunk where the call is received.

origCallTerminationOnBehalfOf

New OnBehalfOf codes have been added.

destCallTerminationOnBehalfOf

New OnBehalfOf codes have been added.

origCalledPartyRedirectOnBehalfOf

New OnBehalfOf codes have been added.

lastRedirectRedirectOnBehalfOf

New OnBehalfOf codes have been added.

origCalledPartyRedirectReason

New OnBehalfOf codes have been added.

lastRedirectRedirectReason

New OnBehalfOf codes have been added.

joinOnBehalfOf

New OnBehalfOf codes have been added.


The release adds value of 2 = CMR record to the cdrRecordType CMR field.

Cisco Unified Communications Manager Release 6.0(1a)

This section describes the new and changed information in Cisco Unified Communications Manager Release 6.0(1a). It contains the following subsections:

CSCsi75567 MCS-7825H2-IPC1 Reboots Randomly

CSCsi75567 MCS-7825H2-IPC1 Reboots Randomly

Sporadic reboots of the 7825H2 servers get triggered during long system hangs. ASR functionality autorecovers the servers after 10 minutes of kernel unresponsiveness. Event timing ranges from once every 3 months to once every 3 days. To work around the issue, see http://www.cisco.com/warp/public/770/fn62850.shtml.

Cisco Unified Communications Manager Release 6.0(1b)

This section describes the new and changed information in Cisco Unified Communications Manager Release 6.0(1b). It contains the following subsections:

Resolved Caveats

Resolved Caveats

The following list gives the caveats that are useful for Cisco Unified Serviceability, Cisco Unified RTMT, and Cisco Unified CAR and that were resolved in this release of Cisco Unified CM:

CSCso53771 - According to Cisco Security, several products in the Cisco Unified Communications family of products contained a command execution vulnerability in the Disaster Recovery Framework (DRF) feature. A remote, unauthenticated user could exploit this vulnerability to execute arbitrary commands that may allow full administrative access to affected systems.

CSCSk58101 - Prior to this release TabSync did not connect to Cisco Unified CM.

CSCsm47603 - The BIOS bundled with Cisco Unified Communications Manager Release 6.0(1a) does not support the E6400 processor in IBM 825I3 servers. Because of this, Cisco Unified CM Release 6.0(1a) downrevs the BIOS to an unsupported version during installation or upgrade. Unfortunately, during start up, the system simply warns the user by displaying a warning message. The customer will not see this message if he is not constantly looking at the terminal. The system allows startup to continue in the unsupported state. The implications of running in this state remain unknown.

CSCsj82405 - Prior to this release, DMA did not migrate some LDAP users due to spaces in the user profile.

CSCsi71128 - Prior to this release, DMA required 28 hours to run on pre-4.1(3) system with many devices.

CSCsk41261 - Prior to this release, DMA reported backup failure on Cisco Unified CM 4.1.3 to Cisco Unified CM 6.0.1 migration.

CSCsk70423 - Prior to this release, an encrypted password displayed in plain text in DMA trace files.

CSCsj95364 - Prior to this release, DMA did not export users if the profileOwner and userId do not match.

CSCsj94674 - Prior to this release, the need existed for DirExport to export users with an unambiguous numplan.