Knowledge Scripts from several modules raise events for problems that Vivinet Diagnostics can diagnose.
Two Knowledge Scripts from this module raise events that Vivinet Diagnostics can diagnose.
The AvayaCM_CallQuality Knowledge Script monitors RTCP packets in the Avaya CM supplemental database for calls that recorded poor call quality statistics. The script raises an event when call quality metrics exceed or fall below a threshold.
The AvayaCM_PhoneQuality Knowledge Script collects real-time voice quality statistics for active calls on Avaya IP phones. This script raises an event if voice quality statistics exceed or fall below a threshold during the data collection interval.
Events from both scripts trigger Action_DiagnoseVoIPQuality to launch Vivinet Diagnostics, which generates a Diagnosis between the two phones in a call based on the following information from the scripts:
The phone numbers of the phones involved in the call
MOS threshold, as set in the Average MOS parameter, or R-Value, as set in the Average R-Value parameter. Vivinet Diagnostics does not diagnose R-value. Instead, when a Diagnosis with a R-Value threshold is triggered, Vivinet Diagnostics translates the threshold into an equivalent MOS value. MOS is computed only for calls that use one of the following codecs: G.711u, G.711a, or G.729.
Jitter, measured in milliseconds, as set in the Maximum interval jitter parameter
Latency, measured in milliseconds, as set in the Maximum interval latency parameter
Packet loss, measured as a percentage, as set in the Maximum interval packet loss parameter
Two Knowledge Scripts from this module raise events that Vivinet Diagnostics can diagnose.
The CiscoCallMgr_CallQuality Knowledge Script monitors the Cisco Unified CallManager Call Management Record (CMR) database for calls that recorded poor VoIP quality metrics. This script runs periodically, looks at all calls generated since the last time the script ran, and raises an event if a call’s quality falls into the “poor” category.
The event triggers Action_DiagnoseVoIPQuality to launch Vivinet Diagnostics, which generates a Diagnosis between the two phones in a call based on the following information from this script.
The phone numbers of the telephones involved in the call. At least one telephone must be an IP phone. The other can be an IP telephone or a traditional (POTS) telephone on the PSTN.
The time the problem occurred, based on the schedule of the CallQuality script
Delay, measured in milliseconds, as set in the Maximum acceptable latency parameter
Lost data, expressed as a percentage, as set in the Maximum acceptable percentage lost data parameter
The CiscoCallMgr_CallFailures Knowledge Script monitors the CDR and CMR databases, looking at the termination codes for all calls. This script runs periodically, looks at all calls terminated since the last time the script ran, and raises an event if the number of calls that terminated abnormally exceeds the threshold you set for the Maximum failed calls parameter.
The event triggers Action_DiagnoseVoIPQuality to launch Vivinet Diagnostics, which generates a Diagnosis between the two phones in a call based on the following information from this script:
The phone numbers of the telephones involved in the call. At least one telephone must be an IP phone. The other can be an IP telephone or a traditional (POTS) telephone on the PSTN.
The time the problem occurred, based on the schedule of the CallFailures script
Call quality threshold. Because no call quality threshold is configured in the CallFailures script, Vivinet Diagnostics uses its default threshold settings. For more information, see Section 3.5.5, Setting Thresholds.
One Knowledge Script from this module raises events that Vivinet Diagnostics can diagnose.
The NortelCS_Alarms Knowledge Script monitors the Nortel CS1000 proxy computer for Nortel CS1000 alarms. Nortel CS1000 components send alarms to the proxy computer using SNMP traps. When one of the following alarms is detected, the Alarms script raises an event that triggers Action_DiagnoseNortelIPT to invoke Vivinet Diagnostics.
|
Alarm |
What It Means |
|---|---|
|
QOS0022 |
Packet loss has reached the warning level |
|
QOS0024 |
Latency has reached the warning level |
|
QOS0026 |
Jitter has reached the warning level |
|
QOS0028 |
R-factor has reached the warning level |
|
QOS0030 |
Packet loss has reached the unacceptable level |
|
QOS0032 |
Latency has reached the warning level |
|
QOS0034 |
Jitter has reached the warning level |
Vivinet Diagnostics generates a Diagnosis between the two Nortel Phase 2 IP phones involved in the call for which an alarm was raised.
Two Knowledge Scripts from this module raise events that Vivinet Diagnostics can diagnose.
The NortelCS2x_CallQuality Knowledge Script monitors the QoS Collector Application records that the Core & Billing Manager pushes to the QoS file collector service, as well as the QoS syslog records sent by the CICM Element Manager to the QoS syslog collector service. This script raises an event for end-of-call quality problems related to MOS, R-Value, jitter, latency, and packet loss.
The NortelCS2x_PhoneQuality Knowledge Script monitors the mid-call QoS records for the Phase 2 IP phones on which you run the script and raises an event for call quality problems related to MOS, R-Value, jitter, latency, and packet loss. The QoS syslog collector service receives those records from the Call Server and pushes those records to the supplemental database.
The events for both scripts trigger Action_DiagnoseVoIPQuality to launch Vivinet Diagnostics, which generates a Diagnosis between the two phones in a call.
One Knowledge Script from this module raises events that Vivinet Diagnostics can diagnose.
The PhoneQuality_CiscoPhoneQuality Knowledge Script polls Web-enabled Cisco IP phones for call quality statistics on active calls. When an active call is detected, the script collects or calculates values for average and maximum jitter, percentage of packet loss, listening MOS, and listening R-Value.
If, while the script is polling an IP phone, a call quality metric falls below or exceeds the threshold you set, the script raises an event while the call is active. The event triggers Action_DiagnoseVoIPQuality to launch Vivinet Diagnostics, which generates a Diagnosis between the two IP phones in the call based on the following information from the script:
The phone numbers of the Web-enabled IP telephones involved in the call
The time the problem occurred, based on the schedule of the script CiscoPhoneQuality script
One Knowledge Script from this module raises events that Vivinet Diagnostics can diagnose.
The VoIPQuality_CallPerf Knowledge Scripts monitor VoIP quality by periodically driving synthetic VoIP traffic between two NetIQ Performance Endpoints. These scripts raise an event when VoIP Quality metrics exceed the thresholds you set and if a VoIP test fails to run.
The event triggers Action_DiagnoseVoIPQuality to launch Vivinet Diagnostics, which generates a Diagnosis between two endpoints in a test based on the following information from a CallPerf script:
The talker and caller endpoints, respectively, used in the VoIP test
The type of codec applied to the test. The Knowledge Script name indicates the codec in use: G.711a, G.711u, G.723-1ACELP, G.723.1-MPMLQ, G.726, G.729, or G.729A.
Whether packet loss concealment was enabled
Whether silence suppression was enabled
The amount of delay set to occur between voice datagrams
Whether Service Quality (DiffServ) was enabled, and which type
The size of the jitter buffer
Whether additional fixed delay was set, and how much
The destination port number
The voice activity rate, which, although you specify in the Knowledge Script, cannot be set in Vivinet Diagnostics. Vivinet Diagnostics uses a default voice activity rate of 50% when generating a Diagnosis.
MOS threshold, as set in the Minimum MOS parameter, or R-Value, as set in the Minimum R-Value parameter. Vivinet Diagnostics does not diagnose R-value. Instead, when a Diagnosis with a R-Value threshold is triggered, Vivinet Diagnostics translates the threshold into an equivalent MOS value. MOS is computed only for calls that use one of the following codecs: G.711u, G.711a, or G.729.
Delay, measured in milliseconds, as set in the Maximum delay parameter
Lost data, measured as a percentage, as set in the Maximum lost data parameter
Loss due to jitter buffer, measured in percentage, set to the Maximum jitter buffer loss parameter