Cisco Unified CM Serviceability FAQs
Serviceability
SNMP
- What SNMP traps are available for Unified CM in CISCO-CCM-MIB?
- What is the mapping of Unified CM alarms to SNMP traps generated?
- How can the various alarms/traps be artificially generated for development and testing?
Call Detail Records
- What's the best way to transfer CDR files to my server?
- CDR Related Redirect Reason Code for 786, 802, 818, 834 and 850
What are the user roles needed to access the RisPort service?
- Standard CCM Admin Users (provides access to the CCMAdmin domain where RisPort is hosted, but not to the CCMAdmin web UI)
- Standard SERVICEABILITY Read Only (to access risport API)
SNMP
What SNMP traps are available for Unified CM in CISCO-CCM-MIB?
| Trap | Description | |
|---|---|---|
| ccmCallManagerFailed | Signifies that the CallManager process detects a failure in one of its critical subsystems. It can also be detected from a heartbeat/event monitoring process | |
| ccmPhoneFailed | Generated in the intervals specified in ccmPhoneFailedAlarmInterval if there is at least one entry in the ccmPhoneFailedTable | |
| ccmPhoneStatusUpdate | Generated in the intervals specified in ccmPhoneStatusUpdateInterv if there is at least one entry in the ccmPhoneStatusUpdateTable | |
| ccmGatewayFailed | Indicates that at least one gateway has attempted to register or communicate with the CallManager and failed | |
| ccmMediaResourceListExhausted | Indicates that the CallManager has run out a certain specified type of resource | |
| ccmRouteListExhausted | Indicates that the CallManager could not find an available route in the indicated route list | |
| ccmGatewayLayer2Change | Sent when the D-Channel/Layer 2 of an interface in a SCCP gateway that has registered with the CallManager changes state | |
| ccmMaliciousCall | Sent when a user registers a call as malicious with the local Unified CM | |
| ccmQualityReport | Sent when a user reports a quality problem using the Quality Report Tool | |
| ccmTLSConnectionFailure | Sent when CallManager fails to open TLS connection for the indicated device |
What is the mapping of Unified CM alarms to SNMP traps generated?
| Trap | Alarm | |
|---|---|---|
| ccmCallManagerFailed | CallManagerFailure | |
| ccmPhoneFailed | DeviceTransientAlarm for Phone | |
| ccmPhoneStatusUpdate | No specific alarm. Trap sent out on periodic interval if there are any changes to Phone table | |
| ccmGatewayFailed | DeviceTransientAlarm for Gateway | |
| ccmMaliciousCall | MaliciousCall | |
| ccmMediaResourceListExhausted | MediaResourceListExhausted | |
| ccmQualityReportRequest | QRTRequest | |
| ccmRouteListExhausted | RouteListExhausted | |
| ccmGatewayLayer2Change | DChannel OOS/DChannel ISV |
How can the various alarms/traps be artificially generated for development and testing?
- General procedure and validation
- Ensure SNMP Master Agent and Cisco CallManager SNMP Service are activated and running.
- Ensure that Community string/user is configured and should contain Notify permissions as well. (Serviceability web page, SNMP -> v1/v2c or v3 -> Community string or User)
- Ensure that Notification destination is configured. (Serviceability web page, SNMP -> v1/v2c or v3 -> Notification Destination)
- For Phones, ensure ccmPhoneFailedAlarmInterval (1.3.6.1.4.1.9.9.156.1.9.2) and ccmPhoneStatusUpdateAlarmInterv (1.3.6.1.4.1.9.9.156.1.9.4) are set between 30 and 3600
- For Gateways, ensure ccmGatewayAlarmEnable (1.3.6.1.4.1.9.9.156.1.9.6) is set to true
- If traps are still not generated:
- Check if the corresponding alarms are generated: enable alarm and setup the Alarm Event level to 'Informational' for 'Local Syslogs'. (Serviceability web page, Alarm -> Confirguration -> Select Server -> Service Group (CM Services) -> Service (Cisco CallManager))
- Reproduce the traps and check if the corresponding alarm is logged in CiscoSyslog file (either from RTMT or CLI)
- Execute the CLI for the corresponding trap and collect the output accordingly.
- For ccmPhoneFailed trap execute CLI "show risdb query phonefailed"
- For ccmPhoneStatusUpdate trap execute CLI "show risdb query phonestatsupd"
- Traps related to Phones and Gateways (ccmPhoneStatusUpdate, ccmPhoneFailed trap and ccmGatewayFailed trap)
- To trigger ccmPhoneStatusUpdate trap
- Set ccmPhoneStatusUpdateAlarmInterv (1.3.6.1.4.1.9.9.156.1.9.4) = 30 or higher in ccmAlarmConfigInfo mib table
- Select the phone from the CUCM Admin page and RESET it.
- Phones will unregister
- Phones will re-register
- ccmPhoneStatusUpdate trap will be generated
- To trigger ccmPhoneFailed trap
- Set ccmPhoneFailedAlarmInterval (1.3.6.1.4.1.9.9.156.1.9.2) =30 or higher in ccmAlarmConfigInfo mib table
- Make a phone fail: delete a phone from CM and attept to register the phone again.
- Or: configure a 7960 phone MAC as 7940 device and attempt to register
- To trigger GatewayFailed trap
- Remove the configuration of the gateway from the database through Web Admin (or) Change the MAC address of the gateway to some invalid value and update.
- Reboot the gateway
- Or: restart the Cisco CallManager service to which the gateway is connected.
- To trigger GatewayFailed trap (Method 2)
- Set ccmGatewayAlarmEnable=true in ccmAlarmConfigInfo MIB table
- Restart CallManager service which will cause gateway failover to the redundant Unified CM server. On that server, the gateway should not be configured in the database.
- To trigger ccmGatewayLayer2Change trap
- Set ccmGatewayAlarmEnable (1.3.6.1.4.1.9.9.156.1.9.6.0) = true in ccmAlarmConfigInfo MIB table
- Change the MAC address of the gateway to some invalid value and update.
- Reset the Gateway
- Other Traps (MediaResourceListExhausted trap, RouteListExhausted trap, MaliciousCallFailed trap)
- To trigger MediaResourceListExhausted trap
- Create a Media Resource Group (MRG), have it contain an instance of the standard ConferenceBridge resource (CFB-2).
- Create a Media Resource Group List (MRGL), have it contain the MRG just created.
- In the Phone Configuration page for three phones, set MRGL as the phone's Media Resource Group List.
- Stop the IP Voice Media Streaing App which makes the ConferenceBridge resource (CFB-2) stop working.
- Make conference calls with phones that using the media list, you will see "No Conference Bridge available" on the phone screen.
- MediaListExhausted Alarm/Alert/Trap is generated
- To trigger RouteListExhausted trap
- Create a Route Group (RG), have it contains one Gateway
- Create a Route Group List (RGL), have it contains the RG just created
- Create a Route Pattern (9.XXXX) that reroutes a 9XXXX call through the RGL
- Unregister the gateway
- Dial 9XXXX from one of the phones
- RouteListExhausted Alarm/Alert/Trap is generated
- To trigger MaliciousCallFailed trap
- Create a softkey template. In the template, add "MaliciousCall" softkey to the phone's different statuses
- Assign the new softkey template to a phone, reset the phone
- Making a call, select "MaliciousCall" softkey during or after the call
- MaliciousCallFailed Alarm/Alert/Trap is generated
- Receiving Syslog messages as SNMP traps
- To receive syslog messages above a particular severity as traps, set the following 2 MIB objects in clogBasic table:
- clogNotificationsEnabled (1.3.6.1.4.1.9.9.41.1.1.2) -> Set this to true(1) to enable syslog trap notification. Default value is false(2). Eg: snmpset -c <Community String> -v 2c <transmitter ip address> 1.3.6.1.4.1.9.9.41.1.1.2.0 i 1
- clogMaxSeverity (1.3.6.1.4.1.9.9.41.1.1.3) -> Set the severity level above which traps are desired. Default value is warning (5). All syslog messages with alarm severity lesser than or equal to configured severity level will be sent as traps if notification is enabled. Eg: snmpset -c <Community String> -v 2c <transmitter ip address> 1.3.6.1.4.1.9.9.41.1.1.3.0 i <value>
- Limitations are:
- Traps are sent out based on selected severity. If the given alarm is of low severity then the management application needs to set the severity threshold lower to capture this low severity alarm/trap. In other words management apps need to deal with flooding of other low severity traps
- Syslog has a standard buffer size when generating a SNMP trap message; the data is trimmed to the specified field size (255). This avoids any errors caused by data that is too large for the field. For example, if you have specified the message text field to be 255 bytes, but a message arrives that is 300 bytes, the data will be truncated to 255 bytes before being logged.
- Not enabled by default. i.e. by default clogsNotificationEnabled (1.3.6.1.4.1.9.9.41.1.1.2) is set to FALSE (2).
What's the best way to transfer CDR files to my server?
To retrieve individual CDR files as needed, you can easily use CDRonDemand API. However, if you need to retrieve all of the CDR files all of the time, it is recommended to use CDR Repository Manager to directly S/FTP the files to your server without the API. CUCMÕs CDR Repository Manager will keep track of which files have been sent to your server, retry sending files if there is an interruption, and send only files you have not received. The CDRondemand API does not have all of these benefits, so most developers use the CDR Repository Manager instead. Visit CDR Repository Manager to set it up.
CDR Related Redirect Reason Code for 786, 802, 818, 834 and 850
Here are explanation for Redirect Reason Code 786, 802, 818, 834 and 850
- NQ_QUEUE_CALL = 786 Native Call Queuing, queue a call
- NQ_DEQUEUE_CALL = 802 Native Call Queuing, dequeue a call
- NQ_SECONDARY_ROUTING_NO_AGENT_LOGGEDIN = 818 Native Call Queuing, redirect tothe 2nd DN on Hunt Pilot Configuration page.
- NQ_SECONDARY_ROUTING_MAX_QUEUE_DEPETH_FULL = 834 Native Call Queuing, redirect to the 2nd DN on Hunt Pilot Configuration page.
- NQ_SECONDARY_ROUTING_MAX_QUEUING_TIMER_EXPIRE = 850 Native Call Queuing, redirect to the 2nd DN on Hunt Pilot Configuration page.