Diagnostics for Voice Endpoints
Cisco Prime Collaboration Assurance enables you to run multiple diagnostics tests to identify issues related to Unified Communications phone network.
If you have deployed Cisco Prime Collaboration Assurance in MSP mode, you can select the customers for which you want to see the test results. Use the global customer selection list on the top right of the user interface to select the customer(s) and then perform the test. The endpoints available to you to perform the tests will depend on the customers you have selected. In the test results, you can see the customer to which the device belongs to. In case you select or deselect customers from the global customer selection list after creating, importing or scheduling, or modifying any fields for the tests, the resultant changes will be visible when the page refreshes.
You can run the following diagnostics tests for voice endpoints:
Phone Status Test
-
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 Cisco Prime Collaboration Assurance to the IP phones.
A phone is considered unreachable after there is no response to either an IP SLA-based ping, or a Cisco Prime Collaboration Assurance ping, and the phone status is unregistered in the phone status process. Cisco Prime Collaboration Assurance generates the PhoneReachabilityTestFailed event.
When a router is rebooted, the phone status tests are lost. However, Cisco Prime Collaboration Assurance reconfigures the test when the router becomes available. While the router is down, the Cisco Prime Collaboration Assurance ping continues to run, if you have enabled Cisco Prime Collaboration Assurance 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 Cisco Prime Collaboration Assurance; update the seed file and add the test again.
Note |
Before uninstalling Cisco Prime Collaboration Assurance, 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. |
snmp-server view .1.3.6.1.4.1.9.9.42 ciscoMgmt included
snmp-server group v3group1 v3 priv write .1.3.6.1.4.1.9.9.42
snmp-server user user1 v3group1 v3 auth sha Cisco123 priv aes 128 Cisco123
Note |
For more information, see respective IOS device configuration guides to view the exact commands. |
Create 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 Cisco Prime Collaboration Assurance device inventory. However, when Cisco Prime Collaboration Assurance 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 Cisco Prime Collaboration Assurance.
Procedure
Step 1 |
Choose .For Cisco Prime Collaboration Release 11.5 and later Choose . |
Step 2 |
Click Create. |
Step 3 |
In the Source pane, use the device selector to select a source device, or enter the device name (or IP address) in the Name field. |
Step 4 |
Click Add From Phone Report. |
Step 5 |
In the Endpoint Diagnostic report page, check the check box next to the phones for which you want to add the test, and click Add Phones. |
Step 6 |
In the Run area of the Create Phone Status Test page, do the following:
|
Step 7 |
Click Save. You can edit, view, and delete the phone tests from the Phone Status Test page. |
Import 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. See Format Synthetic Test Import Files for details on the seed file format.
To create a phone status test using a seed file:
Procedure
Step 1 |
Choose .For Cisco Prime Collaboration Release 11.5 and later Choose . |
Step 2 |
Click Import. Click Browse to add the seed file. |
Step 3 |
In the Run area, do the following:
|
Step 4 |
Click OK. |
Format 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.
-
Shared lines—Enter one or both phones; Cisco Prime Collaboration Assurance can run one test for each phone on a shared line.
-
Multiple extensions—Even if you enter multiple extensions for a phone, Cisco Prime Collaboration Assurance 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.
The following table shows the seed file format for testing the phone status.
Column Number |
Description |
---|---|
1 |
Phone extension. |
2 |
Phone MAC address. |
3 |
Phone IP address. |
4 |
For Cisco Prime Collaboration Release 11.1 and earlier IP SLA-enabled device (router, switch, or voice router). |
5 |
For Cisco Prime Collaboration Release 11.1 and earlier Read community string for the IP SLA-enabled device. |
6 |
For Cisco Prime Collaboration Release 11.1 and earlier 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) |
Examples
For Cisco Prime Collaboration Release 11.1 and earlier
[Extension]:[MAC Address]:[IPAddress]:[IPSLA Router]:[Read Community]:[Write community]
4000:200000000001:172.20.121.1:10.76.34.194:private:private
The following example shows a sample eight-column import file.
Example 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 test 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.
Cisco Prime Collaboration Assurance monitor the information returned from the synthetic tests and generate events based on the results. If a synthetic test fails, Cisco Prime Collaboration Assurance generates a critical event. Such events are displayed in Event Browser.
Cisco Prime Collaboration Assurance supports synthetic testing for the following applications:
-
Cisco Unified CM and Cisco Unified CM Express
-
Cisco TFTP Server
-
Cisco HTTP 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. |
The following table lists the synthetic tests and the results that each test must produce to pass.
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. |
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. |
For Cisco Prime Collaboration Release 11.6 and later HTTP Download Test |
Performs an HTTP get-file operation on the HTTP server. |
Successful download of a configuration file from the HTTP server. |
Emergency Call Test |
Initiates a call to the emergency number to test the dynamic routing of emergency calls. |
|
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. |
Prerequisites 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.
Note
You may use the following special characters in the extension: +, @, (.), (-), ?, \, ], [, (-), !, X, ^, *, and #.
-
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.
For Cisco Prime Collaboration 12.1 SP4 and later
Only Cisco 7965 IP Phones are simulated as synthetic endpoints in synthetic test.
Note
-
If auto registration is not enabled, ensure to manually add 7965 Phones with the same Synthetic MAC address and extension for the uninterrupted UC application synthetic tests.
-
If user has not deleted the 7960 Synthetic Phones, UC-Application Synthetic test will fail.
-
-
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.
-
For Conference Diagnostics and Audio Phone Feature Synthetic Tests to work, ensure that CUCM is as per the listed version(s) before applying Cisco Prime Collaboration Assurance Service Pack 1 bundle. For more information, see Supported Devices for Cisco Prime Collaboration Assurance for 12.1 SP1.
See Synthetic Test Worksheet for list of worksheets that can help you in configuring applications and determining the number of phones for synthetic tests.
Create 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 on Cisco Emergency Responder 1.x and later. |
To create an emergency call synthetic test:
Procedure
Step 1 |
Choose .For Cisco Prime Collaboration Release 11.5 and later Choose . |
||
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:
|
||
Step 5 |
In the Caller pane, do the following:
|
||
Step 6 |
In the PSAP pane, do the following:
|
||
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:
|
||
Step 8 |
In the Run pane, name the test and configure when the test should run.
|
||
Step 9 |
Click Create. |
Create a Message-Waiting Indicator Synthetic Test
The following are the requirements for the target phones to run this test.
-
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.
Note |
For Cisco Prime Collaboration Release 11.1 and earlier 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:
Procedure
Step 1 |
Choose .For Cisco Prime Collaboration Release 11.5 and later Choose . |
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. |
Create 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:
Procedure
Step 1 |
Choose .For Cisco Prime Collaboration Release 11.5 and later Choose . |
||
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, name the test and schedule when to run the test.
|
||
Step 6 |
Click Create. |
Create an HTTP Download Synthetic Test
For Cisco Prime Collaboration Release 11.6 and later
You can configure only one HTTP download test for each Cisco Unified Communications Manager.
To create an HTTP download synthetic test:
Procedure
Step 1 |
Choose . |
||
Step 2 |
Click Create. |
||
Step 3 |
From the Test Type drop-down list, select HTTP 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, name the test and schedule when to run the test.
Enter the file name. |
||
Step 6 |
Click Create. |
Create 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:
Procedure
Step 1 |
Choose .For Cisco Prime Collaboration Release 11.5 and later Choose . |
||
Step 2 |
Click Create. |
||
Step 3 |
From the Test Type drop-down menu, select End-to-End Call Test. |
||
Step 4 |
In the Caller pane, do the following:(Depending on the type of phone you select, some selections might become unavailable.) |
||
Step 5 |
In the Recipient pane, do the following: |
||
Step 6 |
In the Parameters pane, do the following:
|
||
Step 7 |
In the Run pane, name the test and schedule when the test should run.
|
||
Step 8 |
Click Create.
|
Create Dial-Tone Synthetic Tests
To create a dial-tone synthetic test:
Procedure
Step 1 |
Choose .For Cisco Prime Collaboration Release 11.5 and later Choose . |
||
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 Prerequisites 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 CM. If the threshold is exceeded, a warning event is generated. |
||
Step 6 |
In the Run pane, name the test and schedule when to run the test.
|
||
Step 7 |
Click Create.
|
Create a Phone Registration Test
To create a phone registration test:
Procedure
Step 1 |
Choose .For Cisco Prime Collaboration Release 11.5 and later Choose . |
||
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 Configure Applications for Synthetic Tests for MAC address limitations. |
||
Step 6 |
Select a protocol and parameter type.
|
||
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 CM. If the threshold is exceeded, a warning event is generated. |
||
Step 8 |
In the Run pane, name the test and schedule when to run the test.
|
||
Step 9 |
Click Create. |
Import 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 Format Synthetic Test Import Files.
Procedure
Step 1 |
Choose .For Cisco Prime Collaboration Release 11.5 and later Choose . |
Step 2 |
Click Import. |
Step 3 |
In the Import Synthetic Test page, browse to the seed file, 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. |
Format Synthetic Test Import Files
-
If you create the import file manually, the import file should have plain text content (Comma, AND, OR, Pipe separated) without header.
-
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)
-
Day of week—0-6 (0 = sunday)
-
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 Tests
Phone Registration Test Seed File Format
REGISTRATION|TestName|PollInterval|Schedule|CCMAddress|MACAddress|SrcPhoneProtocol|
SIPURI_OR_EXTN
Phone Registration Test Example
REGISTRATION|reg test|60|*;*;*;*;*|ipif-skate.cisco.com|00059A3B7780|SCCP|4002
Column Number | Description |
---|---|
1 |
Type of test—REGISTRATION |
2 |
Test name |
3 |
Polling interval |
4 |
Schedule |
5 |
Cisco Unified CM to which the phone is connected |
6 |
Phone’s MAC address. See Prerequisites 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
Column Number | Description |
---|---|
1 |
Type of test—DIALTONE/OFFHOOK |
2 |
Test name |
3 |
Polling interval |
4 |
Schedule |
5 |
Cisco Unified CM to which the phone is connected |
6 |
Phone’s MAC address. See Prerequisites 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 Call Test Example
ENDTOENDTEST|endtoend test|60|*;*;*;*;*|ipif-skate.cisco.com|00059A3B7782|FALSE
|ipif-skate.cisco.com|00059A3B7783|4002|TRUE|FALSE|SCCP|4004|SCCP
Column Number | Description |
---|---|
1 |
Type of test—ENDTOENDTEST |
2 |
Test name |
3 |
Polling interval |
4 |
Schedule |
5 |
Caller Cisco Unified CM |
6 |
Caller MAC address. See Prerequisites 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 CM |
9 |
Recipient MAC address. See Prerequisites 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 test format: TFTP|TestName|PollInterval|Schedule|CCMAddress
TFTP Download Test Example
TFTP|tftp download|60|*;*;*;*;*|ipif-skate.cisco.com
Column Number | Description |
---|---|
1 |
Type of test—TFTP |
2 |
Test name |
3 |
Polling interval |
4 |
Schedule |
5 |
Cisco Unified CM |
6 |
Customer name |
HTTP Download Test
For Cisco Prime Collaboration Release 11.6 and later
HTTP Download Test Seed File Format
HTTP test format: HTTP|TestName|PollInterval|Schedule|CCMAddress|PhoneConfigurationFileName
HTTP Download Test Example
HTTP|HTTP Download Test|60|*;*;*;*;*|10.78.86.158|SEPDefault.cnf
Column Number | Description |
---|---|
1 |
Type of test—HTTP |
2 |
Test name |
3 |
Polling interval |
4 |
Schedule |
5 |
Cisco Unified CM |
6 |
Phone configuration file 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
Column Number | Description |
---|---|
1 |
Type of test—MWITEST |
2 |
Test name |
3 |
Polling interval |
4 |
Schedule |
5 |
Cisco Unity system |
6 |
Caller Cisco Unified CM |
7 |
Caller MAC address. See Prerequisites for Synthetic Tests, for information on MAC details. |
8 |
Recipient Cisco Unified CM |
9 |
Recipient MAC address. See Prerequisites 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
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 CM |
7 |
Caller MAC address. See Prerequisites for Synthetic Tests, for information on MAC details. |
8 |
Public Safety Answering Point (PSAP) Cisco Unified Communications Manager |
9 |
PSAP MAC address. See Prerequisites 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 CM |
13 |
OSAN MAC address |
14 |
Customer name |
Manage Synthetic Tests
The following table describes the tasks that you can perform from the Synthetic Tests page.
Tasks | Description |
---|---|
Export Synthetic tests |
You can export the synthetic tests that you have created to a file on your Cisco Prime Collaboration Assurance server. If needed, you can use this file to import your configured synthetic tests back into Cisco Prime Collaboration Assurance, or to import the tests into another Cisco Prime Collaboration Assurance system. |
Edit 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. While editing the Synthetic test, if you get an error message stating that the MAC address is already in use, then delete the Synthetic test and add the test back with the same MAC address. |
View 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. |
Start and stop 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. |
View Synthetic test results |
The results are displayed in a report format. As with any of the reports in Cisco Prime Collaboration Assurance, you can print the report or export it to a file.
|
Schedule 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 Cisco Prime Collaboration Assurance 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
The following table contains information you should be aware of while creating synthetic tests:
Summary |
Explanation |
---|---|
Synthetic tests do not run for 30 minutes after the Cisco Prime Collaboration Assurance processes are started. However, during this time, you can still create, edit, or delete tests. |
Starting Cisco Prime Collaboration Assurance processes places a high load on the system. To prevent synthetic tests from failing during this time, Cisco Prime Collaboration Assurance delays starting them. |
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 Cisco Prime Collaboration Assurance or other factors that cause Cisco Prime Collaboration Assurance to be unable to receive some events from applications. |
Cisco Unity message-waiting indicator synthetic tests may fail. |
If a Cisco Unity Connection 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. |
IP SLA Voice Tests
IP SLA Voice 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 Cisco Prime Collaboration Assurance graphing function to examine changes in network performance metrics. You can select, display, and chart network performance data in real time. To understand and deploy the IP SLA on your network devices, see the IP Service Level Agreements (IP SLAs) technology page on Cisco.com.
-
You must configure Cisco IOS IP SLAs Source and Responder in your network.
-
Verify whether the IPSLA responder feature is enabled on the device using Cisco Prime Collaboration Assurance Inventory.
-
Ensure that the read-write community string of SNMP credentials is enabled when you configure IP SLA voice tests.
IP SLA Voice tests can be configured to trigger events when certain thresholds are crossed.
You can create IP SLA Voice tests one at a time, or import a file to create more than one test at a time.
You can create the following IP SLA Voice tests:
Test Name |
Description |
||
---|---|---|---|
UDP Jitter for VoIP |
Starting Cisco Prime Collaboration Assurance processes places a high load on the system. To prevent synthetic tests from failing during this time, Cisco Prime Collaboration Assurance 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 |
|
||
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 destination gateway, 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.
|
Retention period for IP SLA Voice test result data is 30 days. If you want to retain IP SLA Voice 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 Cisco Prime Collaboration Assurance, be sure to delete all the IP SLA Voice tests from the application. If you do not delete these tests, they will continue to run on the router. |
snmp-server view .1.3.6.1.4.1.9.9.42 ciscoMgmt included
snmp-server group v3group1 v3 priv write .1.3.6.1.4.1.9.9.42
snmp-server user user1 v3group1 v3 auth sha Cisco123 priv aes 128 Cisco123
Note |
For more information, see respective IOS device configuration guides to view the exact commands. |
Required Cisco IOS and IP SLA Versions
IP SLA Voice tests rely upon Cisco IOS IP SLA technology. The following table lists the versions of IP SLA and Cisco IOS that are required to successfully configure and run each type of IP SLA Voice tests.
Test |
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 |
|
Create an IP SLA Voice Test
To create an IP SLA Voice test:
Procedure
Step 1 |
Choose .For Cisco Prime Collaboration Release 11.5 and later Choose . |
||
Step 2 |
Click Create. |
||
Step 3 |
From the Test Type drop-down menu, select one of the following:
|
||
Step 4 |
In the Source pane, do the following:
|
||
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, name the test and schedule when to run the test.
|
||
Step 9 |
Click Save. |
Example
Parameter |
Default Value |
Available Values |
Description |
---|---|---|---|
Codec Type |
— |
|
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 |
|
Corresponds to the Access Advantage factor of Mean Opinion Scores (MOS) and Calculated Planning Impairment Factor (ICPIF). |
IP QoS |
IP Precedence |
|
Defines the quality of service policies for the IP SLA packets. |
5 |
|
This is converted to Type of Service (TOS) and set on the device. |
Parameter |
Default Value |
Available Values |
Description |
---|---|---|---|
Source to Destination |
3 (Packet Loss) 40 msec (Jitter) |
Any positive integer1 |
Threshold setting for packet loss and jitter. |
Destination to Source |
3 (Packet Loss) 40 msec (Jitter) |
Threshold setting for packet loss and jitter. |
|
Average Latency |
300 msec |
Threshold setting for latency. |
|
Node-to-Node Quality |
Fair |
Excellent, Good, Fair, or Poor |
|
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 |
|
Defines the quality of service policies for the IP SLA packets. |
0 (none) |
|
This is converted to TOS and set on the device. |
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 |
|
Defines the quality of service policies for the IP SLA packets. |
0 (none) |
|
This is converted to TOS and set on the device. |
Parameter |
Default Value |
Available Values |
Description |
---|---|---|---|
Request Payload |
16 bytes |
4 to 1500 bytes |
Allows for variably sized operations. |
IP QoS |
IP Precedence |
|
Defines the quality of service policies for the IP SLA packets. |
0 (none) |
|
This is converted to TOS and set on the device. |
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. Cisco Prime Collaboration Assurance 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. |
Import Multiple IP SLA Voice Tests
You can import up to 64 tests, the maximum that Cisco Prime Collaboration Assurance 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.
-
To configure the IP SLA Voice 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.
Procedure
Step 1 |
Choose .For Cisco Prime Collaboration Release 11.5 and later Choose . |
Step 2 |
Click Import. |
Step 3 |
Click OK. Cisco Prime Collaboration Assurance performs the following actions:
|
Format IP SLA Voice Test Import Files
You can import up to 64 tests, the maximum that Cisco Prime Collaboration Assurance can support at one time.
-
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
-
If you create the import file manually, the import file should have plain text content (Comma, AND, OR, Pipe separated) without header.
-
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>,
<IPQosType><IPQosValue>,<request-payload>,<LSRHop1|LSRop2|LSRHop3|LSRHop4|LSRHop5|LSRHop6|LSRHop7|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,17:00,0,mon|tue|wed|fri
Ping Path Echo Test Import File
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 Format
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 (IP SLA Voice Quality) Support
Import File Example
The destination type can be either UDP-Server or IP SLA-Responder.
Import File Format with Codec (IP SLA Voice 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, Cisco Prime Collaboration Assurance validates the IP SLA Responder.
VoIP Gatekeeper Registration Delay Test (Scheduled Daily)
Import File Format without Codec (IP SLA Voice 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.
Manage IP SLA Voice Tests
The following table describes the tasks that you can perform from the IP SLA Voice Test page.
Tasks | Description |
---|---|
Edit IP SLA Voice 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. |
Delete IP SLA Voice 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 IP SLA Voice Test Trend graph is displayed. The graph selection option is not displayed for other IP SLA Voice tests. |
View 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. |
Export 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. When you export the test details from Internet Explorer browser, the Windows Security popup window may prompt for your credentials. You can cancel the Windows Security popup and click Save or Save as to download the report. To export test details,
|
The threshold settings that you set during test creation or during modification determine when a IP SLA Voice event is generated.
NodeToNodeTestFailed To determine why a IP SLA Voice test failed and how to clear it, see the IP SLA documentation located on Cisco.com. |
PacketLossSD_ThresholdExceeded |
RFactorDS_ThresholdExceeded |
RoundTripResponseTime _ThresholdExceeded |
PacketLossDS_ThresholdExceeded |
MosCQDS_ThresholdExceeded |
RingBackResponseTime _ThresholdExceeded |
IAJitterDS_ThresholdExceeded |
RTPPacketLossDS_ThresholdExceeded |
RegistrationResponseTime _ThresholdExceeded |
JitterDS_ThresholdExceeded |
|
AverageLatency _ThresholdExceeded |
Quality Dropped Below Threshold |
You can verify whether a test ran and completed correctly. You can also troubleshoot the test if necessary. To do this, select
.The IP SLA Voice Test page appears. All current IP SLA Voice tests appear in the page. The last column in the table shows the status of each test.
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. |
IP SLA Voice Test Data
Cisco Prime Collaboration Assurance 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.
Store IP SLA Voice Test Data
-
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 IP SLA Voice test is available in the file IPSLATestInfo.log.
Maintain IP SLA Voice Test Data
-
Verify that there is sufficient disk space to store test data: Check disk space before a test is scheduled to run. Cisco Prime Collaboration Assurance appends data to a test’s log files. Cisco Prime Collaboration Assurance 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. Cisco Prime Collaboration Assurance 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. Cisco Prime Collaboration Assurance 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, Cisco Prime Collaboration Assurance 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.
Copy 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
-
ICMP Echo
-
UDP Echo
-
Gatekeeper Registration Delay
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 |
|
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 |
* |
||
|
||||||
38 |
Test name |
Text |
Name of the IP SLA Voice 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.
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 |
|
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 |
* |
||
|
||||||
38 |
Test name |
Text |
Name of the IP SLA Voice 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.
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 |
|
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 |
* |
||
|
||||||
38 |
Test name |
Text |
Name of the IP SLA Voice test |
Sjc-VGtest |
Jitter MOS, ICPIF, and Processed Data record format stores MOS and ICPIF values and processed jitter statistics values.
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 |
|||
5 |
IP SLA Voice quality |
Number |
Mandatory: MOS value |
Example: 3.6 |
||
6 |
Source to destination packet loss |
Number |
Mandatory: number of packets |
Any positive integer. Positive integers must be 32 bit. |
||
7 |
Destination to source packet loss |
Number |
Mandatory: number of packets |
Any positive integer. Positive integers must be 32 bit. |
||
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 |
* |
||
|
||||||
38 |
Test name |
Text |
Name of the IP SLA Voice test |
Sjc-VGtest |
Create a Batch Test
Batch tests enable you to test the health and connectivity of a branch office. Batch tests consist of a set of synthetic tests that are run on voice applications (for example, Cisco Unified Communications Manager Express or Cisco Unity Express) that are deployed in a branch office and a set of phone tests that are run on real phones in the branch office. Batch tests can be configured to run once a day to verify the health of the voice network in the branch office.
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.
For Cisco Prime Collaboration Release 12.1 SP1 and later
-
Two different synthetic tests cannot use the same Secure JTAPI User and Instance ID.
-
JTAPI users configured for synthetic test cannot be the same as the one used to Manage CUCM.
To create a batch test:
Before you begin
-
Verify that your seed file is formatted correctly. See Format Batch Test Import Files for details on import file format.
Procedure
Step 1 |
Choose .For Cisco Prime Collaboration Release 11.5 and later Choose . |
Step 2 |
Click Create. |
Step 3 |
Browse to the seed file, 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. |
Format 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/emms/cuom/ImportFiles directory.
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.
-
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.
Manage Batch Tests
The following table describes the tasks that you can perform from the Batch Test page.
Tasks | Description |
---|---|
View 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. |
Edit batch tests |
To edit batch tests, choose . In the Batch Tests page, select the batch test that you want to change and click Edit. |
Verify 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 .
|
Suspend/resume 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 .
The scheduled time and day that a batch test is to run is configured in the import file (see Format Node-To-Node Test Import Files). But if you want to run a batch test on demand, you can use the Run Now button. |
View 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. Cisco Prime Collaboration Assurance saves the data collected by the batch tests on the Cisco Prime Collaboration Assurance server in the /opt/emms/cuom/data/bt folder.
To view the results of a batch test, choose . In the Batch Tests page, select the batch test that you want to see the results for, and click Results. |
Print batch test results |
In a batch test report, click the printer icon in the upper-right corner of the page. |
Export batch test results |
You can use the export functionality to save the test results on your client system.
|
Delete batch tests |
To delete a batch test, choose . 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 Cisco Prime Collaboration Assurance 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 Cisco Prime Collaboration Assurance 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.
-
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 Cisco Prime Collaboration Assurance 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 following table describes the different types of phone tests.
Test |
Description |
---|---|
Call Hold |
Takes control of two phones and performs the following:
|
Call Forward |
Takes control of three phones and performs the following:
|
Call Park |
Takes control of three phones and performs the following:
|
Call Conference |
Takes control of three phones and performs the following:
|
Call Transfer |
Takes control of three phones and performs the following:
|
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. |
Create 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 CM. Phone tests use the JTAPI credential. The JTAPI credential must be configured in Unified CM.
The JTAPI phone tests support E.164 (“+”) dialing and phones with extensions in this format.
To create a phone test, choose
.For Cisco Prime Collaboration Release 11.5 and later
Choose
.The following table describes the fields, which you can select while creating the on-demand phone test:
Item |
Description |
Cisco Unified Communications Manager |
Lists the Unified CM for the phones selected from the phone report. You can select a Unified CM from the left pane and click the >> button to add it to the Unified CM field. The previous Test Phones and Helper Phones selections are cleared; you need to specify them again. |
JTAPI Username and Password |
Enter the JTAPI username and password configured on Unified CM. |
Test Phones |
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). |
Helper Phones |
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). |
Phone Tests |
Select the phone test that you want to see the results for. See Phone Test Descriptions—Batch and On-Demand Tests. 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 CM 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 CM provided in the previous field. |
Audio Phone Features Test
The Audio Phone Features Test portlet displays the phone tests summary for all the Cisco Unified Communications Manager nodes.
It provides the following details:
-
Number of phones tested
-
List of tested features
-
Date and time test was last completed
-
Result of latest phone test
-
Customer Name (only in MSP mode)
-
JTAPI User (Application User) Requirements: Standard Role
Privileges/Resources for the Role
Standard AXL API Access
Allows access to the AXL database API
Standard CCM Admin Users
Login rights to Cisco Unified Communications Manager Administration.
Standard SERVICEABILITY Administration
A serviceability administrator can access the Plugin window in Cisco Unified Communications Manager Administration and download plugins from this window.
Standard CTI Enabled
Enables CTI application control
Standard CTI Allow Call Monitoring
Allows CTI applications or devices to monitor calls
Standard CTI Allow Control of Phones supporting Connected Xfer and conf
Allows control of all CTI devices that supports connected transfer and conferencing
Standard CTI Allow Control of all devices
Allows control of all CTI-controllable devices
Note
-
The "Standard CTI Allow Control of all devices" is an optional role to replace the other CTI Standard roles. This role is recommended only when a dedicated JTAPI test user is created.
-
All test phones must be listed as controlled in the Application User's listing, and the users must exist in all Unified CM nodes.
-
For Cisco Prime Collaboration Release 12.1 SP1 and later
-
Two different synthetic tests cannot use the same Secure JTAPI User and Instance ID.
-
JTAPI users configured for synthetic test cannot be the same as the one used to Manage CUCM.
-
-
-
Phone Requirements:
-
Standard CTI Enabled
-
All test users must be registered to the same subscriber (or Unified CM node)
-
The phone must be in a Managed state in Cisco Prime Collaboration Assurance
-
The phone must be listed as "AllFine" as the Management Status Reason in the Phone Report that is used to select the phones
-
-
Processor Requirements:
-
JTAPI credentials must be in use, and the test valid for each Unified CM node
-
CTI Manager must be running in the Test node
-
AXL Web Services must be running in the Test node
-
Cluster IDs must be unique and configured in each Unified CM node for each cluster
-
The processor must be in a Managed state in Cisco Prime Collaboration Assurance
-
-
Secure JTAPI Requirements
Note
For Cisco Prime Collaboration Release 12.1 SP1 and later
-
JTAPI users configured for synthetic test cannot be the same as the one used to Manage CUCM.
-
Two different synthetic tests cannot use the same Secure JTAPI User and Instance ID.
-
Field Name |
Description |
||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
JTAPI Used to retrieve the session status information from the Cisco Unified CM. |
A new set of JTAPI specific parameters are introduced to secure the JTAPI (TLS1.2) connection. Following are a set of JTAPI specific parameters.
|
||||||||||
4. TFTP Server IP Address - Specify the IP address of the TFTP Server
5. TFTP Server Port - The TFTP Server Port defaults to 69.
6. CAPF Server IP Address - Specify the IP address of the CAPF Server.
7. CAPF Server Port - The CAPF Server Port number defaults to 3804.
8. Instance ID for Publisher - This field specifies the application instance identifier configured in CAPF Settings section of Application or End User CAPF profile configuration page in the Cisco Unified Communication Manager cluster. 9. Secure Authentication String – Enter the Authentication String configured in CAPF Settings section of Application or End User CAPF profile configuration page in the respective Communication Manager Publisher.
|
Troubleshooting
Perform troubleshooting for the following Phone Feature Test scenarios in Cisco Prime Collaboration Assurance.
-
Issue
The Phone Feature Test fails and displays the following error message:
"Address XXXXXX is not in provider's domain"
Recommended Action
-
Ensure that the endpoints that are selected for the feature test are all assigned to the same JTAPI user
-
Ensure that the "Standard CTI Allow Control of all devices" role is selected for the JTAPI user.
-
-
Issue
The Phone Feature Test fails and displays the following error message:
" Unable to create provider -- Connection refused"
Recommended Action
-
Ensure that the JTAPI credentials of the user are configured in Unified CM
-
Ensure that the phones that are used in the feature test are assigned to the same JTAPI user
-
Ensure that the CTI Manager is active and running in the Unified CM node that is used for testing
-
Update the JTAPI Java Archive (JAR) files in Cisco Prime Collaboration Assurance, if the JTAPI implementation in Unified CM has been modified
-
CME Diagnostics
The CME Diagnostics (
) page displays information about Cisco Unified Communications Manager Express (Cisco Unified CME) devices and associated Cisco Unity Express devices.You can launch the device 360 view for Cisco Unified CME devices.
-
Number of ephones registered with each CME. You can click on the number to cross-launch to the Endpoint Diagnostics page.
-
Number of unregistered ephones. Click on the number to cross-launch to the Endpoint Diagnostics page.
-
Total number of active and acknowledged alarms on the CME. Click on the number to launch the Alarms tab, in the Alarms & Events page..
-
Registration status of CUE with CME. If the CUE is not integrated with the CME or if the CUE is not managed in Cisco Prime Collaboration Assurance, this column displays N/A.
-
Total number of active and acknowledged alarms on the CUE.
Note |
Endpoint Name field in Endpoint Diagnostics page is not supported for CME phones. |
Limitation
For Cisco Prime Collaboration Release 12.1 SP3 and later
-
Cisco Prime Collaboration Assurance uses multiple OIDs (like 1.3.6.1.4.1.9.9.439.1.1.47.1.4 for DN) to pull phone information from CME phones.
-
Cisco Prime Collaboration Assurance does not support SIP phone discovery from CME phones.
Monitoring IP Phones Using Cisco Unified CME Syslog Messages
-
Add the Cisco Prime Collaboration Assurance IP configuration in CME to successfully receive Cisco Unified Communications Manager Express syslog messages. CME #(config)# logging <PCA_IP>
-
Use the IP phone registration or deregistration events to send syslog message to the Cisco Prime Collaboration Assurance when the syslog is configured in CME.
-
Use this example to configure the IP phone registration:
Error Message:
has registered.%IPPHONE-6-REGISTER_NEW: ephone-3:SEP003094C38724 IP:1.4.170.6 Socket:1 DeviceType:Phone