Phone Status Test

Phone status testing is protocol-independent. You can perform tests on phones that operate under the following protocols:

•MGCP

•SCCP

•SIP

•A phone status test consists of the following:

•A list of IP phones to test, selected by you.

•A testing schedule that you configure.

•IP SLA-based pings from an IP SLA-capable device (for example, a switch, a router, or a voice router) to the IP phones. Optionally, it also pings from Prime Collaboration to the IP phones.

A phone is considered unreachable after there is no response to either an IP SLA-based ping, or an Prime Collaboration ping, and the phone status is unregistered in the phone status process. Prime Collaboration generates the PhoneReachabilityTestFailed event.

When a router is rebooted, the phone status tests are lost. However, Prime Collaboration reconfigures the test when the router becomes available. While the router is down, the Prime Collaboration ping continues to run, if you have enabled Prime Collaboration ping.

Synthetic Test

Synthetic tests are used to check the availability of voice applications. These tests verify whether the voice application can service requests from a user. For example, you can use synthetic tests to verify whether phones can register with a Cisco Unified CM. You can configure these tests to run periodically.

Synthetic tests use synthetic phones to measure the availability of voice applications by emulating your actions. For example, a synthetic test places a call between clusters and then checks whether the call is successful.

Prime Collaboration can monitor the information returned from the synthetic tests and generate events based on the results. If a synthetic test fails, Prime Collaboration generates a critical event. Such events are displayed in Event Browser.

Prime Collaboration supports synthetic testing for the following applications:

•Cisco Unified CM and Cisco Unified CM Express

•Cisco TFTP Server

•Cisco Emergency Responder

•Cisco Unity, Cisco Unity Express, and Cisco Unity Connection

Note Creating synthetic tests with RTP transmissions in NATed environment is not supported.

Table 11-2 lists the synthetic tests and the results that each test must produce to pass.

Table 11-2 Synthetic Test Descriptions and Expected Results

Synthetic Test

Description

Expected Results

Phone Registration Test

Opens a connection with the Cisco Unified CM and registers a simulated IP phone.

Successful registration of the phone.

Dial-Tone Test

Simulates an off-hook state to Cisco Unified CM and checks for receipt of a dial tone.

Receives a dial tone signal from Cisco Unified CM.

End-to-End Call Test

Initiates a call to a second simulated or real IP phone.

•Registers, goes off-hook, and places the call

•Ring indication

•Destination phone goes off-hook to accept the call

If call progress tones and announcements are configured on the gateway for your end-to-end call, the test may succeed even before the phone rings or after a couple of rings. This indicates that your gateway is working correctly.

TFTP Download Test

Performs a TFTP get-file operation on the TFTP server.

Successful download of a configuration file from the TFTP server.

Emergency Call Test

Initiates a call to the emergency number to test the dynamic routing of emergency calls.

•All calls initiated

•Ring indication on Public Safety Answering Point (PSAP) and On Site Alert Number (OSAN), if configured.

Message-Waiting Indicator Test

Calls the target phone and leaves a voice message in the voice mailbox.

The destination phone for the Message-Waiting Indicator Test should be configured as Call Forward after X number of rings before moving to voicemail.

If it is configured for Call Forward Always, the test will fail.

Activation of the phone's message-waiting indicator. The message is then deleted and the message-waiting indicator is deactivated.

Application Configuration for Synthetic Tests

You can configure synthetic tests for each Cisco Unified Communications Manager and only for supported Cisco voice applications in your network. For each synthetic test, you must configure one or more phones in the related Cisco Unified Communications Manager or supported Cisco voice applications.

Follow these guidelines while creating synthetic tests:

•The MAC address for synthetic phones must be between 00059a3b7700 and 00059a3b8aff and must be in the format 00059a3b7700.

•Create one phone extension number and one MAC address for each test and use it for that test only.

•Configure only one synthetic test per Cisco Unified CM.

•The SIP URI should be in the format sip:extn@ccm; for example, sip:7690@ct-sd.cisco.com.

•Make sure that the combination of the phone extension number and the MAC address used in a test is unique across the voice cluster.

•Select the name or IP address of the system where Cisco Emergency Responder is installed.

•You can use the Select Voice Application group selector in the left pane to enter a device: Select the device in the group selector, and then click the arrow button next to the Cisco Emergency Responder field.Enter the Emergency phone number.

Step 5 In the Caller pane, do the following:

•Select the name or IP address of the Cisco Unified Communications Manager or Cisco Unified Communications Manager Express for the caller's phone.

You can use the Select Voice Application group selector in the left pane to enter a device: Select the device in the group selector, and then click the arrow button next to the Cisco Unified Communications Manager/Express field.

•Enter the synthetic phone's MAC address. If you used the group selector to choose the Cisco Unified Communications Manager or Cisco Unified Communications Manager Express system, the MAC address field is automatically populated.

Prime Collaboration verifies only that the MAC address number entered in the Create Synthetic Test page is syntactically valid. It is your responsibility to make sure the correct numbers are entered, as configured in the Cisco Unified Communications Manager. See Application Configuration for Synthetic Tests for MAC address limitations.

You can use the Select Voice Application group selector in the left pane to enter a device: Select the device in the group selector, and then click the arrow button next to the Cisco Unified Communications Manager/Express field.

•Enter the PSAP phone's MAC address.

Step 7 (Optional) If there is an On Site Alert Number (OSAN), select the On Site Alert Number check box, and enter the following in the OSAN pane:

You can use the group selector in the left pane to enter a device: Select the device in the group selector, and then click the arrow button next to the Cisco Unified Communications Manager/Express field.

•The OSAN phone's MAC address.

Step 8 In the Run pane, configure when the test should run.

Step 9 Click Create.

Creating a Message-Waiting Indicator Synthetic Test

The following are the requirements for the target phones to run this test.

While creating the subscriber on Cisco Unity that you are going to use for synthetic testing, configure the subscriber according to the following:

•The Set subscriber for self-enrollment at next login check box must be deselected, or you must use a real phone to dial into the Cisco Unity device and complete the personalization process.

•Set the password option to Password never expires. The destination phone for the Message-Waiting Indicator Test should be configured as CALL FORWARD after X number of rings before moving to voicemail. If it is configured for CALL FORWARD ALWAYS, the test will fail.

This test is only supported on SCCP end-points. SIP endpoints are not supported for this test.

Note After you perform a Cisco Unified CM version upgrade, Cisco Unity synthetic tests that use the Cisco Unified CM that you upgraded might stop working. If this problem occurs, you should delete the Cisco Unity synthetic test, and then add the synthetic test again.

Step 4 From the Select Voice Application group selector, select the Cisco Unified CM or Cisco Unified CM Express for which you want to set up the test.

Step 5 In the Run pane, schedule when to run the test.

Step 6 Click Create.

Creating an End-to-End Call Synthetic Test

You have the option of configuring the target phone as a real phone or a synthetic phone. The default setting is a synthetic phone.

SIP-based end-to-end call tests that include a non-virtual destination phone with RTP enabled will not work under NAT/multiple end-customer environments. The test execute, but only the signaling portion passes. The RTP transmission will fail.

In this instance, the test is run to a real phone with the Enable RTP transmission option selected. The End-to-End Call Test is unable to do media transmission to a phone in a NAT environment.

Note Do not create more than 100 end-to-end call tests that run at 1-minute intervals. Configure any additional end-to-end call tests to run at various intervals greater than 1 minute.

You can use the Select Voice Application group selector in the left pane to enter a device: Select the device in the group selector, and then click the arrow button next to the Cisco Unified Communications Manager/Express field.

b. Enter the synthetic phone's MAC address.

If you used the group selector to choose the Cisco Unified Communications Manager or Cisco Unified Communications Manager Express system, the MAC address field is automatically populated. See Application Configuration for Synthetic Tests for MAC address limitations.

The SIP URI should be in the format sip:extn@ccm; for example, sip:7690@ct-sd.cisco.com.

Step 4 In the Recipient pane, do the following:

a. Select either the Synthetic Phone or Real Phone radio button.

b. Enter the name or IP address of the Cisco Unified Communications Manager or Cisco Unified Communications Manager Express system (if you selected the Real Phone radio button, this option is grayed out).

You can use the Select Voice Application group selector in the left pane to enter a device: Select the device in the group selector, and then click the arrow button next to the Cisco Unified Communications Manager/Express field.

c. Enter the phone's MAC address (if you selected the Real Phone radio button, this option is grayed out).

d. Select a protocol type (if you selected the Real Phone radio button, this option is grayed out).

e. Select a parameter type (if you selected the Real Phone radio button, this option is grayed out): If you select Extension, enter the extension for the phone. If you select SIP URI, enter the URI.

The Parameters area is grayed out when Synthetic Phone is selected.

Step 5 In the Parameters pane, do the following:

•(Optional) Select Wait for Answer. If you selected the Synthetic Phone radio button, this option is grayed out.

•(Optional) Select Enable RTP transmission. If you selected the Synthetic Phone radio button, this option is grayed out.

•Choose a criterion for success, either Call Success or Call Failure.

•If desired, you can change the call setup time threshold setting (default is 10000 milliseconds).

The call setup time threshold measures the time between when you are done dialing the number to when the Cisco Unified Communications Manager sets up the call (using SIP or SCCP phones). If the threshold is exceeded, a warning event is generated.

If desired, you can change the dial-tone time threshold setting (default is 500 milliseconds).

The dial-tone time threshold measures the time between when an SCCP phone goes offhook to when it receives a dial tone from Cisco Unified Communications Manager. If the threshold is exceeded, a warning event is generated.

If desired, you can change the registration time threshold setting (default is 2000 milliseconds). The phone registration threshold measures the time that it takes for a phone (SIP or SCCP phone) to register with a Cisco Unified Communications Manager. If the threshold is exceeded, a warning event is generated.

Step 8 In the Run pane, schedule when to run the test.

Step 9 Click Create.

Importing Synthetic Tests

You can import multiple synthetic tests at one time by using a comma-separated values (CSV) file.

Each specifier can be a number, a range, comma-separated numbers and a range, or an asterisk.

Month and days of the month fields cannot be changed. You should enter an asterisk (*).

Day of week can have an asterisk to represent all days, or it can have a comma-separated list of days. For Hour, you can enter an asterisk to represent 24 hours, or you can enter a range. Minute can be an asterisk, to represent all, or it can be a range.

Day of week can have an asterisk to represent all days, or it can have a comma-separated list of days. For Hour, you can enter an asterisk to represent 24 hours, or you can enter a range. Minute can be an asterisk, to represent all, or it can be a range.

Only the following schedule types are supported:

•*;*;*;*;* —All days, 24 hours

•*;*;2-4;*;* —Tuesday to Thursday, 24 hours

•*;*;*;8-20;* —All days between 8:00 a.m. and 8:00 p.m.

•*;*;*;8;20-59:*;*;*;9-19;*:*;*;*;20;0-40 —All days between 8:20 a.m. and 8:40 p.m.

Managing Synthetic Tests

The following table describes the tasks that you can perform from the Synthetic Tests page:

Tasks

Description

Exporting Synthetic tests

You can export the synthetic tests that you have created to a file on your Prime Collaboration server. If needed, you can use this file to import your configured synthetic tests back into Prime Collaboration, or to import the tests into another Prime Collaboration system.

Editing Synthetic tests

Every time you create or edit a test that requires a phone extension number and a MAC address, you should edit them as a pair. Do not edit one independently of the other.

Viewing Synthetic test details

In the Synthetic Test Details page you can view the parameters that have been configured for a test.

The details displayed vary depending on the type of test.

Starting and stopping Synthetic tests

Synthetic tests can be started or stopped. You can select multiple tests at one time to start or stop. If a test is running while you are trying to stop it, a message appears stating the test's details.

Viewing Synthetic test results

The results are displayed in a report format. As with any of the reports in Prime Collaboration, you can print the report or export it to a file.

The Synthetic Tests Results report provides the following information:

•The Test status (passed or failed).

•The day and time that the test finished.

•Any error messages.

Scheduling Synthetic tests

When you create a synthetic test, you have the option of running the test now, or scheduling the test to run at regular intervals.

If you want to change the time at which the test should run, you must edit the synthetic test in the Edit Synthetic Test page.

If the system time of the Prime Collaboration server is changed backward, the synthetic tests will not execute until the time has elapsed and the system time reaches the original time at which the change was done.

For example, if at 10:00 a.m. the system time is changed to 9:00 a.m., the tests will not start executing until the system time is 10:00 a.m.

Your login determines whether or not you can perform this task.

Synthetic Test Notes

Table 11-9 contains information you should be aware of while creating synthetic tests.

Table 11-9 Synthetic Test Notes

Summary

Explanation

Synthetic tests do not run for 30 minutes after the Prime Collaboration processes are started. However, during this time, you can still create, edit, or delete tests.

Starting Prime Collaboration processes places a high load on the system. To prevent synthetic tests from failing during this time, Prime Collaboration delays starting them.

You can change the default setting by doing the following:

1. Add the following default settings:

AMAMonitor.InitialDelay-30

in the /opt/CSCOpx/etc/cwsi/AMAServer.properties file (you must log in as root using SSH with port 26).

2. Stop and restart the synthetic transaction server using the following commands:

pdterm STServer

pdexec STServer

3. Start the VHMSTIntegrator process using the command:

pdexec VHMSTIntegrator

Synthetic tests may either be skipped or take an extended period of time to run if the server CPU RAM reaches 85%.

This anomaly will be reflected in the portlets.

Whenever the server CPU is greater than 85%, synthetic tests are either skipped or would take more time for execution.

Therefore, the portlet data about these tests will reflect a lesser number of tests executed than scheduled per hour. To avoid this situation, schedule tests during off-peak hours.

When the interval of a synthetic test is decreased from a high value to a low value, the first results for the new value may take longer than the new interval to report.

Each synthetic test executes at a time that is controlled by its interval setting. Immediately after you decrease the interval setting for a synthetic test, that transaction might not run until the time elapsed is longer than the new interval.

For example, if you decrease an interval from 180 seconds to 60 seconds, the first results for the new interval may take as long as 240 seconds to report.

One-time synthetic test failures sometimes occur.

Occasionally, one-time synthetic test failures occur. Such failures can be due to high loads on the Prime Collaboration or other factors that cause Prime Collaboration to be unable to receive some events from applications.

Cisco Unity message-waiting indicator synthetic tests may fail.

If a Cisco Unity synthetic test fails and the Message-Waiting Indicator light is on, you must configure a real phone with the same extension number used in the test and delete the voicemails manually.

Alternatively, you can use the Message Store Manager tool to remove the voicemails. After this is completed, the test will pass.

End-to-end call test may fail in NAT environment.

The end-to-end call synthetic test is not supported when phones are in a NAT environment. In this instance, the test is to a real phone with the Enable RTP transmission option selected. The end-to-end call synthetic test is unable to do media transmission to a phone in a NAT environment.

Node-to-Node Tests

Node-to-Node tests monitor the response time and availability of multiprotocol networks on both end-to-end and hop-by-hop basis. After collecting this data, you can use the Prime Collaboration graphing function to examine changes in network performance metrics. You can select, display, and chart network performance data in real time.

Node-to-node tests can be configured to trigger events when certain thresholds are crossed.

You can create node-to-node tests one at a time, or import a file to create more than one test at a time.

You can create the following node-to-node tests:

Test Name

Description

UDP Jitter for VoIP

Starting Prime Collaboration processes places a high load on the system. To prevent synthetic tests from failing during this time, Prime Collaboration delays starting them.

This test uses the UDP protocol to measure latency, one-way jitter, and packet drop. Jitter is interpacket delay. The source device sends a number of packets from the source device to the destination device with a specified interpacket delay.

The destination (an IP SLA Responder) time stamps the packet and sends it back. Using this data, the one-way positive and negative jitter (from the source to the destination and back again), packet loss (also from the source to the destination and back again), and round-trip latency are obtained.

Positive jitter occurs when the one-way delay for a packet is longer than the previous packet delay. Negative jitter occurs when the one-way delay for a packet is shorter than the previous packet delay. If the sequence numbers become jumbled, the test reflects the error.

Ping Echo

Measures end-to-end response time between a source device and any IP-enabled device.

The test sends ICMP packets from the source device to the destination device and measures the time it takes to complete the round trip.

Ping Path Echo

Measures hop-by-hop response time between a source device and any IP device on the network by discovering the path using traceroute, and then measuring response time between the source device and each hop in the path.

Note If you want to change the Round-Trip Response Time threshold, in the Thresholds pane, select the check box and enter a new setting (default is 300 m/secs). The setting must be a positive integer (32 bit).

UDP Echo

Measures UDP response time between a source device and any IP-enabled device.

The UDP echo test sends a packet with the configured number of bytes to the destination with the specified port number and measures the response time.

There are two destination device types for the UDP echo operation: RTR Responders, which use IP SLA, and UDP servers, which do not.

Gatekeeper Registration Delay

Measures the time required for a gateway to register with a gatekeeper.

This test sends a lightweight Registration Request (RRQ) from an H.323 gateway to an H.323 gatekeeper and receives a Registration Confirmation (RCF) from the gatekeeper. The test then measures the response time.

For the Gatekeeper Registration Delay test to run, the source gateway must have SIP or H323 configured on it.

Real-Time Transport Protocol

Measures voice quality metrics from DSP to DSP by integrating with the DSP software. The operation involves placing a test call from the source gateway to the destination, sending actual RTP packets and then collecting statistics from DSPs.

This test provides DSP-to-DSP measurement of voice quality metrics by integrating with the DSP software. Test calls are placed from the source gateway to the source destination, sending actual real-time protocol (RTP) packets and then collecting statistics from DSPs.

In some networks, the remote end may not have DSP. In such situations, the real-time protocol test should measure the metrics by making the remote end loop back the RTP stream.

The Real-time Transport Protocol test includes delays in the voice path (path from telephony interface to IP interface on originating gateway and path from IP interface to telephony interface on terminating gateway) in these measurements.

Note For the real-time transport protocol test to run, the source must have a dsp module type of either C5510 or C549 and must have ds0-group of voice ports configured on it.

Retention period for node-to-node test result data is 30 days. If you want to retain node-to-node test or performance polling data files beyond the retention period, you should back them up or move them to another folder or server.

Note Before uninstalling Prime Collaboration, be sure to delete all the node-to-node tests from the application. If you do not delete these tests, they will continue to run on the router.

Required Cisco IOS and IP SLA Versions

Node-to-node tests rely upon Cisco IOS IP SLA technology.

Table 11-10 lists the versions of IP SLA and Cisco IOS that are required to successfully configure and run each type of node-to-node test.

If you recently added an IP SLA-enabled device and it does not appear in the IP SLA Devices group in the selector in the Source pane on the Node-to-Node Test Configuration dialog box, refresh the device group membership (Operate > Device Work Center).

•Choose a source interface setting. You can leave it at Default, or enter a new setting.

Step 5 In the Destination pane, select a destination device using the device selector.

If you want to swap the source and destination devices with each other, click the Swap Source and Destination button.

Threshold Setting. A numerical score derived from other VoIP metrics, such as latency, jitter and packet loss, per ITU-T recommendation G.107. A typical range is 50-90, with a score of 80 or higher indicating satisfactory VoIP call quality. Default is 40.

Conversational Quality

Threshold Setting. Tracks the conversational audio signals based on these settings: Excellent, Good, Fair, and Poor. Default is Fair.

Listening Quality

Threshold Setting. Tracks the listening audio signals based on these settings: Excellent, Good, Fair, and Poor. Default is Fair.

Operation-Specific Parameters

When and how often the test runs.

Polling Time

Number of times in minutes in a 24-hour period during which polling occurs.

Occurrence Pattern

Dates on which the test starts and ends, and hours during which the test is scheduled to run. If the test runs weekly, the Schedule parameter displays days of the week when the test is scheduled to run.

Test Name

User-defined test name. Prime Collaboration also uses the test name to name the folder in which test data is stored. See the description of the Data Directory field in this table.

Importing Multiple Node-to-NodeTests

You can import up to 64 tests, the maximum that Prime Collaboration can support, by importing a seed file.

To import multiple tests:

Before You Begin

•Before you can import a test, you must first add the source devices.

•Make sure your seed file is formatted correctly.

•Place the seed file on the server, in the /opt/CSCOpx/ImportFiles directory. You must log in as root using SSH with port 26 to copy this file.

For example, Node_to_nodetestImport.txt. The file must be located on the server in the directory that is displayed next to the Server Path field name.

Step 3 Click OK.

Prime Collaboration performs the following actions:

•If this is a file you have imported before, Prime Collaboration checks to see if any of the devices exist in Prime Collaboration. If all the information in the import file is the same as what already exists in Prime Collaboration, a message to that effect appears. Click OK.

•Prime Collaboration displays an error message if there are problems with the format of the import file. Click OK, then open the file and correct the listed problems. You cannot import the file until all problems are corrected.

•If there are no errors, a confirmation dialog box appears. The dialog box displays the number of new tests created and the number of tests that will be updated. Click Yes.

Formatting Node-To-Node Test Import Files

You can import up to 64 tests, the maximum that Prime Collaboration can support at one time. You can find a sample import file for node-to-node test in the /opt/CSCOpx/Importfiles folder (you must log in as root using SSH with port 26).

All test seed files should have the following information:

•Test name

•Operation type

•Source device name

•Destination device information (it must be the private IP address of the device if it is NAT-enabled)

•Operation parameters

•Schedule parameters

The general format for a test seed file is as follows:

•If you create the import file manually, the import file header should be:

•For all days of the week, enter a one; otherwise, it should be a zero. If the entry for all days of the week is zero, then you need to enter the days of the week. Separate the days of the week with a vertical bar (|); for example, Mon|Tue|Thu|Fri.

Ping Echo Test Import File

Import File Format

<testName>,Ping-Echo,<source>,<source-ip-address>,<Destination-Name>,<sample-interval>,<IP
QosType><IPQosValue>,<request-payload>,<LSRHop1|LSRop2|LSRHop3|LSRHop4|LSRHop5|LSRHop6|LSR
Hop7|LSRHop8>,<completionTimeThreshold or "">,<start-time>,<end-time>,<AllDaysOfWeek. 1
for all days otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>

<testName>,Ping-Path-Echo,<source>,<source-ip-address>,<Destination-Name>,<sample-
interval>,<IPQosType>,<IPQosValue>,<request-payload>,<completionTimeThreshold or "">
,<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days otherwise 0>,<DaysOfWeek, if
AllDaysOfWeek is 0>

<testName>,Data-Jitter,<source>,<source-ip-address>,<IPSLA-Responder>,<sample-interval>,
<IPQosType>,<IPQosValue>,<request-payload>,<inter-packet-interval>,<number-of-packets>,
<destination-port>,<pktlossSDThreshold or "">,<pktlossDSThreshold or "">,
<jitterSDThreshold or "">,<jitterDSThreshold or "">,<avgLatencyThreshold or "">,
<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days otherwise 0>,<DaysOfWeek, if
AllDaysOfWeek is 0>

<testName>,Data-Jitter,<source>,<source-ip-address>,<IPSLA-Responder>,<sample-interval>,
<IPQosType>,<IPQosValue>,<codecType>,<voiceQualityBenchMark>,<number-of-packets>,
<destination-port>,<pktlossSDThreshold or "">,<pktlossDSThreshold or "">,
<jitterSDThreshold or "">,<jitterDSThreshold or "">,<avgLatencyThreshold or "">,
<nodeToNodeQualityThreshold or "">,<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days
otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>

Read-community-string is an optional field. If you specify a community string, Prime Collaboration validates the IP SLA Responder.

VoIP Gatekeeper Registration Delay Test (Scheduled Daily)

Import File Format without Codec (Node-to-Node Quality) Support

<testName>,Voip-GKReg-Delay,<source GateWay>,<sample-interval>,
<GatekeeperRegistrationTimeThresholdor "">,<start-time>,<end-time>,<AllDaysOfWeek. 1 for
all days otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>

Managing Node-to Node Tests

The following table describes the tasks that you can perform from the Node-to Node Test page:

Tasks

Description

Editing Node-to Node tests

You can use this function to edit the parameters of an existing test. For example, you can change the operation parameters of a test or change the schedule. You cannot change the destination device.

To edit the tests, select the the test you want to edit, and then click Edit.

Deleting Node-to Node tests

You can use this function to delete one or more tests. You can delete tests in any state. To delete the tests, select the test you want to edit, and then click Delete.

View test trending

You can select and examine changes in network performance metrics. You can select, display, and chart network performance data in real time. To view test trending, select the test you want to trend, and click Trend.

If you have selected a UDP Jitter for VoIP test, you get an option to select the graph and then the Node-to-Node Test Trend graph is displayed. The graph selection option is not displayed for other Node-to-Node tests.

Viewing test information

You can find all the details about a particular test on the Test Details page. From this page, you can print or export test information.

To view test information, select the test you want to view, and click View.

Exporting test details

You can export and save all the details about a single test as shown on the Test Details page, including configuration and status. To export test details, select the test you want and click View. Click the export icon in the upper-right corner of the window.

Node-To-Node Test Result

The threshold settings that you set during test creation or during modification determine when a node-to-node event is generated.

The events are raised on the source device. A threshold event is generated when the threshold violation occurs for three consecutive polling cycles. The event is cleared if the value falls below the threshold in the following polling cycle.

The following node-to-node events can be generated:

•NodeToNodeTestFailed

To determine why a Node-to-Node test failed and how to clear it, see the IP SLA documentation located on Cisco.com.

•RoundTripResponseTime_ThresholdExceeded

•RingBackResponseTime_ThresholdExceeded

•RegistrationResponseTime_ThresholdExceeded

•AverageLatency_ThresholdExceeded

•PacketLossSD_ThresholdExceeded

•PacketLossDS_ThresholdExceeded

•IAJitterDS_ThresholdExceeded

•JitterDS_ThresholdExceeded

•Quality Dropped Below Threshold

•RFactorDS_ThresholdExceeded

•MosCQDS_ThresholdExceeded

•MosLQDS_ThresholdExceeded

•RTPPacketLossDS_ThresholdExceeded

You can verify whether a test ran and completed correctly. You can also troubleshoot the test if necessary. To do this, select Administration >System Setup > Diagnostic Tests > Node-to-Node Tests.

The Node-to-Node Tests page appears. All current Node-to-Node tests appear in the page. The last column in the table shows the status of each test.

Table 11-16 Test Status Definitions

Test Status

Description

Running

Test is active and collecting data.

Config Pending

Either the device is not responding or configuration of the test is under way.

Delete Pending

Intermediate state, before the test is deleted. No actions can be performed on the test.

Suspended

Test is suspended from data collecting or polling. This occurs because the device was suspended.

Scheduled

Appears after you create or update a test. The status will change to Running at the first polling cycle.

Dormant

Test is active but not currently collecting data. Tests are in the Dormant state between polling cycles.

Storing Node-To-Node Test Data

Node-to-node test data is stored on the Prime Collaboration server in the /opt/CSCOpx/data/N2Ntests folder. The node-to-node test data is retained for 30 days. The two different types of files stored in the data storage directory are:

•YYYYMMDD.csv—Test data. Each file has multiple records. Each record is a comma-separated values (CSV) record, and there is one record in a file for each polling interval.

All configuration information for the node-to-node-test is available in the file IPSLATestInfo.log.

Maintaining Node-To-Node Test Data

You should perform all the following tasks to maintain the test data:

•Verify that there is sufficient disk space to store test data. Check disk space before a test is scheduled to run. Prime Collaboration appends data to a test's log files. Prime Collaboration produces one data file for each running test per day when a test is running. Assess the amount of space used by previous tests to derive an estimate. For example, a test with a 16-hour polling cycle and a 1-minute sampling interval uses approximately 60 to 100 KB per day. A path echo test with a 16-hour polling cycle, a 1-minute sampling interval, and 12 hops uses approximately 1.2 MB per day.

•Export and save test data.Prime Collaboration purges all data files more than 31 days old. You must save the test to another server to maintain data for more than 31 days.

•Back up the test data.Prime Collaboration writes test data to the Data Storage Directory, displayed in the Test Details window. Perform regular backups using the same method you use to back up your file system.

•Determine when to copy data to another server. You should copy test data to another server before you examine it.

•Display and use the data.You can analyze the results of the test after you import the test data into Microsoft Excel or by using a third-party report-generating tool.

Do not open test data files using any application that acquires an exclusive read-only lock on files while the test is in the Running state. If test data files are locked, Prime Collaboration will not be able to write output data and will instead write errors to the log files.

Examples of applications that acquire an exclusive lock are Microsoft Excel and Microsoft Word. You can use these applications when the test is not running.

Copying Test Data to Another Server

You must copy test data to another server before you examine it. You may also want to copy the test data to another server as a means of backup. Test data is in ASCII format. You can copy it to another server using whatever method is available to you; for example, SSH or copy-and-paste.

Copy the test data files from the Data Storage Directory. Test data files are those whose names end with .csv, because the test data is written to CSV files.

Data Format

The Echo test data record format captures end-to-end statistics for the following types of tests:

•ICMP Echo

•UDP Echo

•Gatekeeper Registration Delay

Table 11-17 Echo Test Data Format

Field
Number

Field ID

Content

Description

Value

1

Record ID

nnn

Record type 200

200

2

Date

yyyymmdd

Calendar date

Example: 20070201

3

Time stamp

hhmmss

Wall clock time

Example: 230000

4

Completion time

Number

Round-trip time (RTT), in milliseconds

Between 0 and 4294967295

5

Completion status

Number

The allowed numbers are:

•1—OK

•2—disconnected

•3—overThreshold

•4—timeout

•5—busy

•6—notConnected

•7—dropped

•8—sequenceError

•9—verifyError

•10—applicationSpecific

•11—dnsServerTimeout

•12—tcpConnectTimeout

•13—httpTransactionTimeout

•14—dnsQueryError

•15—httpError

•16—error

Between 1 and 16

6

Application-specific completion status

Number

(Optional) An application-specific status that is valid only when completion status is set to applicationSpecific (10).

Between 1001 and 2147483647

7

Status description

Number

(Optional) The description for the completion status when completion status is set to applicationSpecific (10). Default value is blank.

ASCII characters

8

None

Null indicator

Not used

*

Note Fields 9 through 37 are not used and contain the null indicator "*".

38

Test name

Text

Name of the node-to-node test

Sjc-VGtest

The Ping Path Echo record format captures hop-by-hop statistics for Ping Path Echo tests. The tests record information from source to destination.

Table 11-18 Hop-by-hop Statistics for Ping Path Echo Test Data Format

Field
Number

Field ID

Content

Description

Value

1

Record ID

nnn

Record type 201

201

2

Date

yyyymmdd

Calendar date

Example: 20070201

3

Time stamp

hhmmss

Wall clock time

Example: 230000

4

Completion time

Number

Round-trip time (RTT), in milliseconds

Between 0 and 4294967295

5

Hop ID

Number

Unique ID chosen by the study and given to a hop on this path.

Maximum value is 30

6

Hop address

String

IP Address of the hop

ASCII characters

7

Completion status

Number

The allowed numbers are:

•1—OK

•2—disconnected

•3—overThreshold

•4—timeout

•5—busy

•6—notConnected

•7—dropped

•8—sequenceError

•9—verifyError

•10—applicationSpecific

•11—dnsServerTimeout

•12—tcpConnectTimeout

•13—httpTransactionTimeout

•14—dnsQueryError

•15—httpError

•16—error

Between 1 and 16

8

Application-specific completion status

Number

(Optional) Application-specific status that is valid only when completion status is set to applicationSpecific (10).

Between 1001 and 2147483647

9

Status description

Text

(Optional) Description for the completion status when completion status is set to applicationSpecific (10). Default value is blank.

ASCII characters

10

None

Null indicator

Not used

*

Note Fields 11 through 37 are not used and contain the null indicator "*".

38

Test name

Text

Name of the node-to-node test

Sjc-VGtest

This record format captures end-to-end statistics for Ping Path Echo tests. The tests are from the source to the destination.

Table 11-19 End-to-end Statistics for Ping Path Echo Test Data Format

Field Number

Field ID

Content

Description

Value

1

Record ID

nnn

Record type 204

204

2

Date

yyyymmdd

Calendar date

Example: 20070201

3

Time stamp

hhmmss

Wall clock time

Example: 230000

4

Completion time

Number

Round-trip time (RTT) in milliseconds

Between 0 and 4294967295

5

Hop ID

Number

Unique ID given to a hop on this path chosen by the study. For this record, the hop ID is always 1.

1

6

Hop address

String

Mandatory: IP address of the destination

ASCII characters

7

Completion status

Number

The allowed numbers are:

•1—OK

•2—disconnected

•3—overThreshold

•4—timeout

•5—busy

•6—notConnected

•7—dropped

•8—sequenceError

•9—verifyError

•10—applicationSpecific

•11—dnsServerTimeout

•12—tcpConnectTimeout

•13—httpTransactionTimeout

•14—dnsQueryError

•15—httpError

•16—error

Between 1 and 16

8

Application-specific completion status

Number

(Optional) The application-specific status that is valid only when Completion Status is set to applicationSpecific (10).

Between 1001 and 2147483647

9

Status description

Text

(Optional) This is the description for the completion status when Completion Status is set to applicationSpecific (10). Default value is blank.

ASCII characters

10

None

Null indicator

Not used

*

Note Fields 10 through 37 are not used and contain the null indicator "*".

Step 3 Enter the name of the seed file in the Filename field and click OK.

The scheduled time and day for a batch test is configured in the import file. If you want to run a batch test on demand, you can use the Run Now button.

Formatting Batch Test Import Files

The batch test import file is an XML file. You can find an example of an import file (batchtest.xml) in the /opt/CSCOpx/ImportFiles folder.

A batch test import file contains information for one batch test. Each batch test import file contains all the information required to configure the synthetic tests and phone tests for that particular batch test.

When creating a batch test import file, observe the following guidelines for the listed fields:

•PhoneMACAddress—The MAC address of a synthetic phone. It must be in the range of 00059A3B7700 to 00059A3B8AFF.

Note Soft phones will display the device name in the MAC address fields.

•PhoneProtocol—The protocol of the synthetic phone, either SCCP or SIP.

•PhoneURIorExtension—The extension or URI of a SIP phone. This is ignored for SCCP phones.

•OnsiteAlertNumber—Required only when IsOSANEnabled is set to true.

•DialingNumber—Optional. PhoneNumber is used if no input is present. This field is valid for intercluster call only. It must provide the complete number that has to be dialed from source phone to reach destination phone on a different cluster.

For example, just the phone number or the dial pattern/access digits plus the phone number.

You can change an existing batch test by importing a new batch test import file. The previous batch test information is overwritten by the new import file. To change the import file, you must manually edit the file.

Managing Batch Tests

The following table describes the tasks that you can perform from the Batch Test page.

Tasks

Description

Viewing Batch Test Details

You can see all details about a particular batch test on the Test Details page. This page lists all the synthetic tests and phone tests that are part of the batch test.

•If the batch test is active and you want to stop it from running, click Suspend.

•If the batch test is suspended and you want it to run it at its scheduled time, click Resume.

The scheduled time and day that a batch test is to run is configured in the import file (see Ping Echo Test Import File). But if you want to run a batch test on demand, you can use the Run Now button.

Viewing batch test results

No events are generated when a component of a batch test fails. You must use the Batch Test Results report to see the results of a batch test. A new Batch Test Results report is generated every 24 hours for each batch test.

Prime Collaboration saves the data collected by the batch tests on the Prime Collaboration server in the /opt/CSCOpx/data/bt folder.

The Batch Test Results report provides the following information for the overall batch test:

•Test status

•Date and time that the test started and finished.

The Batch Test Results report provides the following information for the individual tests that are a part of the batch test:

•Test type.

•Whether or not it is a negative test.

•Test status (passed or failed).

•Date and time that the test finished.

•Any error messages.

To view the results of a batch test, choose Administration > System Setup > Diagnostic Tests > Batch Tests. In the Batch Tests page, select the batch test that you want to see the results for, and click Results.

Printing batch test results

In a batch test report, click the printer icon in the upper-right corner of the window.

Exporting batch test results

You can use the export functionality to save the test results on your client system.

To export the results of a batch test:

1. In a batch test report, click the export icon in the upper-right corner of the window.

2. Select either CSV or PDF format for export and click OK.

Deleting batch tests

To delete a batch test, choose Administration > System Setup > Diagnostic Tests > Batch Tests. In the Batch Tests page, select the batch test that you want to change and click Delete.

Phone Tests—Batch and on Demand Tests

The phone tests that are run as part of batch testing and on-demand testing take control of a real phone in the network and make a call from that phone to another phone. Phone tests use JTAPI credentials.

For the phone test feature in Prime Collaboration to work properly, the JTAPI credentials need to be configured in Cisco Unified CM as well.

While creating a phone test, follow these guidelines:

•The test phones and test probes must belong to the same Cisco Unified CM because Prime Collaboration takes control of these phones and probes through Cisco Unified CM using JTAPI. If the test phones (phones being tested) and test probes (phones being used to run the tests) belong to a different Cisco Unified CM, the tests will fail.

•Only when the call test type is an intercluster call can the destination phone belong to a different Cisco Unified CM. In this instance, the user needs to provide the credentials of the destination Cisco Unified CM in the XML file.

•An example of an import XML file for batch phone testing is provided in /opt/CSCOpx/ImportFiles/batchPhoneTests.xml. You must log in as root using SSH (port 26).

•Before running the phone tests, verify that the configurations are correct in Cisco Unified CM and that the various phone operations are working using the real phones.

Note Do not confuse these phone tests with other Prime Collaboration phone tests (synthetic tests or phone status tests). These phone tests are created as part of batch testing and can also be launched on-demand, from IP Phone reports. These tests take control of real phones to conduct the tests.

The call is removed from phone B and a message is displayed to tell you where the call is parked (for example, Call Park at 80503).

3. Has phone C dial the number where the call is parked.

The parked call is transferred to the phone that you made the call from.

4. Disconnects the call.

Call Conference

Takes control of three phones and performs the following:

1. Places a call from phone A to phone B.

2. Places a conference call from phone A to phone C.

3. Disconnects the call.

Call Transfer

Takes control of three phones and performs the following:

1. Places a call from phone A to phone B.

2. Has phone B transfer the call to phone C.

3. Has phone C accept the call.

4. Disconnects the call.

Call Test

Takes control of a phone and places a call to a given number. The call can be from a real phone to a number, in which case the test is controlling the caller only.

Alternatively, the call can be from a real phone to a real phone, in which case the test is controlling both the caller and the receiver.

Creating a Phone Test on Demand

You can select one or more phones from an IP Phones/Lines report display and run a phone test on demand. The selected phones must belong to the same Cisco Unified Communications Manager. Phone tests use the JTAPI credential. The JTAPI credential must be configured in Communications Manager.

The JTAPI phone tests support E.164 ("+") dialing and phones with extensions in this format.

To create a phone test, choose Administration > System Setup > Diagnostic Tests > Phone Tests. Table 11-22describes the fields, which you can select while creating the on-demand phone test.

Table 11-22 On-Demand Phone Test

Item

Description

Cisco Unified Communications Manager

Lists the Communications Manager for the phones selected from the phone report.

You can select a Cisco Unified Communications Manager from the left pane and click the >> button to add it to the Cisco Unified Communications Manager field.

The previous Test Phones and Helper Phones selections are cleared; you will need to specify them again.

JTAPI Username and JTAPI Password

Enter the JTAPI username and password configured on the Communications Manager.

Test Phones

To add more phones to Test Phones:

1. Click Add from Phone Report.

2. In the phone report window, select the additional phones to add and click Select.

The phones added must belong to the same Cisco Unified Communications Manager provided at the beginning for this test.1

Helper Phones

To add more phones to Helper Phones:

1. Click Add from Phone Report.

2. Select the additional phones to add and click Select.

The phones added must belong to the same Cisco Unified Communications Manager provided at the beginning for this test.1

Phone Tests

Select the phone test that you want to see the results for (see Table 11-21).

When Call Test is selected, Call Type, Success Criterion, and Phone Number fields are enabled.

Call Type

From the drop-down list, choose the call type.

When Inter Cluster Call is selected, the following fields are enabled:

•Cisco Unified Communications Manager

•JTAPI Username

•JTAPI Password

Success Criterion

From the drop-down list, choose the success criterion.

Phone Number

The destination phone number to be dialed for the call test needs to be specified in this field.

Dialing Number

When Inter Cluster Call is selected for Call Type, enter the complete phone number that the source phone must dial to reach the destination phone on a different cluster.

This may include dial pattern or access digits, for example 94151234567.

This field is not mandatory. If left blank, the Phone Number field is used instead.

Cisco Unified Communications Manager

When Inter Cluster Call is selected for Call Type, enter the Cisco Unified Communications Manager for the phone number specified in the Phone Number field.

JTAPI Username and Password

When Inter Cluster Call is selected for Call Type, enter the JTAPI username and password for the Cisco Unified Communications Manager provided in the previous field.

1If you select a single phone which shares its extension with other phones in the personalized report, the report generated will have details about all the phones (including the selected phone).

If the phone tests fail and display the message Unable to create provider verify:

•The JTAPI username and password is created in Communications Manager and that the phones used in the test are assigned to the same JTAPI user. For the phone test feature in Prime Collaboration to work properly, the JTAPI credentials need to be configured in Communications Manager as well.

•The JTAPI implementation in Communications Manager may have been modified; as a result the JTAPI Java Archive (JAR) files need to be updated in Prime Collaboration.