Table Of Contents
Quality Report Tool
Introducing Quality Report Tool
Components of QRT
Overview of QRT Architecture
Cisco CTIManager Interface (QBEHelper)
Cisco CallManager Database Interface (DBL Library)
Screen Helper and Dictionary
Redundancy Manager
DB Change Notifier
SDI Trace and Alarm
System Requirements for QRT
Cisco Extended Functions Service Dependency
Multiple Cisco Extended Functions Applications in a Cluster
How to Use QRT
User Interface
Extended Menu Choices
Problem Classification Categories and Reason Codes
Interactions and Restrictions
Installing and Activating QRT Functions
Configuring the QRT Feature
Configuration Checklist for QRT
Creating a Softkey Template with the QRT Softkey
Configuring the QRT Softkey Template in Device Pool
Adding the QRT Softkey Template in Phone Configuration
Configuring the Cisco CallManager Serviceability Features
Activating the Cisco Extended Functions Service for QRT
Configuring Alarms and Traces for QRT
Setting the Cisco Extended Functions Service Parameters for QRT
Using the QRT Viewer
QRT Reports
Providing Information to Users for the QRT Feature
Troubleshooting the QRT Feature
Where to Find More Information
Quality Report Tool
The Quality Report Tool (QRT), a voice-quality and general problem-reporting tool for Cisco IP Phones, acts as a Windows NT service that allows users to easily and accurately report audio and other general problems with their IP phone. QRT automatically loads with the Cisco CallManager installation, and the Cisco Extended Functions (CEF) service supports it. (For more information about the Cisco Extended Functions service, refer to the "Services" chapter in the Cisco CallManager System Guide.)
As system administrator, you can enable QRT functionality by creating, configuring, and assigning a softkey template to associate the QRT softkey on a user's IP phone. You can choose from two different user modes, depending upon the amount of user interaction that is desired with QRT.
Note The system gives users with administrator privileges the authorization to configure QRT and view the reports.
This chapter provides the following information about configuring and using the QRT feature:
•Introducing Quality Report Tool
•System Requirements for QRT
•Cisco Extended Functions Service Dependency
•How to Use QRT
•Interactions and Restrictions
•Installing and Activating QRT Functions
•Configuring the QRT Feature
•Using the QRT Viewer
•Providing Information to Users for the QRT Feature
•Troubleshooting the QRT Feature
•Where to Find More Information
Introducing Quality Report Tool
When you install Cisco CallManager, the Cisco Extended Functions service installs and loads the QRT functionality on the Cisco CallManager server.
Then, as system administrator, you enable the QRT feature through the use of softkey templates and define how the feature will work in your system by configuring system parameters and setting up Cisco CallManager Serviceability tools. You can then create, customize, and view phone problem reports by using the QRT Viewer application.
You can configure QRT availability for up to four different call states and choose from two different user modes. The user modes determine the level of user interaction that is enabled with QRT and allow either detailed voice-quality reports or more general phone problem reports, and relevant statistics. (See the "Extended Menu Choices" section for more information.)
When users experience problems with their IP phones, they can invoke this feature by pressing the QRT softkey on their Cisco IP Phone during one of the following call states:
•Connected
•Connected Conference
•Connected Transfer
•On Hook
From a supported call state, and using the appropriate problem classification category, users can then choose the reason code that best describes the problem that they are experiencing with their IP phone. See the "Problem Classification Categories and Reason Codes" section for specific information about problem categories, reason codes, and supported call states.
The Quality Report Tool comprises several key components. The following sections provide information about these components and the architecture of the QRT feature:
•Components of QRT
•Overview of QRT Architecture
Components of QRT
QRT, a multitiered, web-based application, includes the following key components:
•Client Components
•IP phone browser for end-user interface
•Cisco CallManager Administration windows for feature and tools configuration and viewer application
•Server Components
•Cisco Extended Functions NT service
•Cisco CallManager for skinny messages
•CTIManager for QBE messages
•Database for configuration data and device data
•Cisco RIS Data Collector for runtime device-related information
•Alarm interface
•System Diagnostic Interface (SDI) trace
•NT Service—Cisco Extended Functions service for collecting and managing user reports. It also handles the user interface on the IP phone as well as notifying Cisco RIS Data Collector for alerts and issuing SNMP traps.
•Viewer Application—A QRT Viewer tool menu, included in the Cisco CallManager Serviceability Administration window, allows you to filter, format, and view generated reports.
Overview of QRT Architecture
The QRT feature uses the Cisco Extended Functions service, which comprises the following interfaces:
•Cisco CTIManager Interface (QBEHelper)
•Cisco CallManager Database Interface (DBL Library)
•Screen Helper and Dictionary
•Redundancy Manager
•DB Change Notifier
•SDI Trace and Alarm
The Cisco Extended Functions service interfaces with the phone by using the XML services interface (XSI) over skinny protocol (a protocol that is used between a Cisco IP Phone and Cisco CallManager) and the Quick Byte Encoding protocol (a protocol that is used between the Cisco CTIManager and TSP/JTAPI).
When a user presses the QRT softkey, QRT opens the device and presents up to four different screens that display problem categories and associated reason codes to obtain user feedback.
After the user chooses the option that best describes the problem, the system logs the feedback in the XML file; the system then issues alarms to notify the Cisco RIS Data Collector to generate alerts and SNMP traps. When QRT detects that user interaction is complete, it then closes the device.
Note The actual information logged depends upon the user selection and whether the destination device is a Cisco IP Phone.
Figure 17-1 shows an illustration of the Cisco Extended Functions service architecture.
Figure 17-1 Using the Cisco Extended Functions Service Architecture
Cisco CTIManager Interface (QBEHelper)
The QBEHelper library provides the interface that allows the Cisco Extended Functions service to communicate with a configured Cisco CTIManager.
Cisco CallManager Database Interface (DBL Library)
The DBL library provides the interface that allows the Cisco Extended Functions service to perform queries on various devices that are configured and registered in the Cisco CallManager database.
Screen Helper and Dictionary
The screen helper of the Cisco Extended Functions service reads the XML dictionary files and creates Document Object Model (DOM) objects for all installed locales when the CEF service starts. The system uses these DOM objects for constructing XSI screens that the Cisco IP Phone needs.
Redundancy Manager
When multiple Cisco Extended Functions are active within a Cisco CallManager cluster, the redundancy manager uses an algorithm to determine which Cisco Extended Functions service is active and which is the backup CEF. The Redundancy Manager uses the lowest IP address of the server that is running the CEF service as the active service. The remaining CEF services serve as backup services.
DB Change Notifier
The DB Change Notifier handles all the database change notifications, such as service parameter changes, trace parameter changes, alarm configuration changes, and status changes of other CEF services in the cluster, and reports the changes to the Cisco Extended Functions service.
SDI Trace and Alarm
The Cisco Extended Functions service uses the SDI Trace and Alarm libraries. The libraries generate traces and alarms to the Event Viewer. The alarm library publishes information about the CEF service to Syslog, SNMP, and the Cisco RIS Data Collector service. For more information about traces and alarms, refer to the Cisco CallManager Serviceability Administration Guide.
System Requirements for QRT
To operate, the QRT feature requires the following software components:
•Cisco CallManager 3.3 or later
•Microsoft Windows 2000
•Microsoft Internet Explorer or Netscape Navigator
Support for the QRT feature extends to any model IP phone that includes the following capabilities:
•Support for softkey templates
•Support for IP phone services
•Controllable by CTI
•Contains an internal HTTP server
Note For more information, refer to the following URL for the appropriate
Cisco IP Phone guide for your model IP phone:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/index.htm.
Cisco Extended Functions Service Dependency
The Cisco Extended Functions service depends on the following services:
•Cisco CallManager—Ensure a minimum of one Cisco CallManager service is running in the cluster, but the service need not be on the same server as CEF.
•Cisco CTIManager—Ensure a minimum of one Cisco CTIManager service is running in the cluster, but the service need not be on the same server as CEF.
•Cisco Database Layer Monitor—Ensure one Cisco Database Layer Monitor service is running on the same server as CEF.
•Cisco RIS Data Collector—Ensure one Cisco RIS Data Collector service is running on the same server as CEF.
Note Ensure Cisco Database Layer Monitor and Cisco RIS Data Collector are running on the same server. You can include more than one Cisco Extended Functions service in a Cisco CallManager cluster.
Tip Install all the services on one server for one-server Cisco CallManager systems.
Figure 17-2 shows a typical Cisco Extended Functions service configuration.
Figure 17-2 Cisco Extended Functions Service Dependency (Typical Configuration)
Multiple Cisco Extended Functions Applications in a Cluster
If multiple Cisco Extended Functions services are active within a Cisco CallManager cluster, Cisco Extended Functions uses an algorithm to determine which service should be active and to order the remaining as backups. The Cisco Extended Functions application with the lowest IP address becomes active. The service with the next lowest IP address becomes the backup to the active service. Any remaining services act as backups to each other, beginning with the service with the next lowest IP address. If you add any new services to the cluster, Cisco Extended Functions restarts the algorithm to determine which service will be active.
Note When a Cisco Extended Functions service gets started in a cluster, the Cisco Extended Functions service with the lowest IP address becomes active. This process may cause service interruption for approximately 2 minutes.
To verify the directory status and Cisco Extended Functions service registration status to the Cisco CTIManager, use the Real-Time Monitoring Tool (RTMT) as described in the Cisco CallManager Serviceability Administration Guide.
How to Use QRT
After you properly install and configure QRT, supported Cisco IP Phones include the QRT softkey. (See the "System Requirements for QRT" section for the IP phone models that are supported with QRT.)
Note The Cisco CallManager Standard User template does not include the QRT softkey. You must enable QRT functionality and make it available to users through the use of a QRT softkey. To do this, create, configure, and assign the QRT softkey from the Cisco CallManager Administration application. (See the "Configuring the QRT Feature" section for information about setting up the softkey template.)
The following sections describe the user interaction features with QRT:
•User Interface
•Extended Menu Choices
•Problem Classification Categories and Reason Codes
For more user-related information, refer to the following URL for the appropriate Cisco IP Phone guide for your phone model:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/index.htm.
User Interface
The QRT user interface includes several components, as described below:
•Phone Screens—Available to all IP phones that are in the device pool where the QRT softkey is configured, the phone screen supports different locales.
Only the Cisco CallManager administrator can access the following components:
•Serviceability—See the "Configuring the Cisco CallManager Serviceability Features" section.
•Alert Configuration—See the "Configuring Alarms and Traces for QRT" section.
•Service Parameters—See the "Setting the Cisco Extended Functions Service Parameters for QRT" section.
•Viewer Application—See the "Using the QRT Viewer" section.
Figure 17-3 shows an example of the QRT softkey as it displays on a
Cisco IP Phone.
Figure 17-3 QRT Phone Interface Display
Extended Menu Choices
Extended menu choices allow a user to interact with QRT and provide additional details regarding the phone problem that they are reporting. You can choose to enable extended menu choices or provide users with a more passive interface, depending upon the amount of information that you want users to submit.
From the Cisco CallManager Service Parameters Configuration window, configure the user interface mode for QRT from the following options:
•Silent Mode—In this mode, the user does not get presented with extended menu choices. When the user presses the QRT softkey, the system collects the streaming statistics and logs the report without additional user interaction.
The system supports silent mode only when the IP phone is in the Connected, Connected Conference, or Connected Transfer call state.
Figure 17-4 shows an example of the QRT display as it appears in silent mode.
Figure 17-4 Submitting Voice Quality Feedback in Silent Mode
•Interview Mode—In this mode, the user gets presented with extended menu choices, allowing additional user input that is related to audio quality on the IP phone (see the "Problem Classification Categories and Reason Codes" section for the applicable reason codes). This mode also allows the user to report other, non-audio related problems such as the phone rebooting or the inability to make calls.
The system supports interview mode only when the IP phone is in the Connected or On Hook call state.
Figure 17-5 shows an example of the QRT display as it appears when the QRT softkey is pressed while the phone is on-hook and in interview mode.
Figure 17-5 QRT Phone Interface - On Hook, Interview Mode Display
Note Ensure that you configure the QRT softkey only for the supported call states.
Note Configure the "Display extended menu choices" field in the Cisco CallManager Administration Service Parameters configuration window to determine whether the users can access the extended menu choices. See the "Setting the Cisco Extended Functions Service Parameters for QRT" section for additional information.
Problem Classification Categories and Reason Codes
The following tables show the problem categories and corresponding reason codes that users can choose to report problems with their IP phones. Additional options become available after you configure extended menu choices. Users can choose only one reason code per category, per problem. Each problem category becomes available only when the IP phone is in the supported call state.
Table 17-1 shows the supported call states and the reason codes that are available for the "Problems with current call" category.
Table 17-1 Problem Category—Problems with Current Call
Problem Category
|
Supported Call States
|
Reason Codes
|
Statistics
|
Problems with current call
|
•Connected
•Connected Conference
•Connected Transfer
|
•I hear echo
•The remote end hears echo
•Choppy audio
•Robotic sound
•Long delays
•Low volume
•The remote end experiences low volume
•I can't hear the remote end
•The remote end can't hear me
|
The system collects streaming statistics from the source and destination devices.
|
Figure 17-6 shows an example of the phone display as it appears after the QRT softkey is pressed on an IP phone in the connected state. This menu allows the user to provide additional details before submitting a problem with the current phone call.
Figure 17-6 Reporting Problem with the Current Call
Table 17-2 shows the supported call state and the reason codes that are available for the "Problems with last call" category.
Table 17-2 Problem Category—Problems with Last Call
Problem Category
|
Supported Call States
|
Reason Codes
|
Statistics
|
Problems with last call
|
•On Hook
|
•I heard echo
•The remote end heard echo
•Choppy audio
•Robotic sound
•Long delays
•Low volume on my end
•Low volume on the remote end
•I could not hear the remote end
•The remote end could not hear me
•The call dropped
|
The system collects streaming statistics from the source device.
|
Figure 17-7 shows an example of the phone display as it appears after the user selects the "Problems with last call" category. This menu allows the user to provide additional details before submitting a problem report for the last phone call.
Figure 17-7 Reporting Problem with the Last Call
Table 17-3 shows the supported call state that is available for the "Phone recently rebooted" category. No associated reason codes exist for this category.
Table 17-3 Problem Category—Phone Recently Rebooted
Problem Category
|
Supported Call States
|
Reason Codes
|
Statistics
|
Phone recently rebooted
|
•On Hook
|
None
|
|
Figure 17-8 shows an example of the phone display after the user chooses the "Phone recently rebooted" category. The system logs user feedback.
Figure 17-8 Reporting Problem with Phone Recently Rebooted
Table 17-4 shows the supported call state and the reason codes that are available for the "I can't make calls" category.
Table 17-4 Problem Category—I Can't Make Calls
Problem Category
|
Supported Call States
|
Reason Codes
|
Statistics
|
I can't make calls
|
•On Hook
|
•I get a busy tone
•I get a fast busy tone
•I get dialtone after dialing digits
•I hear silence after dialing
•I don't get dialtone
|
|
Figure 17-9 shows an example of the phone display as it appears after the user chooses the "I can't make calls" category.
Figure 17-9 Reporting Problem with I Can't Make Calls
Note QRT collects information from various sources, such as the source IP phone, the destination IP phone, the Cisco RIS Data Collector, the Cisco CallManager database, and the user. See the "QRT Reports" section for detailed information about the fields that the phone problem report includes.
Interactions and Restrictions
The following interactions and restrictions apply when you use the QRT feature with Cisco CallManager:
•Cisco Extended Functions, Cisco CallManager, CTIManager, and Cisco RIS Data Collector services must be running and fully operational.
•As system administrator, you must create, configure, and assign softkey templates to enable the QRT softkey feature on IP phones.
•Ensure that you configure the QRT softkey only for the supported call states.
•The system makes the extended menu choices option available only when the "Display extended menu choices" service parameter is set to true; it provides support for the "Problems with current call" category.
•If another application feature (such as Cisco Call Back or IPMA) or a function key (such as Settings, Directories, or Messages) is invoked while the user is interacting with QRT, or if the user does not complete the QRT selection, the system can overwrite the QRT display. In this case, the system forces the device into a wait state, which prevents QRT from completing the interaction and then closes the device.
Note Because unattended devices consume large amounts of resources and could impact CTI performance, the system configures QRT to regularly check for opened devices. You cannot modify these system settings.
Installing and Activating QRT Functions
As a feature within the Cisco Extended Functions service, QRT automatically installs as part of the Cisco CallManager installation.
Perform the following steps after installation to enable QRT availability for users and to set up administrative reporting capabilities:
1. Properly configure the QRT feature for Cisco IP Phone users. See the "Configuring the QRT Feature" section.
2. From Cisco CallManager Serviceability, activate the Cisco Extended Functions service and configure alarms and traces for use with QRT. See the "Configuring the Cisco CallManager Serviceability Features" section and refer to the Cisco CallManager Serviceability Administration Guide for additional information.
3. Define how the QRT feature will work in your system by configuring the applicable service parameters for the Cisco Extended Functions service. See the "Setting the Cisco Extended Functions Service Parameters for QRT" section.
4. Create, customize, and view phone problem reports by using the QRT Viewer application. See the "Using the QRT Viewer" section.
Note If users require the QRT feature to display (softkeys and messages on the IP phone) in any language other than English, verify that the locale installer is installed before configuring QRT. Refer to the Cisco IP Telephony Locale Installer documentation for more information.
Configuring the QRT Feature
For successful configuration of the QRT feature, review the steps in Table 17-5, QRT Configuration Checklist, perform the configuration requirements, activate the Cisco Extended Functions service, and set the service parameters.
The following sections provide configuration information for enabling QRT:
•Configuration Checklist for QRT
•Creating a Softkey Template with the QRT Softkey
•Configuring the QRT Softkey Template in Device Pool
•Adding the QRT Softkey Template in Phone Configuration
•Activating the Cisco Extended Functions Service for QRT
•Configuring Alarms and Traces for QRT
•Setting the Cisco Extended Functions Service Parameters for QRT
Configuration Checklist for QRT
Table 17-5 shows the steps for configuring the QRT feature in Cisco CallManager.
Creating a Softkey Template with the QRT Softkey
Perform the following procedure to create a new softkey template with the QRT softkey.
Procedure
Step 1 From Cisco CallManager Administration, choose Device > Device Settings > Softkey Template.
The Softkey Template Configuration window displays.
Step 2 From the Softkey Template list, or from the drop-down list box in the Create a softkey template based on field, choose the Standard User softkey template. (If you choose the first option, the Softkey Template Configuration window automatically displays with new information. Go to Step 3.)
Step 3 Click the Copy button.
The Softkey Template Configuration window displays with new information.
Step 4 In the Softkey Template Name field, enter a new name for the template; for example, QRT Standard User.
Figure 17-10 shows an example of the Cisco CallManager Administration Softkey Template window, where you copy a softkey template.
Figure 17-10 QRT Softkey Template Copy
Step 5 Click the Insert button.
The Softkey Template Configuration redisplays with new information.
Figure 17-11 shows an example of the Cisco CallManager Administration Softkey Template Configuration window.
Figure 17-11 QRT Softkey Template Configuration
Step 6 To add the QRT softkey to the template, click the Configure Softkey Layout link.
The Softkey Layout Configuration window displays. You must add the QRT softkey to the Connected, Connected Conference, Connected Transfer, and On Hook call states.
Step 7 To add the QRT softkey to the On Hook call state, click the On Hook link in the Call States field.
The Softkey Layout Configuration window redisplays with the Unselected Softkeys and Selected Softkeys lists.
Step 8 From the Unselected Softkeys list, choose the Quality Report Tool (QRT) softkey and click the right arrow to move the softkey to the Selected Softkeys list.
Figure 17-12 shows an example of the Cisco CallManager Administration Softkey Layout Configuration window.
Figure 17-12 QRT Softkey Layout Configuration
Step 9 To save and continue, click the Update button.
Step 10 To add the QRT softkey to the Connected, Connected Conference, and Connected Transfer call states, repeat Step 7 through Step 9 for each individual call state.
Note Ensure that you configure the QRT softkey only for the supported call states and click the Update button after each entry.
Configuring the QRT Softkey Template in Device Pool
Perform the following procedure to add the QRT softkey template to the device pool.
Procedure
Step 1 From Cisco CallManager Administration, choose System > Device Pool.
The Device Pool Configuration window displays.
Step 2 Choose the Default device pool or any previously created device pool that is listed in the Device Pools.
You can add the template to the default device pool if you want all users to have access to the QRT softkey, or you can create a customized device pool for QRT feature users.
Step 3 In the Softkey Template field, choose the softkey template that contains the QRT softkey from the drop-down list box. (If you have not created this template, see the "Creating a Softkey Template with the QRT Softkey" section.)
Figure 17-13 shows an example of the Cisco CallManager Administration Device Pool Configuration window.
Figure 17-13 Device Pool Configuration
Note All IP phones that are part of this device pool inherit this softkey template, providing an easy way for you to assign softkey templates to multiple phones.
Step 4 Click the Update button.
Adding the QRT Softkey Template in Phone Configuration
Perform the following procedure to add the QRT softkey template to each user phone.
Procedure
Step 1 From Cisco CallManager Administration, choose Device > Phone.
The Find and List Phones window displays.
Step 2 Find the phone to which you want to add the softkey template. See Finding a Phone in the Cisco CallManager Administration Guide.
Step 3 In the Softkey Template field, choose the softkey template that contains the QRT softkey from the drop-down list box. (If you have not created this template, see the "Creating a Softkey Template with the QRT Softkey" section.)
If you alternatively configured the softkey template in the device pool, from the Device Pool field, choose the device pool that contains the new softkey template.
Figure 17-14 shows an example of the Cisco CallManager Administration Phone Configuration window.
Figure 17-14 Phone Configuration
Step 4 Click the Update button.
Configuring the Cisco CallManager Serviceability Features
The Cisco Extended Functions service uses the following Cisco CallManager Serviceability features:
•Service Activation—Configured from the Cisco CallManager Serviceability Tools window.
•SDI Trace—Configured from the Cisco CallManager Serviceability Trace Configuration window.
•Alarm Interface—Configured from the Cisco CallManager Serviceability Alarm Configuration window.
•Real-Time Monitoring Tool (RTMT)—Used to monitor the operating status of QRT and CTI Manager. For detailed information about RTMT, refer to the Cisco CallManager Serviceability Administration Guide.
This section describes how to activate and configure the Cisco CallManager Serviceability features for use with QRT, and contains the following information:
•Activating the Cisco Extended Functions Service for QRT
•Configuring Alarms and Traces for QRT
For additional information about Cisco CallManager Serviceability, refer to the Cisco CallManager Serviceability Administration Guide.
Activating the Cisco Extended Functions Service for QRT
Follow this procedure to activate the Cisco Extended Functions service for use with the QRT feature.
Procedure
Step 1 From Cisco CallManager Serviceability, choose Tools > Service Activation.
A list of Cisco CallManager servers displays.
Step 2 Click on the Cisco CallManager server to choose it for activation of the Cisco Extended Functions service.
Step 3 Check the Cisco Extended Functions check box.
Step 4 Click Update.
Figure 17-15 shows an example of the Cisco CallManager Serviceability Service Activation window, where you activate the Cisco Extended Functions service.
Figure 17-15 CEF Service Activation
Configuring Alarms and Traces for QRT
Follow this procedure to configure alarms and SDI traces through Cisco CallManager Serviceability.
Procedure
Step 1 For alarm configuration, choose Alarm > Configuration from the Cisco CallManager Serviceability window.
A list of Cisco CallManager servers displays.
Step 2 Click the Cisco CallManager server to choose it for alarm configuration.
Step 3 From the Configured Services window, click Cisco Extended Functions.
Step 4 Check the Enable Alarm check box for both Event Viewer and SDI Trace.
Figure 17-16 shows an example of the Cisco CallManager Serviceability Alarm Configuration window. (See Figure 17-18 for an example of the logged alarm entry in the Event Viewer.)
Figure 17-16 Alarm Configuration for QRT
Step 5 Click Update.
Step 6 For trace configuration, choose Trace > Configuration from the Cisco CallManager Serviceability window.
A list of Cisco CallManager servers displays.
Step 7 Click the Cisco CallManager server to choose it for trace configuration.
Step 8 From the Configured Services window, click Cisco Extended Functions.
Step 9 Check the Cisco Extended Functions Trace Fields check box.
Figure 17-17 shows an example of the Cisco CallManager Serviceability Trace Configuration window, where you configure trace information for the Cisco Extended Functions service and QRT.
Figure 17-17 Trace Configuration for QRT
Step 10 Click Update.
Figure 17-18 shows an example of the Event Properties window of a QRT alarm entry that is logged in the Windows 2000 Event Viewer. This entry shows the following information:
•Source Device Name
•Source IP Address
•Source Directory Number
•Category
•Reason Code
•Timestamp
Figure 17-18 Event Viewer - QRT Alarm Entry Event Properties Window
For additional information about configuring alarms and traces, refer to the Cisco CallManager Serviceability Administration Guide.
Setting the Cisco Extended Functions Service Parameters for QRT
Set the Cisco Extended Functions service parameters by using Cisco CallManager Administration to access the service parameters (Service > Service Parameters). Choose the server where the QRT application resides and then choose the Cisco Extended Functions service.
Figure 17-19 shows an example of the server and service selections in the Cisco CallManager Administration Service Parameters Configuration window.
Figure 17-19 Service Parameters Server Selection
Cisco recommends that you use the default service parameters settings unless the Cisco Technical Assistance Center (TAC) instructs otherwise.
Cisco Extended Functions includes the following parameters for QRT:
•Display extended menu choices—Determines whether extended menu choices are presented to the user. Set this field to true to display extended menu choices (interview mode) or set this field to false to not display extended menu choices (silent mode).
Recommended default value specifies false (silent mode).
•Streaming statistics polling duration—Determines the duration used for polling streaming statistics. Set this field to -1 to poll until the call ends, set it to 0 to not poll at all, or set it to any positive value to poll for that many seconds. Polling stops when the call ends.
Recommended default value specifies -1 (poll until the call ends).
•Streaming statistics polling frequency (seconds)— Designates the number of seconds to wait between each poll. The value ranges between 30 and 3600.
Recommended default value specifies 30.
•Log File—Specifies the path where the QRT report files are located. Users must have the proper privileges to access these files.
Recommended default value specifies
C:\Program Files\Cisco\QRT\QRT.xml.
•Maximum No. of Files—Specifies the maximum number of files before restarting the file count and overwriting old files. The value ranges between 1 and 10000.
Recommended default value specifies 250.
•Maximum No. of Lines per File—Specifies the maximum number of lines in each file before starting the next file. The value ranges between 100 and 2000.
Recommended default value specifies 2000.
Figure 17-20 shows an example of the Cisco CallManager Administration Service Parameters Configuration window, where you specify the Cisco Extended Functions service parameters for QRT.
Figure 17-20 Service Parameters Configuration for QRT
Using the QRT Viewer
You can use the QRT Viewer to view the IP phone problem reports that the Quality Report Tool generates. The QRT Viewer allows you to filter, format, and view the tool-generated phone problem reports, so they provide you with the specific information that you need.
Figure 17-21 shows an example of the Cisco CallManager Serviceability Tools window where you access the QRT Viewer.
Figure 17-21 QRT Viewer
Note For detailed information about accessing, configuring, using, and customizing the QRT Viewer for IP phone problem reports, refer to the Cisco CallManager Serviceability Administration Guide.
QRT Reports
QRT collects information from various sources, such as the source IP phone, the destination IP phone, the Cisco RIS Data Collector, Cisco CallManager, and the user. (The system does not collect information from gateways or other devices.)
The following list provides information about the QRT report fields, segmented by information source:
Information Collected from the Source Device
•Directory number of source device (in the case of multiline, the information shows only the first primary directory number)
•Source device type (for example, CP-7960, CP-7940)
•Source stream1 port number
•Source codec (for example, G.711u)
•Source packets (for example, 2,45,78)
•Source rcvr packets (for example, 12,45,78)
•Source rcvr jitter (for example, 0 0)
•Source rcvr packet lost (for example, 0,21 0,21)
•Source sampling timestamp, implicit (for example, 12:30, 13:00, 13:30, 14:00)
•Destination device name (IP)
•Destination stream1 port number
Note The number of samples that are collected for packets, jitter, packets lost, and so on, depends on the sampling duration and polling frequency. The streaming information gets collected only one time per call. For example, if phone A called phone B and both phone A and phone B submit multiple reports for the same call, only the first report includes the streaming data. Also, for the "Problems with last call" category. these values might reflect only the last snapshot of the streaming statistics that are stored in the phone device.
Information Collected from the Destination Device
The system collects the following information if the destination device is a supported Cisco IP Phone within same Cisco CallManager cluster. If the destination device is not an IP phone, the information includes only IP address, device name, and device type.
•Directory number of destination device (in the case of multiline, the information shows only the first primary directory number)
•Destination device type (for example, CP-7960, CP-7940)
•Destination codec
•Destination packets
•Destination rcvr packets
•Destination rcvr jitter
•Destination rcvr packet lost
•Destination sampling timestamp (Implicit)
Note The number of samples that are collected for packets, jitter, packets lost, and so on, depends on the sampling duration and polling frequency. The streaming information gets collected only one time per call. For example, if phone A called phone B and both phone A and phone B submit multiple reports for the same call, only the first report includes the streaming data included. QRT attempts to collect the information from the destination IP phone only for the "Problems with current call" category.
Information Collected from RIS Data Collector
•Source device owner (user name that is currently logged in to the IP phone); if no explicitly logged-in user exists, this field is null.
•IP address for source device
•Registered Cisco CallManager name for source device
•Source device type (if the device is not one of the supported IP hones; for example, RISCLASS_PHONE, RISCLASS_GATEWAY, RISCLASS_H323, RISCLASS_CTI, RISCLASS_VOICEMAIL, and so on)
•Source device model (for example, DBLTypeModel::MODEL_TELECASTER_MGR, DBLTypeModel::MODEL_TELECASTER_BUSINESS)
•Source device product (for example, DBLTypeProduct::PRODUCT_7960, DBLTypeProduct::PRODUCT_7940)
•Destination device name
•Destination device type (if the device is not one of the supported IP phones; for example, RISCLASS_PHONE, RISCLASS_GATEWAY, RISCLASS_H323, RISCLASS_CTI, RISCLASS_VOICEMAIL, and so on)
•Destination device model (for example, DBLTypeModel::MODEL_TELECASTER_MGR, DBLTypeModel::MODEL_TELECASTER_BUSINESS)
•Destination device product (for example, DBLTypeProduct::PRODUCT_7960, DBLTypeProduct::PRODUCT_7940)
•Registered Cisco CallManager name for destination device
•Destination device owner (user name that is currently logged in to the IP phone); if no explicitly logged-in user exists, this field is null.
Information Collected from Cisco CallManager/CTIManager
•Source device name (MAC address)
•CallingPartyNumber (the party who placed the call; for transferred calls, the transferred party becomes the calling party)
•OriginalCalledPartyNumber (the original-called party after any digit translations occurred)
•FinalCalledPartyNumber (For forwarded calls, this specifies the last party to receive the call; for non-forwarded calls, this field specifies the original called party.)
•LastRedirectDn (For forwarded calls, this field specifies the last party to redirect the call; for non-forwarded calls, this field specifies the last party to redirect, via transfer or conference, the call.)
•globalCallID_callManagerId (distinguishes the call for CAR)
•globalCallID_callId (distinguishes the call for CAR)
•CallState (Connected, Connected Conference, Connected Transfer, On Hook)
Information Collected from the Cisco CallManager Database
•Sampling duration - Service parameter (for example, 50 seconds)
•Sampling frequency - Service parameter (for example, 30 seconds)
•Cluster ID - Enterprise parameter
Information Collected from the User
•Category
•ReasonCode
•TimeStamp (Implicit)
Note Refer to the QRT Viewer chapter in the Cisco CallManager Serviceability Administration Guide to see an illustration of a phone problem report.
Table 17-6 shows the available fields for each supported category.
Table 17-6 QRT Fields by Supported Category
Information Source
|
Problems with Current Call
|
Problems with Last Call
|
Phone Recently Rebooted
|
Can't Make Calls
|
Source Device Name
|
X
|
X
|
X
|
X
|
DN of Source Device
|
X
|
X
|
X
|
X
|
IP Address of Source Device
|
X
|
X
|
X
|
X
|
Source Device Type
|
X
|
X
|
X
|
X
|
Source Device Owner
|
X
|
X
|
X
|
X
|
Registered Cisco CallManager for Source Device
|
X
|
X
|
X
|
X
|
Source Model
|
X
|
X
|
X
|
X
|
Source Product
|
X
|
X
|
X
|
X
|
Source Stream 1 Port Number
|
X
|
X
|
|
|
Source Codec
|
X
|
X
|
|
|
Source Packets
|
X
|
X
|
|
|
Source Rcvr Packets
|
X
|
X
|
|
|
Source Rcvr Jitter
|
X
|
X
|
|
|
Source Rcvr Packet Lost
|
X
|
X
|
|
|
Source Sampling Timestamp
|
X
|
|
|
|
Destination Device Name
|
X
|
X
|
|
|
DN of Destination Device
|
X
|
X
|
|
|
IP Address of Destination Device
|
X
|
X
|
|
|
Destination Device Type
|
X
|
X
|
|
|
Destination Stream 1 Port Number
|
X
|
|
|
|
Destination Codec
|
X
|
|
|
|
Destination Packets
|
X
|
|
|
|
Destination Rcvr Packets
|
X
|
|
|
|
Destination Rcvr Jitter
|
X
|
|
|
|
Destination Rcvr Packet Lost
|
X
|
|
|
|
Destination Sampling Timestamp
|
X
|
|
|
|
Destination Device Owner
|
X
|
X
|
|
|
Registered Cisco CallManager for Destination Device
|
X
|
X
|
|
|
Destination Model
|
X
|
X
|
|
|
Destination Product
|
X
|
X
|
|
|
Calling Party Number
|
X
|
|
|
|
Original Called Party Number
|
X
|
|
|
|
Final Called Party Number
|
X
|
|
|
|
Last Redirect DN
|
X
|
|
|
|
globalCallID_callManagerId
|
X
|
|
|
|
globalCallID_callId
|
X
|
|
|
|
Sampling Duration
|
X
|
X
|
X
|
X
|
Sampling Frequency
|
X
|
X
|
X
|
X
|
Cluster ID
|
X
|
X
|
X
|
X
|
Category
|
X
|
X
|
X
|
X
|
Reason Code
|
X
|
X
|
|
X
|
TimeStamp When Report is Submitted
|
X
|
X
|
X
|
X
|
Providing Information to Users for the QRT Feature
The Cisco IP Phone guides provide procedures for how to use the QRT feature on the Cisco IP Phone. For more information, refer to the following URL for the appropriate Cisco IP Phone Guide for your phone model:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/index.htm.
Troubleshooting the QRT Feature
Cisco CallManager Serviceability provides web-based tools to assist in troubleshooting Cisco CallManager problems. Use the Cisco CallManager Serviceability Trace Configuration, Alarm Configuration, and Real-Time Monitoring Tool to help troubleshoot problems with QRT. Refer to the Cisco CallManager Serviceability Administration Guide for more information.
The Trace and Alarm tools work together. You can configure trace and alarm settings for Cisco CallManager services and direct alarms to the Windows 2000 Event Viewer, CiscoWorks2000 Syslog, system diagnostic interface (SDI), or signal distribution layer (SDL) trace log files, or to all destinations.
You can base traces for Cisco CallManager services on debug levels, specific trace fields, and Cisco CallManager devices such as phones or gateways. You can also perform a trace on the alarms that are sent to the SDI or SDL trace log files.
Use the Trace Configuration tool to specify the parameters that you want to trace for troubleshooting Cisco CallManager problems. The Trace Configuration window provides two types of settings: trace filter and trace output. The trace tool provides three main functions:
•Configure trace parameters
•Collect trace files
•Analyze trace data for troubleshooting problems
Use Trace to view the SDI or SDL log files in XML format or use a text editor to view the SDI or SDL log files in text format. (Trace supports text format as well.)
Use the Windows 2000 Event Viewer program to view alarm information that is sent to the Event Log. You can view alarm information that is sent to the SDI or SDL trace log file in text or XML format.
Note Enabling Trace decreases system performance; therefore, enable Trace only for troubleshooting purposes. For assistance in using Trace, contact Cisco TAC.
For more information about Cisco CallManager Serviceability tools, refer to the Cisco CallManager Serviceability Administration Guide.
For information about Event Viewer and Microsoft text editors, refer to the Microsoft Windows 2000 documentation.
For information about troubleshooting Cisco CallManager, refer to the Troubleshooting Guide for Cisco CallManager.
Where to Find More Information
Related Topics
•Softkey Template Configuration, Cisco CallManager Administration Guide
•Device Pool Configuration, Cisco CallManager Administration Guide
•Cisco IP Phones, Cisco CallManager System Guide
•Device Defaults Configuration, Cisco CallManager Administration Guide
•Service Parameters Configuration, Cisco CallManager Administration Guide
•Cisco IP Phone Configuration, Cisco CallManager Administration Guide
Additional Cisco Documentation
•Cisco CallManager Administration Guide
•Cisco CallManager System Guide
•Cisco CallManager Serviceability Administration Guide
•Cisco CallManager Serviceability System Guide
•Troubleshooting Guide for Cisco CallManager
•Cisco IP Phone Administration Guide for Cisco CallManager
•Cisco IP Telephony Locale Installer
•Cisco IP Phone Guides