The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco Prime Collaboration enables you to run multiple diagnostics tests to identify issues related to Unified Communications phone network.
If you have deployed Cisco Prime Collaboration 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:
A phone is considered unreachable after there is no response to either an IP SLA-based ping, or a Cisco Prime Collaboration ping, and the phone status is unregistered in the phone status process. Cisco Prime Collaboration generates the PhoneReachabilityTestFailed event.
When a router is rebooted, the phone status tests are lost. However, Cisco Prime Collaboration reconfigures the test when the router becomes available. While the router is down, the Cisco Prime Collaboration ping continues to run, if you have enabled Cisco 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 Cisco Prime Collaboration; update the seed file and add the test again.
Note | Before uninstalling Cisco 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. |
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 | Please refer respective IOS device configuration guides to view the exact commands. |
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:
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 device inventory. However, when Cisco 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 Cisco Prime Collaboration.
You can create phone status test by importing a seed file with a list of extensions to include in the test.
Verify that your seed file is formatted correctly. See Format Synthetic Test Import Files for details on the seed file format.
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.
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:
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.
For Cisco Prime Collaboration Release 11.1 and earlier |
|
For Cisco Prime Collaboration Release 11.1 and earlier |
|
For Cisco Prime Collaboration Release 11.1 and earlier |
|
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 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 can monitor the information returned from the synthetic tests and generate events based on the results. If a synthetic test fails, Cisco Prime Collaboration generates a critical event. Such events are displayed in Event Browser.
Cisco Prime Collaboration supports synthetic testing for the following applications:
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.
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.
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.
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.
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 Worksheet for list of worksheets that can help you in configuring applications and determining the number of phones for synthetic tests.
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:
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. |
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. |
You can configure only one TFTP download test for each Cisco Unified Communications Manager.
To create a TFTP 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:
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. |
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
.
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.
|
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.
|
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. |
You can import multiple synthetic tests at one time by using a comma-separated values (CSV) file.
Verify that your seed file is formatted correctly. For details, see Format Synthetic Test Import Files.
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. |
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
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:
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 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 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 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 |
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 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 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 |
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 server. If needed, you can use this file to import your configured synthetic tests back into Cisco Prime Collaboration, or to import the tests into another Cisco Prime Collaboration 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, 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 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. |
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 processes are started. However, during this time, you can still create, edit, or delete tests. |
Starting Cisco Prime Collaboration processes places a high load on the system. To prevent synthetic tests from failing during this time, Cisco Prime Collaboration 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 or other factors that cause Cisco Prime Collaboration 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 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 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.
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 processes places a high load on the system. To prevent synthetic tests from failing during this time, Cisco 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 |
|
||
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, 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 | Please refer respective IOS device configuration guides to view the exact commands. |
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 |
|
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. |
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 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. |
You can import up to 64 tests, the maximum that Cisco Prime Collaboration can support, by importing a seed file.
Step 1 | Choose
.
For Cisco Prime Collaboration Release 11.5 and later Choose . |
Step 2 | Click Import. |
Step 3 | Click
OK.
Cisco Prime Collaboration performs the following actions:
|
You can import up to 64 tests, the maximum that Cisco Prime Collaboration can support at one time.
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.
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
Import File Format
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
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.
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 validates the IP SLA Responder.
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.
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, |
IP SLA Voice Test Result
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. |
Cisco 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.
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.
Verify that there is sufficient disk space to store test data: Check disk space before a test is scheduled to run. Cisco Prime Collaboration appends data to a test’s log files. Cisco 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. Cisco 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. Cisco 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, Cisco 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.
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.
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 |
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.
Verify that your seed file is formatted correctly. See Format Batch Test Import Files for details on import file format.
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.
CallAgent—Can be a Cisco Unified Communications Manager or a Cisco Unified Communications Manager Express.
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.
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 saves the data collected by the batch tests on the Cisco Prime Collaboration 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. |
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 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 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 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.
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. |
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 JTAPI 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. |
The Audio Phone Features Test portlet displays the phone tests summary for all the Cisco Unified Communications Manager nodes.
It provides the following details:
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 |
|
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
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
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
To update the JTAPI.JAR files in Cisco Prime Collaboration Assurance
Step 1 | Log in to Cisco Unified Communications Manager Administration and select . | ||
Step 2 | Click Find to list the available plugins. | ||
Step 3 | From the list, select Download Cisco JTAPI 32-bit Client for Windows and save the file on your local system. | ||
Step 4 | Click the executable file to install the Cisco JTAPI client on your computer. | ||
Step 5 | In the Cisco Prime
Collaboration Assurance server, go to
/opt/emms/cuom/objects/bt/lib, and look for the directories
listed for each Unified CM version installed.
| ||
Step 6 | Click the directory for the Unified CM version that you are currently using. For example, go to directory 10.0 if your current version of CUCM is 10.0.x. Replace the .JAR files (jtapi.jar,updater.jar,jtracing.jar) in the directory with the .JAR files from the newly installed Cisco JTAPI client on your computer. By default, the .JAR files are in C:\Windows\java\lib on your computer if the default directory was selected during the Cisco JTAPI client installation. |
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, this column displays N/A.
Note | Endpoint Name field in Endpoint Diagnostics page is not supported for CME phones. |