Cisco Prime Collaboration Assurance Guide, 9.5
Diagnostics for Voice Endpoints
Downloads: This chapterpdf (PDF - 498.0KB) The complete bookPDF (PDF - 4.16MB) | Feedback

Table Of Contents

Diagnostics for Voice Endpoints

Phone Status Test

Creating a Phone Status Test

Importing Phone Status Test

Formatting Phone Status Test Import File

Synthetic Test

Application Configuration for Synthetic Tests

Creating an Emergency Call Synthetic Test

Creating a Message-Waiting Indicator Synthetic Test

Creating a TFTP Download Synthetic Test

Creating an End-to-End Call Synthetic Test

Creating Dial-Tone Synthetic Tests

Creating a Phone Registration Test

Importing Synthetic Tests

Formatting Synthetic Test Import Files

Managing Synthetic Tests

Synthetic Test Notes

Node-to-Node Tests

Required Cisco IOS and IP SLA Versions

Creating a Node-to-Node Test

Importing Multiple Node-to-Node Tests

Formatting Node-To-Node Test Import Files

Managing Node-to Node Tests

Node-To-Node Test Result

Node-to-Node Test Data

Storing Node-To-Node Test Data

Maintaining Node-To-Node Test Data

Copying Test Data to Another Server

Data Format

Creating a Batch Test

Formatting Batch Test Import Files

Managing Batch Tests

Phone Tests—Batch and on Demand Tests

Creating a Phone Test on Demand


Diagnostics for Voice Endpoints


Prime Collaboration enables you to run multiple diagnostics tests to identify issues related to UC phone network.

You can run the following diagnostics tests for voice endpoints:

Phone Status Test

Synthetic Test

Node-to-Node Tests

Creating a Batch Test

Phone Tests—Batch and on Demand Tests

Phone Status Test

Phone status testing uses Cisco IOS IP SLA technology to monitor the reachability of key phones in the network.

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.

Phone status tests continue to run, except when phone information (IP address or extension number) changes and phone-related devices are not monitored by Prime Collaboration; update the seed file and add the test again.

You can create phone status tests by using the Create Phone Status Test page or by using a seed file.

If you want to configure the test on the IP SLA-capable device closest to the new Cisco Unified Communications Manager, update the seed file and add the test again.


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


Creating a Phone Status Test

You can create phone status tests to monitor the reachability of key phones in the network.

To create a phone status test using the Create Phone Status Test page:

Before You Begin

You must be able to provide IP SLA-capable devices and IP phones (extensions and IP addresses) for testing.

Phone status tests do not require information from Prime Collaboration device inventory. However, when Prime Collaboration monitors phone-related devices, it can update phone status tests whenever phone information changes.

The source device for a phone status test must be monitored in Prime Collaboration.


Step 1 Choose Administration > System Setup > Diagnostic Tests > Phone Status Tests.

Step 2 Click Create.

Step 3 In the Source pane, use the device selector to select a source device, or enter the device's name (or IP address) in the Name field.

Step 4 Click the Add from Phone Report button.

Step 5 On the Audio Phones/Lines report, check the check box next to the phones for which you want to add the test, and click Select.

Step 6 In the Run area of the Create Phone Status Test page, do the following:

Schedule when to run the test.

Enter a name for the test.

Check the Do not use ping from Cisco Prime Collaboration server check box to disable ping from Prime Collaboration server.

Step 7 Click OK.


Importing Phone Status Test

You can create phone status test by importing a seed file with a list of extensions to include in the test.

Before you Begin

Verify that your seed file is formatted correctly. For details, see Formatting Phone Status Test Import File.

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.

To create a phone status test using a seed file:


Step 1 Choose Administration > System Setup > Diagnostic Tests > Phone Status Tests.

Step 2 Click Import.

Step 3 Enter the name of the seed file.

Step 4 In the Run area, do the following:

Schedule when to run the test.

Enter a name for the test.

Check the Do not use ping from Cisco Prime Collaboration server check box to disable ping from Prime Collaboration server.

Step 5 Click OK.


Formatting Phone Status Test Import File

A phone status testing seed file should list all the phones that are to be tested. You can use a six-column or eight-column file format. The first six columns are the same for both file formats.

The information that you must provide for each phone is extension number, IP address, and MAC address. For:

Shared lines—Enter one or both phones; Prime Collaboration can run one test for each phone on a shared line.

Multiple extensions—Even if you enter multiple extensions for a phone, Prime Collaboration runs only one test for the phone.

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

You can use a six-column or eight-column file format. The first six columns are the same for both file formats. Each line of the seed file must contain:

Six or eight columns. If a column is not used, you must enter a space.

Colons separating the columns.

You must also provide the IP address and read and write community strings for the router closest to the Cisco Unified CM to which the phone is registered.

Table 21-1 shows the seed file format for testing the phone status.

Table 21-1 Seed File Format for Phone Status Testing 

Column Number
Description

1

Phone extension.

2

Phone MAC address.

3

Phone IP address.

4

IP SLA-enabled device (router, switch, or voice router).

5

Read community string for the IP SLA-enabled device.

6

Write community string for the IP SLA-enabled device.

7

SNMPv3 username (used in the eight-column format only)

8

SNMPv3 password (used in the eight-column format only)


Example 21-1 shows a sample six-column import file.

Example 21-1 Phone Status Testing Six-Column Import File

[Extension]:[MAC Address]:[IPAddress]:[IPSLA Router]:[Read Community]:[Write community]
 
 
4000:200000000001:172.20.121.1:10.76.34.194:private:private 
 
 
Example 21-2 shows a sample eight-column import file.

Example 21-2 Phone Status Testing Eight-Column Import File

2) [Extension]:[MAC Address]:[IPAddress]:[SAA Router]:[Read Community]:[Write community]: 
[snmpv3UserName]:[snmpv3Passwd]
 
 
#4000:200000000001:172.20.121.1:10.76.34.194:!{[NOVALUE]}!:!{[NOVALUE]}!:admin:admin

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 21-2 lists the synthetic tests and the results that each test must produce to pass.

Table 21-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.

Only Cisco 7960 IP Phones are simulated as synthetic endpoints in synthetic tests.

If the synthetic phones are not preconfigured in Cisco Unified CM and Auto Registration is enabled, then the first execution of synthetic tests will fail but subsequent executions will work properly.

See "Synthetic Test Worksheets" for list of worksheets that can help you in configuring applications and determining the phones for synthetic tests.

Creating an Emergency Call Synthetic Test

For the target phones, the outgoing PSAP must use a local phone (not 911). Also, for the OSAN, use a synthetic phone only (do not use your local onsite security phone).


Note The Emergency Call synthetic test is supported only on Cisco Emergency Responder 1.2.


To create an emergency call synthetic test:


Step 1 Choose Administration > System Setup > Diagnostic Tests > Synthetic Tests.

Step 2 Click Create.

Step 3 From the Test Type drop-down menu, select Emergency Call Test.

Step 4 In the CER Parameters pane, do the following:

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.

Step 6 In the PSAP pane, do the following:

Select the Public Safety Answering Point (PSAP) Cisco Unified Communications Manager or Cisco Unified Communications Manager Express.

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:

The name or IP address of the OSAN Cisco Unified Communications Manager or Cisco Unified Communications Manager Express.

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.


To create a message-waiting indicator synthetic test:


Step 1 Choose Administration > System Setup > Diagnostic Tests > Synthetic Tests.

Step 2 Click Create.

Step 3 From the Test Type drop-down menu, select Message-Waiting Indicator Test.

Step 4 In the Unity Parameters pane, enter the Cisco Unity, Cisco Unity Express, or Cisco Unity Connection system details.

Step 5 Enter the appropriate information and click Create.


Creating a TFTP Download Synthetic Test

You can configure only one TFTP download test for each Cisco Unified Communications Manager.

To create a TFTP download synthetic test:


Step 1 Choose Administration > System Setup > Diagnostic Tests > Synthetic Tests.

Step 2 Click Create.

Step 3 From the Test Type drop-down menu, select TFTP Download Test.

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.


To create an end-to-end call synthetic test:


Step 1 Choose Administration > System Setup > Diagnostic Tests > Synthetic Tests.

Step 2 Click Create. From the Test Type drop-down menu, select End-to-End Call Test.

Step 3 In the Caller pane, do the following (Depending on the type of phone you select, some selections might become unavailable.):

a. Enter the Cisco Unified Communications Manager or Cisco Unified Communications Manager Express system.

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.

c. Select a protocol type.

d. Select a parameter type:

If you select Extension, enter the extension for the phone.

If you select SIP URI, enter the SIP Uniform Resource Identifier (SIP URI).

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.

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

Step 7 Click Create.


Creating Dial-Tone Synthetic Tests

To create a dial-tone synthetic test:


Step 1 Choose Administration > System Setup > Diagnostic Tests > Synthetic Tests.

Step 2 Click Create.

Step 3 From the Test Type drop-down menu, select Dial-Tone Test.

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

Step 5 Enter the synthetic phone's MAC address. See Application Configuration for Synthetic Tests for MAC address limitations.

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.

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

Step 7 Click Create.


Creating a Phone Registration Test

To create a phone registration test:


Step 1 Choose Administration > System Setup > Diagnostic Tests > Synthetic Tests.

Step 2 Click Create.

Step 3 From the Test Type drop-down list, select Phone Registration Test.

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 Enter the synthetic phone's MAC address. See Application Configuration for Synthetic Tests for MAC address limitations.

Step 6 Select a protocol and parameter type.

If you select Extension, enter the extension for the phone.

If you select SIP URI, enter the SIP Uniform Resource Identifier (SIP URI). The SIP URI should be in the format sip:extn@ccm; for example, sip:7690@ct-sd.cisco.com.

Step 7 Select a criteria for success (Registration Success or Registration Failure).

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.

To import synthetic tests:

Before You Begin

Verify that your seed file is formatted correctly. For details, see Formatting Synthetic Test Import Files.

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.


Step 1 Choose Administration > > System Setup > Diagnostic Tests > Synthetic Tests.

Step 2 Click Import.

Step 3 In the Import Synthetic Test page, enter the name of the seed file in the Filename field and click OK.

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


Formatting Synthetic Test Import Files

You can find a sample import file for synthetic test in the /opt/CSCOpx/ImportFiles directory (log in as root using SSH with port 26).

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

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

Cisco Systems synthetic test import, version=2.0;type=CSV;source=manual

All values must be separated with a vertical bar (|).

The schedule column must use the following formatting:

MONTH,DAYSOFMONTH,DAYSOFWEEK,HOUR,MINUTE

Month—0-11

Day of month—1-31

Day of week—0-6 (0 = sunday)

Hour—0-23

Minute—0-59

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.

Phone Registration and Dial-Tone Tests

Phone Registration test seed file format: REGISTRATION|TestName|PollInterval|Schedule|CCMAddress|MACAddress|SrcPhoneProtocol|SIPURI_OR_EXTN

Example of a Phone Registration test import file:

REGISTRATION|reg test|60|*;*;*;*;*|ipif-skate.cisco.com|00059A3B7780|SCCP|4002

Table 21-3 Import File Format for Phone Registration and Dial-Tone Tests 

Column Number
Description

1

Type of test—REGISTRATION

2

Test name.

3

Polling interval.

4

Schedule.

5

Cisco Unified Communications Manager to which the phone is connected.

6

Phone's MAC address. See Application Configuration for Synthetic Tests, for information on MAC details.

7

Phone's protocol (SCCP or SIP).

8

SIP URI or extension number.

9

Customer name.


Dial-Tone Tests

Dial-tone test seed file format:
OFFHOOK|TestName|PollInterval|Schedule|CCMAddress|MACAddress

Dial-tone test example:

OFFHOOK|dial-tone|60|*;*;*;*;*|ipif-skate.cisco.com|00059A3B7781

Table 21-4 Import File Format for Dial-Tone Tests 

Column Number
Description

1

Type of test—DIALTONE

2

Test name.

3

Polling interval.

4

Schedule.

5

Cisco Unified Communications Manager to which the phone is connected.

6

Phone's MAC address. See Application Configuration for Synthetic Tests, for information on MAC details.

7

Customer name.


End-to-End Call Test

End-to-End Call test seed file format: ENDTOENDTEST|TestName|PollInterval|Schedule|SrcCCM|SrcMAC|isDestRealPhone|DestCCM|DestMAC|Extn|WaitForAnswer|EnableRTP|SrcPhoneProtocol|SRC_SIPURI_OR_EXTN|DestPhoneProtocol

End-to-End test example:

ENDTOENDTEST|endtoend test|60|*;*;*;*;*|ipif-skate.cisco.com|00059A3B7782|FALSE 
|ipif-skate.cisco.com|00059A3B7783|4002|TRUE|FALSE|SCCP|4004|SCCP
 
 

Table 21-5 File Format for End-to-End Call Test 

Column Number
Description

1

Type of test—ENDTOENDTEST

2

Test name.

3

Polling interval.

4

Schedule.

5

Caller Cisco Unified Communications Manager.

6

Caller MAC address. See Application Configuration for Synthetic Tests, for information on MAC details.

7

Whether or not the recipient phone is a real phone. Enter true or false.

8

Recipient Cisco Unified Communications Manager.

9

Recipient MAC address. See Application Configuration for Synthetic Tests, for information on MAC details.

10

Recipient extension number.

11

Wait for answer. Enter true or false.

12

Enable RTP transmission. Enter true or false.

13

Phone's protocol (SCCP or SIP).

14

SIP URI or extension number.

15

Destinations phone's protocol (SCCP or SIP).

16

Customer name.


TFTP Download Test

TFTP Download test seed file format:

TFTP|TestName|PollInterval|Schedule|CCMAddress

TFTP download test example:

TFTP|tftp download|60|*;*;*;*;*|ipif-skate.cisco.com
 
 

Table 21-6 Import File Format for TFTP Download Test 

Column Number
Description

1

Type of test—TFTP.

2

Test name.

3

Polling interval.

4

Schedule.

5

Cisco Unified Communications Manager.

6

Customer name.


Message-Waiting Indicator Test

Message-Waiting Indicator test seed file format: MWITEST|TestName|PollInterval|Schedule|UnityAddress|SrcCCM|SrcMAC|DestCCM|DestMAC|Extn|Password

Message-waiting indicator test example:

MWITEST|mwi test|300|*;*;*;*;*|10.76.91.155|10.76.91.148|00059A3B7B00|10.76.91.148 
|00059A3B7B01|71418001|13579
 
 

Table 21-7 Import File Format for Message-Waiting Indicator Test 

Column Number
Description

1

Type of test—MWITEST.

2

Test name.

3

Polling interval.

4

Schedule.

5

Cisco Unity system.

6

Caller Cisco Unified Communications Manager.

7

Caller MAC address. See Application Configuration for Synthetic Tests, for information on MAC details.

8

Recipient Cisco Unified Communications Manager.

9

Recipient MAC address. See Application Configuration for Synthetic Tests, for information on MAC details.

10

Recipient extension number.

11

Recipient voicemail password.

12

Customer name.


Emergency Call Test

Emergency Call test seed file format: EMERGENCYCALLTEST|TestName|PollInterval|Schedule|CERAddress|SrcCCM|SrcMAC|PsapCCM|PsapMAC|EmergencyNumber|enableOsan|OsanCCM|OsanMAC

Emergency Call test example:

EMERGENCYCALLTEST|emergency call test|600|*;*;*;*;*|10.76.35.211|10.76.93.75|00059A3B7789 
|10.76.93.75|00059A3B7790|911|TRUE|10.76.38.111|00059A3B7791
 
 

Table 21-8 Import File Format for Emergency Call Test 

Column Number
Description

1

Type of test—CCCTEST.

2

Test name.

3

Polling interval.

4

Schedule.

5

Cisco Emergency Responder system.

6

Caller Cisco Unified Communications Manager.

7

Caller MAC address. See Application Configuration for Synthetic Tests, for information on MAC details.

8

Public Safety Answering Point (PSAP) Cisco Unified Communications Manager.

9

PSAP MAC address. See Application Configuration for Synthetic Tests, for information on MAC details.

10

Emergency number.

11

Enable On Site Alert Number (OSAN). Enter true or false.

12

OSAN Cisco Unified Communications Manager.

13

OSAN MAC address. See Application Configuration for Synthetic Tests, for information on MAC details.

14

Customer name.


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 21-9 contains information you should be aware of while creating synthetic tests.

Table 21-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.

Measures packet loss, round-trip latency, and delay variance (or jitter) in IP networks by generating synthetic UDP traffic.

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 21-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.

Table 21-10 IP SLA Mapping for Node-to-Node Tests 

Test
Required Versions
IP SLA
Cisco IOS

Ping Echo

2.1.0 and higher

12.0(5)T, 12.1(1), and higher

Ping Path Echo

UDP Echo

UDP Jitter for VoIP

Without ICPIF/MOS values.

UDP Jitter for VoIP

With ICPIF/MOS values.

2.2.0 and higher

12.3(4)T and higher

Gatekeeper Registration Delay

12.3(14)T and higher

Real-Time Transport Protocol

2.20 and higher

Voice port of type - ds0-group.

DSP of type either C5510 or C549.

IOS version greater than or equal to 12.4(19.12)T


Creating a Node-to-Node Test

To create a node-to-node test:


Step 1 Choose Administration > System Setup > Diagnostic Tests > Node-to-Node Tests.

Step 2 Click Create.

Step 3 From the Test Type drop-down menu, select one of the following:

UDP Jitter for VoIP (see Table 21-11 for details on the parameters)

Ping Echo (see Table 21-12 for details on the parameters)

Ping Path Echo (see Table 21-13 for details on the parameters)

UDP Echo (see Table 21-14 for details on the parameters)

Gatekeeper Registration Delay

Real-time Transport Protocol (see Table 21-15 for details on the parameters)

Step 4 In the Source pane, do the following:

Select a source device using the device selector.

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.

Step 6 Enter the required information in the Parameters pane.

Step 7 Enter the required information in the Threshold pane.

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


Note The test name that you enter in the Run pane, cannot contain tabs, question marks, quotation marks, asterisks, semicolons, commas, colons, forward slashes, straight slashes, or backslashes.


Step 9 Click OK.


Table 21-11 UDP Jitter for VoIP Test Parameters

Parameter
Default Value
Available Values
Description

Codec Type

           —

G.711ulaw

G.711alaw

G.729

Used to determine the packet interval and the request payload.

Call Duration

8

1 - 59 seconds

Time of the call.

Voice Quality Expectation

Land line

Land line

Wireless campus

Wireless on the move

Multi-hop

Corresponds to the Access Advantage factor of Mean Opinion Scores (MOS) and Calculated Planning Impairment Factor (ICPIF).

IP QoS

IP Precedence

IP Precedence

DSCP

Defines the quality of service policies for the IP SLA packets.

5

IP Precedence—0 (none) through 7 (high)

DSCP—0 (none) through 8 (CS1), 9, and 10 (AF11)

This is converted to Type of Service (TOS) and set on the device.


Table 21-12 Ping Echo Test Parameters

Parameter
Default Value
Available Values
Description

Request Payload

32 bytes

28 to 16384 bytes

A default ICMP Ping packet has 32 bytes. Allows for variably sized operations.

IP QoS

IP Precedence

IP Precedence

DSCP

Defines the quality of service policies for the IP SLA packets.

0 (none)

IP Precedence—0 (none) through 7 (high)

DSCP—0 (none) through 8 (CS1), 9, and 10 (AF11)

This is converted to TOS and set on the device.


Table 21-13 Ping Path Echo Test Parameters

Parameter
Default Value
Available Values
Description

Request Payload

32 bytes

28 to 16384 bytes

A default ICMP Ping packet has 32 bytes. Allows for variably sized operations.

IP QoS

IP Precedence

IP Precedence

DSCP

Defines the quality of service policies for the IP SLA packets.

0 (none)

IP Precedence—0 (none) through 7 (high)

DSCP—0 (none) through 8 (CS1), 9, and 10 (AF11)

This is converted to TOS and set on the device.


Table 21-14 UDP Echo Test Parameters 

Parameter
Default Value
Available Values
Description

Request Payload

16 bytes

4 to 1500 bytes

Allows for variably sized operations.

IP QoS

IP Precedence

IP Precedence

DSCP

Defines the quality of service policies for the IP SLA packets.

0 (none)

IP Precedence—0 (none) through 7 (high)

DSCP—0 (none) through 8 (CS1), 9, and 10 (AF11)

This is converted to TOS and set on the device.


Table 21-15 Real-time Transport ProtocolTest Parameters 

Field
Description
General Parameters

General information about a test.

Codec Type

Used to determine the packet interval and the request payload.

Call Duration

Test duration. Default is 20 seconds.

Voice Quality Expectation

Corresponds to the Access Advantage factor of Mean Opinion Scores (MOS) and Calculated Planning Impairment Factor (CPIF).

Threshold Parameters

Threshold settings for the Real-Time Transport Protocol test.

Interarrival Jitter

Threshold Setting. The Destination to Source Inter-Arrival Jitter (Milliseconds) metric is supported.

Packet Loss

Threshold Setting. The Destination to Source Packet Loss (Number) metric is supported.

R Factor

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-Node Tests

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.

To configure the Node-to-Node test for NAT-enabled devices, ensure the import file contains the private/local IP address for the target router instead of public/global IP address.


Step 1 Choose Administration > System Setup > Diagnostic Tests > Node-to-Node Tests.

Step 2 Click Import.

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:

Cisco Systems Node-to-Node test import, version=3.0;type=CSV;source=manual
 
 

All values must be separated by commas.

Start and end dates must be formatted as mm/dd/yyyy; for example, 12/01/2004.

Start and end times must be formatted on a 24-hour clock as hh:mm; for example, 23:30.

Entering the source-ip-address is optional. This address is the same as the alternate test address.

Fill in optional fields with double quotation marks; for example, "".

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>
 
 
LSRHop<number> is an optional field.

Import File Example

echo-import1,Ping-Echo,source-1,"",dest-1,1,DSCP,9,64,lsr-hop1|lsr-hop2,300,09:00,17:00,1
echo-import2,Ping-Echo,source-1,"",dest-1,1,IPPrecedence,4,64,lsr-hop1|lsr-hop2,"",09:00,1
7:00,0,mon|tue|wed|fri

Ping Path Echo Test Import File

Import File Format

<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>

Import File Example

ping-path-import2,Ping-Path-Echo,source-2,"",dest-2,3,DSCP,10,32,250,17:00,23:00,0,mon|tue
|wed|thu|fri
ping-path-import2,Ping-Path-Echo,source-2,"",dest-2,3,IPPrecedence,5,32,"",17:00,23:00,1
 
 

UDP Echo Test Import File

Import File Format

<testName>,UDP-Echo,<source>,<source-ip-address>,<Destination-Name>,<destination-type>,<sa
mple-interval>,<IPQosType>,<IPQosValue>,<destination-port>,<request-payload>,
<completionTimeThreshold or "">,<start-time>,<end-time>,<AllDaysOfWeek. 1 for all days 
otherwise 0>,<DaysOfWeek, if AllDaysOfWeek is 0>

Import File Example

udp-import1,UDP-Echo,source-1,"",udp-dest,IPSLA-Responder,1,IPPrecedence,4,2001, 
32,300,17:00,23:00,0,mon|tue|wed|thu|fri
udp-import2,UDP-Echo,source-1,"",udp-dest,IPSLA-Responder,1,DSCP,48,2001,32,"", 
17:00,23:00,1
 
 

The destination type can be either UDP-Server or IP SLA-Responder.

UDP Jitter for VoIP Test

Import File Format Without Codec (Node-to-Node Quality) Support:

<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>
 
 

Import File Example

jitter-import1,Data-Jitter,source-1,source-1,dest-with-IPSLA-Responder,3,DSCP,24,64,30,20,
2002,30,30,25,25,50,17:00,23:00,0,mon|tue|wed|thu|fri
 
 

The destination type can be either UDP-Server or IP SLA-Responder.

Import File Format With Codec (Node-to-Node Quality) Support, valid for Cisco IOS version 12.3(4)T or higher:

<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>

Import File Example

jitter-import2,Data-Jitter,source-1,source-1,dest-with-IPSLA-Responder,3,IPPrecedence,5,G.
711ulaw,LandLine,20,2002,30,30,25,25,50,"",17:00,23:00,1
 
 

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>
 
 
Import File Example
gkregdelay-import1,Voip-GKReg-Delay,source-gateway,3,50,17:00,23:00,0,mon|tue|wed|thu|fri
gkregdelay-import2,Voip-GKReg-Delay, source-gateway,5,"",17:00,23:00,1
 
 

The destination type can be either UDP-Server or IP SLA-Responder.

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 21-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.

Config Failed

Test was not configured correctly. Possible problems include incorrect device credentials or low device memory.


Node-to-Node Test Data

Prime Collaboration saves the data collected by tests to disk.

The following topics provide information you will need to use the data, keep the data safe, and prepare to run additional tests:

Storing Node-To-Node Test Data

Maintaining Node-To-Node Test Data

Copying Test Data to Another Server

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.

StudyInfo.log—Log includes test name, description, polling interval, devices, start date, end date, operation type, polling interval, and status.

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 21-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 21-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 21-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 "*".

38

Test name

Text

Name of the node-to-node test

Sjc-VGtest


Jitter MOS, ICPIF, and Processed Data record format stores MOS and ICPIF values and processed jitter statistics values.

Table 21-20 Jitter MOS, ICPIF, and Processed Data Record Format  

Field Number
Field ID
Content
Description
Value

1

Record ID

205

Mandatory: record type 205

205

2

Date

yyyymmdd

Calendar date

Example: 20070201

3

Time stamp

hhmmss

Wall clock time

Example: 230000

4

ICPIF

Number

Mandatory: Icpif Value

Example

5

Node-to-node quality

Number

Mandatory: MOS value

Example: 3.6

6

Source to
destination packet loss

Number

Mandatory: number of packets

Any positive integer1

7

Destination to source packet loss

Number

Mandatory: number of packets

Any positive integer1

8

Source to destination jitter

Number

Mandatory: milliseconds

Greater than or equal to 0 and less than or equal to 100

9

Destination to source jitter

Number

Mandatory: milliseconds

Greater than or equal to 0 and less than or equal to 100

10

Average latency

Number

Mandatory: milliseconds

Greater than or equal to 0 and less than or equal to 100

11

None

Null indicator

Not used

*

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

38

Test name

Text

Name of the node-to-node test

Sjc-VGtest

1 Positive integers must be 32 bit.


Creating a Batch Test

Batch tests can be run once a day to verify the health of the voice network.

You can create batch tests by importing an XML file. Each individual batch test consists of multiple synthetic tests and phone tests.

To create a batch test:

Before You Begin

Verify that your seed file is formatted correctly. See Formatting Batch Test Import Files for details on import file format.

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


Step 1 Choose Administration > System Setup > Diagnostic Tests > Batch Tests.

Step 2 Click Create.

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:

TestSchedule—Can have multiple schedule entries.

Each ScheduleEntry—Must have the following five fields:

Month—Not supported.

DayOfMonth—Not supported.

DayOfWeek—Must be 0 through 6 or asterisk to indicate all days.

Hour—Must be between 0 and 23.

Minute—Must be between 0 and 59.

CallAgent—Can be a Cisco Unified Communications Manager or a Cisco Unified Communications Manager Express.

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.

Editing batch tests

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

Verifying the status of a test

You can verify whether a test ran and completed correctly. You can also troubleshoot the test if necessary.

To verify the status of a test, choose Administration > System Setup > Diagnostic Tests > Batch Tests.

The Batch Tests page appears. All current batch tests appear on the page. The last column in the table shows the status of each test.

Running—The test is active and collecting data.

Suspended—The 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.

Suspending/resuming a batch test

When you suspend a batch test it no longer runs at its scheduled time. The test is not removed from the system. If you want to remove the test, it must be deleted.

To suspend and resume a batch test, choose Administration > System Setup > Diagnostic Tests > Batch Tests.

The Batch Tests page appears.

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.


Table 21-21 describes the different types of phone tests.

Table 21-21 Phone Test Descriptions—Batch and On-Demand Tests 

Test
Description

Call Hold

Takes control of two phones and performs the following:

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

2. Has phone B put the call on hold.

3. Disconnects the call.

Call Forward

Takes control of three phones and performs the following:

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

2. Forwards the call to phone C from phone B.

3. Verifies that the call is received by phone C.

4. Disconnects the call.

Call Park

Takes control of three phones and performs the following:

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

2. Has phone B park the call.

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 21-22 describes the fields, which you can select while creating the on-demand phone test.

Table 21-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 21-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.

1 If 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.