The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Unified RTMT displays information about predefined system objects in the monitoring pane.
Tip | The polling rate in each precanned monitoring window remains fixed, and the default value specifies 30 seconds. If the collecting rate for the Alert Manager and Collector (AMC) service parameter changes, the polling rate in the precanned window also updates. In addition, the local time of the RTMT client application (not the back-end server) time provides the basis for the time stamp in each chart. For information about service parameters, see the administration online help. |
Tip | To zoom in on the monitor of a predefined object, click and drag the left mouse button over the area of the chart in which you are interested. Release the left mouse button when you have the selected area. RTMT updates the monitored view. To zoom out and reset the monitor to the initial default view, press the R key. |
Unified RTMT displays information about predefined Cisco Unified Communications Manager objects in the monitoring pane when you select Voice/Video in the quick launch channel. The tool monitors the predefined objects on all servers in an cluster, if applicable.
Tip | The polling rate in each precanned monitoring window remains fixed, and the default value specifies 30 seconds. If the collecting rate for the AMC (Alert Manager and Collector) service parameter changes, the polling rate in the precanned window also updates. In addition, the local time of the Unified RTMT client application and not the backend server time, provides the basis for the time stamp in each chart. For more information about service parameters, see the Cisco Unified Communications Manager Administration Guide or Cisco Unity Connection System Administration Guide. |
Tip | To zoom in on the monitor of a predefined object, click and drag the left mouse button over the area of the chart in which you are interested. Release the left mouse button when you have the selected area. Unified RTMT updates the monitored view. To zoom out and reset the monitor to the initial default view, press the R key. |
Voice and Video Summary |
Displays registered phones, calls in progress, and active MGCP ports and channels. To display information about predefined Cisco Unified Communications Manager objects, choose . |
||
Call Process |
|
||
Session Trace |
Displays all SIP message activity: specifically, the incoming and outgoing calls and sessions that pass through the Cisco Unified Communications Manager. Provides associated call flow diagram for each SIP transaction. To display information about Session Trace, choose . |
||
Device |
Device Summary displays information about the Cisco Unified Communications Manager server, including the number of registered phone devices, registered gateway devices, registered other station devices, and registered media resource devices. This includes all servers in the cluster, if applicable. Device Search displays cluster name and device types in a tree hierarchy and allows you to query for information about phones and devices. Phone Summary displays information about the Cisco Unified Communications Manager server, including the number of registered phones, registered SIP phones, registered SCCP phones, partially registered phones, and the number of failed registration attempts. This includes all servers in the cluster, if applicable. To display information about the number of registered phones, gateways, and media resource devices on Cisco Unified Communications Manager, choose .
|
||
Service |
|
||
CTI |
Displays information about the devices and applications that interfaces with the CTI Manager. To display information about CTI Applications, choose .To monitor specific CTI types, you must perform additional configuration steps. See topics related to monitoring CTI applications, devices, and lines. |
||
Intercompany Media Services |
|
In a single monitoring pane, Unified RTMT allows you to monitor information about a Cisco Unified Communications Manager server or about all servers in a cluster (if applicable). In the CallManager Summary window, you can view information about the following predefined objects:
The Call Process monitoring category monitors the following items:
Call Activity: You can monitor the number of attempted calls, completed calls, in-progress calls, and logical partition total failures for a particular server or for an entire cluster (if applicable).
Gateway Activity: You can monitor gateway activity for each gateway type. Gateway activity monitoring includes the number of active ports, the number of ports in service, and the number of calls that were completed for each gateway type for a particular server or for an entire cluster (if applicable).
Trunk Activity: The system monitors trunk activity by trunk type for a particular server or for an entire cluster (if applicable). Trunk activity monitoring includes the number of calls in progress and the number of calls that were completed for a particular trunk type.
SDL Queue: SDL queue monitoring monitors the number of signals in the SDL queue and the number of signals that were processed for a particular signal distribution layer (SDL) queue type. The SDL queue types comprise high, normal, low, and lowest queue. You can monitor the SDL queue for a particular server or for an entire cluster (if applicable).
SIP Activity: The system displays a summary of SIP requests, SIP responses, total number of failed incoming responses (4xx, 5xx, and 6xx), total number of failed outgoing responses (4xx, 5xx, and 6xx), number of retry requests, and number of retry responses.
Session Trace: You can search or trace the calls based on the following criteria: Calling Number/URI, Called Number/URI, Start Time, and Duration. RTMT downloads the Call Log file(s) that include the Start Time and Duration, search for the matching calls, list the matching call records, and provide the Call Flow Diagram.
The following table provides information about the call processing objects that RTMT monitors, the alert, thresholds, and defaults. For information about call activity daily reports, see the Cisco Unified Serviceability Administration Guide.
CallsAttempted, CallsCompleted, CallsInProgress, and Logical Partition Failures Total for each server and cluster (if applicable). |
|
CallsAttempted, CallsCompleted, and CallsInProgress of each type of MGCP FXS/FXO/PRI/T1CAS/H.323 gateway, as well as SIP and H.323 Trunks for each server and cluster (if applicable). |
|
MGCP FXS Gateway: Number of In-Service and Active ports for each server and cluster (if applicable). |
|
MGCP FXO Gateway: Number of In-Service and Active ports for each server and cluster (if applicable). |
|
MGCP PRI Gateway: Number of In-Service and Active channels for each server and cluster (if applicable). |
|
MGCP T1CAS Gateway: Number of In-Service and Active ports for each server and cluster (if applicable). |
The system accumulates call-processing data in the memory whenever Unified RTMT calls the LogCall API. Every 5 minutes, Unified RTMT logs the data into the file as a single record and cleans the memory.
The system logs data every 5 minutes for the following counters on the basis of the following calculation:
cmCallsAttempted: Cumulative (difference between last collected value and the first collected value in last 5 minutes)
cmCallsCompleted: Cumulative (difference between last collected value and the first collected value in last 5 minutes)
cmCallsInProgress: Average of all the values that were collected in last 5 minutes
gwMGCP_FXS_CallsCompleted: Cumulative (difference between last collected value and the first collected value in last 5 minutes)
gwMGCP_FXO_CallsCompleted: Cumulative (difference between last collected value and the first collected value in last 5 minutes)
gwMGCP_PRI_CallsCompleted: Cumulative (difference between last collected value and the first collected value in last 5 minutes)
gwMGCP_T1_CAS_CallsCompleted: Cumulative (difference between last collected value and the first collected value in last 5 minutes)
gwH323_CallsAttempted: Cumulative (difference between last collected value and the first collected value in last 5 minutes)
gwH323_CallsInProgress: Average of all the values that were collected in last 5 minutes
gwH323_CallsCompleted: Cumulative (difference between last collected value and the first collected value in last 5 minutes)
trunkH323_CallsAttempted: Cumulative (difference between last collected value and the first collected value in last 5 minutes)
trunkH323_CallsInProgress: Average of all the values collected in last 5 minutes
trunkH323_CallsCompleted: Cumulative (difference between last collected value and the first collected value in last 5 minutes)
trunkSIP_CallsAttempted: Cumulative (difference between last collected value and the first collected value in last 5 minutes)
trunkSIP_CallsInProgress: Average of all the values that were collected in last 5 minutes
trunkSIP_CallsCompleted: Cumulative (difference between last collected value and the first collected value in last 5 minutes)
gwMGCP_FXS_PortsInService: Average of all the values that were collected in last 5 minutes
gwMGCP_FXO_PortsInService: Average of all the values that were collected in lasts 5 minutes
gwMGCP_PRI_SpansInService: Average of all the values that were collected in last 5 minutes
gwMGCP_T1_CAS_SpansInService: Average of all the values that were collected in last 5 minutes
gwMGCP_FXS_ActivePorts: Average of all the values that were collected in last 5 minutes
gwMGCP_FXO_ActivePorts: Average of all the values that were collected in last 5 minutes
gwMGCP_PRI_ActiveChannels: Average of all the values that were collected in last 5 minutes
gwMGCP_T1_CAS_ActiveChannels: Average of all the values that were collected in last 5 minutes
The AMC service logs the call data in windows Performance tool-compatible CSV format. The header of the log comprises the time zone information and a set of columns with the previously listed counters for the server. These sets of columns repeat for every server in a cluster, if applicable.
The following filename format of the Call Log applies: CallLog_MM_DD_YYYY_hh_mm.csv.
Cisco Unified Communications Manager captures and logs all SIP message activities, which comprise the incoming and outgoing calls or sessions that pass through it. Unified Communications Manager stores the messages on a per-transaction basis in a new Call Log file, which can be downloaded through RTMT for postprocessing activity.
RTMT users can search or trace the calls based on the following criteria:
RTMT downloads the Call Log file that includes the Start Time and Duration. The tool searches for the matching calls, lists the matching call records, and provides the SIP message Call Flow Diagram.
You can also save the call logs on your local system. Based on the saved call logs, RTMT can search for the matching calls, list the matching records, and provide SIP Message Call Flow Diagrams.
Follow this procedure to monitor real-time data using RTMT.
Note | You can search calls based on the following criteria: Calling Number/URI, Called Number/URI, Start Time, and Duration. The search applies to the entire Unified Communications Manager cluster, not just the local node. If any node fails to collect the trace files, the system displays an error message in the bottom panel and pops up the message prompt to the user. |
Note | In Calling Number/URI, Called Number/URI, you can use wildcard character "*" to match any number of characters. For example, a search for 123* fetches numbers like 123, 1234, or 123456. If you want to search for numbers with a "*" in them, use "\*". For example, to search for a Called Number like 12*45, enter 12\*45 in the search box. |
Step 1 | To display information about Session Trace, from the RTMT menus, choose . The Real Time Data screen appears. | ||||
Step 2 | Enter the search criteria and Click Run. Click Yes to ignore the error and generate the table, based on the input. If matching calls are found, the Matching Call pane displays Start Time, Calling DN, Original Called DN, Final Called DN, Calling Device Name, Called Device Name, and Termination Cause Code.
After the call records are displayed in the Matching Calls pane, you can trace calls.
|
Follow this procedure to monitor session trace data from the logs that are saved on your local disk:
Step 1 | From the RTMT menus, choose . The Open from Local Disk screen appears. | ||||||
Step 2 | In the File Location field, specify the directory where the call log files are saved on your local disk. You can click Browse to specify the directory path. | ||||||
Step 3 | Check the Enable Time Based Search check box to view call records for a specific duration. If you check this check box, you can specify the duration in Duration field. If you do not check this check box, you will not be able to specify the duration. In such cases, all the calls from the specified Start Time that are present in the saved log files will be displayed. | ||||||
Step 4 | Enter the search criteria and click Run.
If matching calls are found, the Matching Call pane displays Start Time, Calling DN, Original Called DN, Final Called DN, Calling Device Name, Called Device Name, and Termination Cause Code.
|
Follow this procedure to trace call records displayed as per the specified search criteria.
Note | Use this procedure along with "Monitor real-time data" and "Monitor session trace data from local disk." |
Step 1 | Select a call (a row) to trace. By default, the Include SIP Message check box is selected to view the associated SIP protocol messages or call transactions. | ||||||||||||||||||||||
Step 2 | To generate the SIP Message Call Flow Diagram, click Trace Call. If you want to stop the generation of the session information, click Cancel on the progress window. The Analyze Call Diagram window displays the corresponding SIP messages in the Call Flow Diagram. | ||||||||||||||||||||||
Step 3 | Click the tabs that you want to view. The following tabs are available: | ||||||||||||||||||||||
Step 4 | Move your mouse over the SIP messages in the Call Flow Diagram. The following table lists the details that are displayed:
Detailed SIP Message: Appears only when the Include SIP Message check box is checked. Displays the actual SIP message that is logged into the SDL log file. Message in Log File: Displays the log file which contains the message. To view the SIP messages that get logged into the SDL log file, perform the following actions:
| ||||||||||||||||||||||
Step 5 | Click Save. If you are monitoring real-time data, the Call Flow Diagram is saved as index.html in the specified folder along with the SDL files which contain the SIP messages. You can email the files to the Technical Assistance Center (TAC). For more information on monitoring real-time data, see "Monitor real-time data." The SIP messages in the saved Call Flow Diagram appear as hyperlinks. When you click a SIP message, the detailed SIP message along with the following details is displayed in a new window.
If you open logs for Cisco Unified Communications Manager 8.5(1) or 8.6(1) using Open from Local Disk option and save the ladder diagram , the SIP messages, the SDI log files that contain the SIP messages and SDL Log files for a duration of from 5 minutes before the start of the call to 5 minutes after the start of the call will be saved. If you save logs from Cisco Unified Communications Manager 9.0(1) or later, the SDL log files that contain the call details are saved along with index.html and the SIP messages. For more information about monitoring the session trace data from the logs saved to your local disk, see "Monitor session trace data from local disk."
You can perform the following actions: The Session Manager logs the call data in new log files. These new log files are located in the following folder: /var/log/active/cm/trace/ccm/calllogs/. The Call Log name has the following filename pattern: calllogs_dddddddd.txt.gz. Detailed SIP messages are logged into SDI traces. The Call Logs include the following message types:
The following limitations apply when the Call Flow Diagram is generated:
SIP messages exchanged in Step b are not displayed in the Call Flow Diagram In these cases, a RELEASE message is logged in the call logs without a corresponding SETUP message. |
The Service monitoring category monitors the activities of Cisco TFTP requests, database activities, and heartbeat of the server or of different servers in a cluster (if applicable).
The Cisco TFTP service builds and serves files that are consistent with the Trivial File Transfer Protocol, which is a simplified version of the File Transfer Protocol (FTP). Cisco TFTP builds configuration files and serves embedded component executables, ringer files, and device configuration files. You can view the total Cisco TFTP requests, requests not found, and requests that were aborted.
Unified RTMT monitors the heartbeat of Cisco Unified Communications Manager and Cisco TFTP services for the server or for different servers in a cluster (if applicable). The heartbeat acts as an indicator of the life of whatever it is monitoring. When the heartbeat is lost, a blinking icon appears in the lower right corner of the RTMT window. To find when the heartbeat loss was detected, click the blinking icon. An email can notify you of the heartbeat loss, if you configure the system to do so.
The database summary provides connection information for the server or for each server in a cluster (if applicable), such as the change notification requests that are queued in the database, change notification requests that are queued in memory, the total number of active client connections, the number of devices that are queued for a device reset, replicates created, and replication status.
For information about daily reports for CTI and Cisco TFTP usage statistics, see the Cisco Unified Serviceability Administration Guide.
Number of open devices, lines, CTI connections, and active Cisco Unified Communications Manager links for each CTI Manager. |
|
TotalTftpRequests and TotalTftpRequestsAborted for each Cisco TFTP server. |
|
Connection and replication status for each Directory server. |
|
The service data accumulates in the memory whenever RTMT calls the LogService API. Every five minutes, RTMT logs the data into the file as a single record and cleans the memory.
The system logs data every five minutes for the following counters, based on the following calculation:
ctiOpenDevices: Average of all the values that were collected in last five minutes
ctiLines: Average of all the values that were collected in last five minutes
ctiConnections: Average of all the values that were collected in last five minutes
ctiActiveCMLinks: Average of all the values that were collected in last five minutes
tftpRequests: Cumulative (difference between last collected value and the first collected value in last five minutes)
tftpAbortedRequests: Cumulative (difference between last collected value and the first collected value in last five minutes)
The AMC service logs the service data in csv format. The header of the log comprises the time zone information and a set of columns with the counters that were previously listed for a server. These sets of columns repeat for every server in a cluster, if applicable.
The following filename format of the Service Log applies: ServiceLog_MM_DD_YYYY_hh_mm.csv.
The device data accumulates in the memory whenever RTMT calls the LogDevice API. Every five minutes, RTMT logs the data into the file as a single record and cleans the memory.
The data is logged every five minutes for the following counters based on the following calculation:
gatewayDevicesFXS: Average of all the values that were collected in last 5 minutes
gatewayDevicesFXO: Average of all the values that were collected in last 5 minutes
gatewayDevicesPRI: Average of all the values that were collected in last 5 minutes
gatewayDevicesT1: Average of all the values that were collected in last 5 minutes
gatewayDevicesH323: Average of all the values that were collected in last 5 minutes
The AMC service logs the device data in CSV format. The header of the log comprises the time zone information and a set of columns with the previously listed counters for a server. These sets of columns repeat for every server in a cluster, if applicable.
The following filename format of the Device Log applies: DeviceLog_MM_DD_YYYY_hh_mm.csv.
The Device monitoring category provides a summary of devices, device search capability, and a summary of phones.
For information about daily reports on registered devices, see the Cisco Unified Serviceability Administration Guide.
Number of registered phones for each server or for all servers in a cluster (if applicable). |
Total number of registered phones drops by X% in consecutive polls. Default specifies 10%. |
Number of registered gateways on each server or for all servers in a cluster (if applicable). |
|
Number of registered media devices on each server or for all servers in a cluster (if applicable). |
The Device Search menu comprises the following items on which you can search: phones, gateway devices, H.323 devices, CTI devices, voice-messaging devices, media resources, hunt lists, and SIP trunks.
You can search on any device in the Unified Communications Manager system and choose the status of the devices, including registered, unregistered, rejected, any status, and devices that are only configured in the database. You can also search by any model, or a specific device model, and set up criteria that include several different attributes. Within the phone search, you can also search on the basis of phone protocol.
Unified RTMT queries RIS to find the matching device. Results display in a table with a row for each matched device, a column for each of the specified attributes, and a time stamp of the device that has been opened or closed and the application that controls the device media.
If you have Unified Communications Manager clusters and you search for a device by choosing the Any Status option, Unified RTMT does not display a snapshot of the matched device type, but rather it displays data for that device type from the RIS database for all specified Unified Communications Manager servers for a period of time. As a result, you may see multiple entries of a device with multiple statuses (for example, Registered or Unregistered) in Unified RTMT.
When you see multiple entries of a device, the current status of the device reflects the entry that has the latest time stamp. By configuring the RIS Unused Cisco CallManager Device Store Period service parameter for the Cisco RIS Data Collector service in Cisco Unified Communications Manager Administration, you can configure the period of time that the RIS database keeps information on unregistered or rejected device. See the Cisco Unified Communications Manager Administration Guide for more information about configuring service parameters.
Tip | To find the matching item, Unified RTMT requires that you activate the Cisco RIS Data Collector service in the Service Activation window. |
Results display in a table with a row for each matched device, a column for each of the specified attributes, and a time stamp of the device that has been opened or closed and the application that controls the device media.
The phone summary provides information about the number of registered phones, phones that are running SIP, phones that are running SCCP, partially registered phones, and the number of failed registration attempts.
Follow this procedure to monitor data for the following device types:
Step 1 | Perform one of
the following tasks:
| ||
Step 2 | To find all devices or to view a complete list of device models from which you can choose, right-click the cluster name and choose Monitor. | ||
Step 3 | To monitor a
specific device type, right-click or double-click the device type from the tree
hierarchy.
| ||
Step 4 | In the Select device with status window, click the radio button that applies. | ||
Step 5 | In the drop-down
list box next to the radio button that you clicked, choose
Any
CallManager or a specific
Cisco Unified Communications
Manager server for which you want the device information to display.
| ||
Step 6 | Click the Next > button. | ||
Step 7 | In the Select Device with Download Status pane, click the radio button that applies, and click Next. | ||
Step 8 | In the Search by
device model pane, click the radio button that applies.
| ||
Step 9 | Click Next. | ||
Step 10 | In the Search
with name pane, click the radio button that applies and enter the appropriate
information in the corresponding fields, if required.
| ||
Step 11 | Click Next. | ||
Step 12 | In the Monitor following attributes pane, check one or all of the search attributes. | ||
Step 13 | Click
Finish.
|
You can view information about phones that display in the RTMT device monitoring pane. This section describes how to view phone information.
Step 1 | Find and display the phone in the RTMT device monitoring pane. |
Step 2 | Perform one of the following tasks: |
Step 3 | In the Select Device with Status pane, click the radio button that applies. |
Step 4 | In the drop-down list box next to the radio button that you clicked, choose Any CallManager or a specific Cisco Unified Communications Manager server for which you want the device information to display. |
Step 5 | In the Search By Device Model pane, choose the phone protocol that you want to display. |
Step 6 | Click the Any Model or Device Model radio button. If you click the Device Model radio button, choose a phone model that you want to display. |
Step 7 | Click Next. |
Step 8 | In the Search With Name pane, click the radio button that applies and enter the appropriate information in the corresponding fields. |
Step 9 | In the Monitor following attributes pane, check one or all of the search attributes. |
Step 10 | Click Finish. The Device Information window appears. For more information about the device, choose any field that appears in the left pane of the window. |
You can view the properties of devices that appear in the RTMT device monitoring pane. Follow this procedure to view device properties.
Cisco Unified Communications Manager polls counters, devices, and gateway ports to gather status information. In the RTMT monitoring pane, you configure the polling intervals for the performance monitoring counters and devices.
Note | High-frequency polling rate may adversely affect Cisco Unified Communications Manager performance. The minimum polling rate for monitoring a performance counter in chart view is 5 seconds; the minimum rate for monitoring a performance counter in table view is 1 second. The default value for both is 10 seconds. |
Note | The default value for devices is 10 minutes. |
The CTI category monitors CTI Manager activities and provides CTI search capability. With CTI Manager, you can monitor the number of open devices, lines, and CTI connections.
You can specify criteria for the CTI applications, devices, and lines that include CTI status, device name, application pattern, and attributes.
Tip | To find the matching item, RTMT requires that you activate the Cisco RIS Data Collector service in the Service Activation window in Cisco Unified Serviceability. |
Results display in a table with a row for each matched device, a column for each of the specified attributes, and a time stamp of the device that has been opened or closed and the application that controls the device media.
Follow this procedure to display a chart of open devices, lines, and CTI connections for each server or for each server in a cluster (if applicable).
Perform the following procedure to find specific CTI applications to monitor:
Step 1 | Perform one of the following tasks: | ||
Step 2 | From the CTI Manager drop-down list box, choose the CTI Manager that you want to monitor. | ||
Step 3 | From the Applications Status drop-down list box, choose the application status. | ||
Step 4 | Click Next. | ||
Step 5 | In the Application Pattern pane, click the radio button that applies. | ||
Step 6 | Enter the
information in the field for the radio button that you clicked; for example, if
you clicked the
IP
Subnet radio button, enter the IP address and the subnet mask in
the field.
| ||
Step 7 | Click Next. | ||
Step 8 | In the Monitor following attributes window, check one or all of the check boxes for the attributes that you want to monitor. | ||
Step 9 | Click
Finish.
The applications monitoring pane displays the information that you choose. |
Follow this procedure to find specific CTI devices to monitor.
Step 1 | Perform one of
the following tasks:
| ||
Step 2 | From the CTI Manager drop-down list box, choose the CTI Manager that you want to monitor. | ||
Step 3 | From the Devices Status drop-down list box, choose the device status. | ||
Step 4 | In the Devices
pane, click the radio button that applies.
| ||
Step 5 | Click Next. | ||
Step 6 | In the Application Pattern window, click the radio button that applies. | ||
Step 7 | Enter the
information in the field for the radio button that you clicked; for example, if
you clicked
IP
Subnet, enter the IP address and subnet mask in the field.
| ||
Step 8 | Click Next. | ||
Step 9 | In the Monitor following attributes window, check one or all check boxes for the attributes that you want to monitor. | ||
Step 10 | Click
Finish.
The devices monitoring pane displays the information that you chose. |
Follow this procedure to find specific CTI lines to monitor.
Step 1 | Perform one of
the following tasks:
| ||
Step 2 | From the CTI Manager & Status drop-down list box, choose the CTI manager that you want to monitor. | ||
Step 3 | From the Lines Status drop-down list box, choose the status. | ||
Step 4 | In the Devices
pane, click the radio button that applies.
| ||
Step 5 | In the Lines
pane, click the radio button that applies:
| ||
Step 6 | Click Next. | ||
Step 7 | In the Application Pattern pane, click the radio buttons apply: | ||
Step 8 | Enter the
information in the field for the radio button that you clicked; for example, if
you clicked
IP
Subnet, enter the IP address and subnet mask in the field.
| ||
Step 9 | Click Next. | ||
Step 10 | In the Monitor following attributes window, check one or all check boxes for the attributes that you want to monitor. | ||
Step 11 | Click
Finish.
The lines monitoring pane displays the information that you choose. |
You can view the application information for selected devices such as the Cisco Unified IP Phone, CTI port, and CTI route point. Follow this procedure to view application information.
Step 1 | Find and display the devices in the RTMT monitoring pane. |
Step 2 | Perform one of the following tasks:
The Application Information window displays the CTI manager server name, application ID, user ID, application IP address, application status, app time stamp, device time stamp, device name, and CTI device open status. |
Step 3 | To view updated information, click Refresh. To close the window, click OK. |
Learned Pattern reports and Service Advertisement Framework (SAF) forwarder reports support the Call Control Discovery feature. When you configure the call control discovery feature, Cisco Unified Communications Manager advertises itself and its hosted DN patterns to other remote call-control entities that use the SAF network. Likewise, these remote call-control entities advertise their hosted DN patterns, which Unified Communications Manager can learn and insert in digit analysis. For more information about the call control discovery feature, see "Call Control Discovery" in the Cisco Unified Communications Manager Features and Services Guide.
Note | The learned pattern may be repeated in the report because the learned pattern may be coming from a different source; for example, it may be coming from a different IP address. |
Column |
Description |
---|---|
Pattern |
Displays the name of the learned pattern from the remote call-control entity. |
TimeStamp |
Displays the date and time that the local Unified Communications Manager marked the pattern as a learned pattern. |
Status |
Indicates whether the learned pattern was reachable or unreachable |
Protocol |
Displays the protocol for the SAF-enabled trunk that was used for the outgoing call to the learned pattern; if the remote call-control entity has QSIG tunneling configured for the SAF-enabled trunk, the data indicates that QSIG tunneling was used; for example, EMCA is listed along with H.323 in this column. |
AgentID |
Displays the name of the remote call-control entity that advertised the learned pattern |
IP Address |
Displays the IP address for the call control entity that advertised the learned pattern; Displays the port number that the call-control entity uses to listen for the call. |
ToDID |
Displays the PSTN failover configuration for the learned pattern. |
CUCMNodeId |
Displays the ID from the local Unified Communications Manager node. |
Column |
Description |
---|---|
Name |
Displays the name of the SAF forwarder that you configured in the SAF Forwarder Configuration window in Cisco Unified Communications Manager Administration. |
Description |
Displays the description for the SAF forwarder that you configured in the SAF Forwarder Configuration window in Cisco Unified Communications Manager Administration. If None displays, you did not enter a description for the SAF forwarder. |
IP Address |
Displays the IP address for the SAF forwarder, as configured in the SAF Forwarder Configuration window in Cisco Unified Communications Manager Administration. |
Port |
Indicates the port number that Cisco Unified Communications Manager uses to connect to the SAF forwarder; by default, Unified Communications Manager uses 5050. |
Type |
Indicates whether the SAF forwarder is classified as the primary or backup SAF forwarder. |
Connection Status |
Indicates whether Unified Communications Manager can connect to the SAF forwarder. |
Authentication Type |
Indicates that Cisco Unified Communications Manager used digest authentication to connect to the SAF forwarder. |
Registration Status |
Indicates whether the Cisco Unified Communications Manager is registered to the SAF forwarder. |
Time Last Registered |
Displays the date and time when the Unified Communications Manager last registered with the SAF forwarder. |
No of Registered Applications |
Displays the total number of CCD advertising and requesting services that are registered to the SAF forwarder. |
No of Connection Re-Attempts |
Displays the number of times that the call-control entity, in this case, the Unified Communications Manager, has attempted to connect to the SAF forwarder. |
RTMT allows you to search based on different criteria; for example, if you specify a search for the remote call-control entity, all the learned patterns display for the remote call-control entity.
To access the Learned Patterns or SAF Forwarder reports in RTMT, perform the following procedure.
Step 1 | To access the report, perform one of the following actions: |
Step 2 | Choose the
node from the
Select
a Node drop-down list box.
For learned pattern reports, if the Cisco CallManager Service is running but the CCD requesting service is not running on that node, a message displays that the CCD Report Service is not working after you choose the node. If the CCD requesting service is not active on the node that you choose, the report displays as empty. |
Step 3 | Review the
data in the report.
See the Data from Learned Pattern Report table and the Data from SAF Forwarder Report table for descriptions of the items that were reported. |
Step 4 | After the data appears, if you want to filter the results based on specific criteria, click the Filter button; specific the criteria that you want to search, click Apply and then OK. |
Step 5 | To display the most current results, click Refresh. |
Step 6 | If you want to search on a specific string in the data, click the Find button, enter the string, then, click Find Next. |
Step 7 | If you want to save the results, click Save, and choose either XML or Text, depending on how you want to save the results. Browse to the location where you want to save the data, name the file that you want to save; then, click Save. |
Called Party Trace allows you to configure a directory number or list of directory numbers that you want to trace. You can request on-demand tracing of calls using the Session Trace Tool.
The Called Party Trace feature provides information on the calling party number in addition to the called party number within a node. You can use the information from each node to trace a call back to the originator.
Note | You must be an authorized administrator to access the directory number logs. To grant authorization to a specific role using MLA, the "Called Party Tracing" resource must have read permission enabled for the role. |
To access the Called Party Trace report in the Real-Time Monitoring Tool, follow these steps:
Step 1 | From the RTMT menu, choose Voice/Video tab; then, click Called Party Trace. . Or, Click the | ||
Step 2 | Select the start time of the report using the drop-down box.
| ||
Step 3 | The report shows the following information:
|
The IME Service category monitors the following items:
Network Activity: Displays the activity on the Cisco Unified Communications Manager that relates to Cisco Intercompany Media Engine. The Network Activity object displays these charts:
IME Distributed Cache Health: Displays the health of the IME distributed cache based on the IMEDistributedCacheHealth counter for the IME Server performance object.
IME Distributed Node Count: Displays an approximation of the number of nodes in the IME distributed cache, based on the value of the IMEDistributedCacheNodeCount counter for the IME Server performance object. Because each physical Cisco Intercompany Media Engine server contains multiple nodes, the number that displays in the chart does not indicate the number of physical Cisco Intercompany Media Engine servers that participate in the IME distributed cache.
Internet BW Received: Displays the amount of bandwidth in Kbits/s that the Cisco IME service uses for incoming Internet traffic and represents the InternetBandwidthRecv counter for the IME Server performance object.
Internet BW Send: Displays the amount in Kbits/s that the Cisco IME service uses for outgoing Internet traffic and represents the InternetBandwidthSend counter for the IME Server performance object.
IME Distributed Cache Stored Data Records: Displays the number of IME Distributed Cache records that the Cisco Intercompany Media Engine server stores and represents the IMEDistributedCacheStoredData counter for the IME Server performance object.
To display information about network activity, choose
.Server Activity: Allows you to monitor the activity on the Cisco Intercompany Media Engine server. The Server Activity object displays these charts:
Number of Registered Clients: Displays the current number of clients that connect to the Cisco IME service and represents the value of the ClientsRegistered counter for the IME Server performance object.
IME Distributed Cache Quota: Indicates the number of individual DIDs that can be written into the IME Distributed Cache, by Cisco Cisco Unified Communications Managers attached to this IME server. This number is determined by the overall configuration of the IME Distributed Cache, and the IME license installed on the IME server.
IME Distributed Cache Quota Used: Indicates the total number of unique DID numbers that have been configured, to be published through enrolled patterns for Intercompany Media Services, by Cisco Cisco Unified Communications Managers currently attached to this IME server.
Terminating VCRs: Indicates the total number of IME voice call records that are stored on the Cisco IME server for the terminating side of a call. These records can be used for validation of learned routes.
Validations Pending: Displays the number of pending validations on the Cisco IME service as well as the threshold for validations. This chart represents the ValidationsPending counter for the Cisco IME Server performance object.
To display information about server activity, choose
.The IME System Performance monitoring category provides the SDL Queue object that monitors the number of signals in the SDL queue and the number of signals that were processed for a particular signal distribution layer (SDL) queue type. The SDL queue types comprise high, normal, low, and lowest queue. You can monitor the SDL queue for a particular server or for an entire cluster (if applicable).
To display information about the SDL Queue, choose . Select the type from the SDL Queue Type drop-down list box.
Tip | The polling rate in each precanned monitoring window remains fixed, and the default value specifies 30 seconds. If the collecting rate for the AMC (Alert Manager and Collector) service parameter changes, the polling rate in the precanned window also updates. In addition, the local time of the RTMT client application, not the back end server time, provides the basis for the time stamp in each chart. |
Tip | To zoom in on the monitor of a predefined object, click and drag the left mouse button over the area of the chart that interests you. Release the left mouse button when you have the selected area. RTMT updates the monitored view. To zoom out and reset the monitor to the initial default view, press the R key. |
The Intercompany Media Services monitoring category monitors the following items:
Routing: Displays the total number of Cisco Intercompany Media Engine routes that Cisco Unified Communications Manager maintains. This total includes the following routes:
Learned routes that represent the phone numbers that the Cisco Intercompany Media Engine client learned and that exist in the Cisco Unified Communications Manager routing tables
Unique domains of peer enterprises for which Cisco Intercompany Media Engine routes exist
Published routes that represent the number of direct inward dialing numbers (DIDs) that were published successfully to the IME distributed hash table across all Cisco Intercompany Media Engine services
Rejected routes that represent the number of learned routes that were rejected because the administrator blocked them.
These charts represent the following performance counters for the Cisco IME Client performance object: RoutesLearned, DomainsUnique, RoutesPublished, and RoutesRejected.
To display information about routing, choose
.Call Activities: Allows you to monitor the total number of Cisco Intercompany Media Engine calls. This total includes the following types of calls:
Calls that were attempted (including calls that were accepted, busy, no answer, and failed)
Calls that were received
Calls that were set up (that is, made by Cisco Unified Communications Manager and accepted by the remote party)
Calls that were accepted (that is, received by Cisco Unified Communications Manager and answered by the called party)
Calls that completed fallback to the PSTN
Calls that did not successfully fall back to the PSTN.
These charts represent the following performance counters for the Cisco IME Client performance object: CallsAttempted, CallAccepted, CallsReceived, CallsSetup, IMESetupsFailed, and FallbackCallsFailed.
To display information on call activities, choose
.The Real-Time Monitoring Tool provides a set of important performance counters that assist you in monitoring the overall performance of the IM and Presence service and Cisco Jabber. The IM and Presence and Cisco Jabber summaries in RTMT allow you to monitor important common information in a single monitoring pane.
To display information on important performance counters that reflect the overall performance of IM and Presence and Cisco Jabber, select or .
Under IM and Presence Summary, review the following information:
PE Active JSM Sessions
XCP JSM IM Sessions
Total IMs Handled
Current XMPP Clients Connected
Total Ad hoc Chat Rooms
Total Persistant Chat Rooms
Under Cisco Jabber Summary, review the following information:
View the current number of XMPP clients connected to the Cisco XCP Connection Manager on an individual IM and Presence server. This number should rise and fall based on the usage patterns of your deployment. Further investigation may be required if this number is higher than expected for your user base.
View the current number of CAXL web clients connected to the Cisco XCP Web Connection Manager on an individual IM and Presence server. This number should rise and fall based on the usage patterns of your deployment. Further investigation may be required if this number is higher than expected for your user base.
View the current number of active outgoing SIP Subscriptions being maintained by the Cisco XCP SIP Federation Connection Manager service on the IM and Presence server. Monitor this counter if IM and Presence server is configured for SIP Interdomain Federation or SIP Intradomain Federation.
Note | The total combined count of SIPS2SSubscriptionsOut and SIPS2SSubscriptionsIn must not rise above 260,000 on any single IM and Presence server. |
View the current number of active inbound SIP Subscriptions being maintained by the Cisco XCP SIP Federation Connection Manager service on the IM and Presence server. Monitor this counter if IM and Presence server is configured for SIP Interdomain Federation or SIP Intradomain Federation.
Note | The total combined count of SIPS2SSubscriptionsOut and SIPS2SSubscriptionsIn must not rise above 260,000 on any single IM and Presence server. |
This counter gives the total number of IM sessions on the IM and Presence node across all users. The Presence Engine (PE), which provides presence composition services and rich, always-on, network presence, creates an IM session on behalf of all users at PE start-up time. This is necessary so that network presence events such as Cisco Unified Communications Manager Telephony Presence and Exchange Calendar notifications are reflected in a user's presence even if that user is not logged in to any IM clients.
Every licensed user on a IM and Presence node has one IM Session for Presence Engine rich presence composition in addition to one IM Session for any logged in clients.
This counter gives the total number of IM packets handled by the IM and Presence node across all users.
Note that if user Alice sends an IM to user Bob, and both users are assigned to the same IM and Presence node, then this IM packet will be counted twice. This is because the XCP Router and Jabber Session Manager treat the two users separately. For example, Alice's privacy rules will be applied to the IM packet before it is delivered to Bob, and then Bob's privacy rules will be applied to the IM packet before it is delivered to Bob's client. Whenever IM and Presence handles an IM packet it is counted once for the originator and once for the terminator.
If Alice and Bob are assigned to different IM and Presence nodes and Alice sends an IM packet to Bob, then the IM will be counted once on Alice's node and once on Bob's node.
This counter gives the total number of IM packets handled by the IM and Presence node across all users in the past 60 seconds. This counter is reset to 0 every 60 seconds. The same rules for counting IM packets apply as for JsmTotalMessagePackets. Monitoring of this counter will help identify the busy IM hours in your organization.
These per session counters only exist for the duration of an IM session or user login. One set of these counters exists for each Presence Engine network presence session, and one set of these counters exists for each client login session. In the example given above for the IMSessions counters, there are 160 different sets of Cisco XCP JSM Session Counters. When a user logs out, or when the Presence Engine is stopped, the associated Cisco XCP JSM Session Counters instance is deleted.
You can use the Cisco XCP JSM Session counters to get a snapshot of all users currently logged in. These counters can be accessed from the CLI using the following command:
admin: show perf list instances "Cisco XCP JSM Session Counters"
Every user assigned to an IM and Presence node that is logged into the system will have a set of JSM session counters for their current logged in client session and also their Presence Engine network session. On an IM and Presence node with 5000 users logged in this would result in a minimum of 10,000 sets of JSM Session counters. Updating these counters with new values as they change would place the system under stress. To combat this, JSM Session counter values are cached locally by the system and only updated to RTMT every 30 minutes.
This counts the total number of IM packets sent by the user from his IM client or session. Note that the terminology JsmSessionMessagesIn is used as from the perspective of the IM and Presence server, the IM packet sent by the client is an inbound IM packet to IM and Presence.
This counts the total number of IM packets sent to the user on his IM client or session. Note that the terminology SessionMessagesOut is used as from the perspective of the IM and Presence server, the IM packet is sent to the client and is an outbound IM packet from IM and Presence.
Note | JsmTotalMessagePackets, JsmMsgsInLastSlice, JsmSessionMessagesIn and JsmSessionMessagesOut each represent instant message packets being sent to IM and Presence and are not exact figures of Instant Messages on the system. The amount of IM packets sent to IM and Presence per IM can vary depending on the client in use. |
This counter represents the total number of Text Conferencing rooms hosted on the node. This includes both ad hoc rooms and persistent chat rooms.
This counter represents the total number of AdHoc chat rooms currently hosted on the node. Note that AdHoc chat rooms are automatically terminated when all users leave the room, so this counter should rise and fall in value regularly.
This counter represents the total number of persistent chat rooms hosted on the node. Persistent chat rooms must be explicitly terminated by the room owner. You can monitor this counter to identify if the total number of persistent chat rooms is very large and also to help identify if some persistent chat rooms are not being used regularly anymore.
These pre-chat room counters exist only for the lifetime of a chat room. For ad hoc chat rooms, these counter instances are deleted when the Ad Hoc chat room is terminated. For persistent chat rooms, the counter instances are also deleted when the persistent chat room is terminated, however persistent chat rooms are long-lived, so they should rarely be terminated.
You can use these per-chat room counters to monitor the usage and participants in persistent (and ad hoc) chat rooms over their lifetime and can help identify persistent chat rooms that are no longer being used frequently.
You can use the Cisco XCP TC Room Counters to get a snapshot of all rooms that are currently hosted on the node. These counters can be accessed from the CLI using the following command:
admin:show perf list instances "Cisco XCP TC Room Counters"
This counter represents the number of IM packets received per room.
This counter gives the current number of occupants of the chat room. Monitor this counter for Persistent Chat rooms to get an indication of the usage trend for the chat room.
It is possible to have a maximum of 16,500 Text Conferencing rooms on an IM and Presence node. Each of these rooms will have its own set of Per-Chat Room counters. Similar to JSM Session counters, updating these with new values as they change would place the system under stress. To combat this, Per-Chat Room counter values are cached locally by the system and only updated to RTMT every 30 minutes.
View the current number of idle, or free, SIP worker processes on the IM and Presence SIP Proxy. This counter gives a good indication of the load being applied to the SIP Proxy on each IM and Presence server. Monitor this counter if IM and Presence server is configured for SIP Interdomain Federation or SIP Intradomain Federation.
The number of idle processes can drop to zero on occasion and is not a cause for concern. However, if the number of idle processes are consistently below 5 processes, then it is an indication that the IM and Presence Server is being heavily loaded and requires further investigation
The Port Monitor lets you monitor the activity of each Cisco Unity Connection voice messaging port in real time. This information can help you determine whether they system has too many or too few ports.
The Port Monitor provides information about each Cisco Unity Connection voice messaging port in real time. This information can help you determine the activity of each port and whether the system has too many or too few ports. The Port Monitor displays the information for each port as described in the following table.
The display name of the port in Cisco Unity Connection Administration. |
|
The extension that redirected the call. If the call was redirected by more than one extension, this field shows the extension prior to the last extension. |
|
The name of the conversation that Cisco Unity Connection is playing for the caller. When the port is not handling a call, the status displays Idle. |
|
The action that the conversation is currently performing. When the port is not handling a call, the status displays Idle. |
|
Specific details about the action that the conversation is performing. When the port is not handling a call, the status displays Idle. |
|
For Cisco Unified Communications Manager SCCP integrations, the IP address and port of the Cisco Unified Communications Manager server to which the ports are registered. |
Note | Depending on the information that the phone system integration provided and the status of the call, some fields may remain blank. |
Perform the following steps to use the Port Monitor.
Note | Setting a low polling rate may impact system performance. |
Step 1 | In the Real Time Monitoring Tool, access Unity Connection and click Port Monitor. The Port Monitor window appears. |
Step 2 | In the Node drop-down box, choose a Cisco Unity Connection server. |
Step 3 | In the Polling Rate field, accept the default or enter the number of seconds between updates in the data on the Port Monitor tab; then, click Set Polling Rate. |
Step 4 | Click Start Polling. The Port Monitor window displays the status of all voice messaging ports on Cisco Unity Connection. |