SNMP Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted Release 9.0(1)
Responding to Alarms
Downloads: This chapterpdf (PDF - 1.14 MB) The complete bookPDF (PDF - 2.1 MB) | The complete bookePub (ePub - 148.0 KB) | Feedback

Responding to Alarms

Responding to Alarms

Unified ICM/CCE Notifications

Notification Mechanism

SNMP notifications are error or warning events generated by component processes and are delivered to a network management station (NMS) via SNMP. The MIB component notification types describe objects which allow for correlating events and for easily identifying the component that generated the event.

SNMP notifications are derived from the event message stream continually being generated by the various Cisco Unified ICM/CCE processes throughout the system. These processes report events of interest to the central database as they occur. Just before being placed in the central database, the event stream is intercepted by a process called the Customer Support Forwarding Service (CSFS) that watches for events of significant interest which should be treated as SNMP notifications.

Most Unified ICM/CCE SNMP notifications are "stateful" in that the notification reports a "raise" or a "clear" state for a given error or warning event. Stateful notifications may or may not require system administrator intervention; often, the Unified ICM/CCE system's fault tolerance features allow the system to recover automatically. Other notifications are "stateless" (e.g. "single-state raise") whereby a "clear" event will not be forthcoming and resolution requires system administrator intervention.

The CSFS process running on the logger generates an event feed to a Cisco SNMP subagent which converts the event data into an SNMP notification in the format defined by a Cisco Unified ICM/CCE MIB. Notifications are defined by the CISCO-CONTACT-CENTER-APPS-MIB.

Event Correlation

Events are sent to the NMS as a series of raises and clears. A single clear can clear multiple raises. Events that relate to each other are given the same correlation ID.

The correlation ID is a combination of the event class name and the event component ID. The component ID (available in the MIB) is a combination of the class name and any substitution strings (arguments) that are passed into it.

To provide an organized view of events you need to create rules in your NMS to map events to a state-based object, using the correlation IDs to associate the events into like groups. When a clear event comes into the NMS you can cancel all previous raises that have the same correlation ID as the clear.

The raises and clears are defined in the file <INSTALL_DRIVE>/icm/snmp/ccca-Notifications.txt, which is found in the SNMP folder of your installation.


Some raises have no automatic clears and must be manually cleared. You should set up an escalation path within your NMS for events that do not have a corresponding clear.

The ccca-Notifications.txt file contains a list of all alarms and each alarm contains an ccaEventState (Raise/Clear) and CorrelationID. Based on CorrelationID, you can determine if a Raise event has a corresponding Clear event or must be manually cleared.

This information is also available as part of the event; RAISE=9 requires a manual Clear and RAISE=4 is an event that has a corresponding Clear.

SNMP Notifications

Unified CCE SNMP subagents are installed and enabled by default. To enable the flow of notifications to the management station, on the Logger node, the installer must first configure a community string (SNMP v1/v2c) or a user name (SNMP v3), and a trap destination. These properties specify security parameters to use for notification transport and the network management station that will receive the Unified CCE notifications.