5.3.1 Burst Density

A variation of data loss, burst density is the longest sequence of data, beginning and ending with a loss, during which the number of consecutive received packets is less than the threshold. Bursty packet loss has a severe impact on VoIP call quality. Even if the average packet loss rate for a call is low (say one percent), the lost packets are likely to occur during short dense periods, resulting in short periods of degraded quality.

To calculate burst density between Nortel Target Devices, Vivinet Diagnostics uses data from the Nortel R-value trap, which was raised because a voice quality threshold was crossed, or the RTCP-XR Average Burst Density value. RTCP does not provide a value for burst density.

The burst density threshold is static in Vivinet Diagnostics. You cannot change it.

5.3.2 CPU Utilization

Any applications installed on the same computer might at any point be required to compete with each other for processing time — for the use of the chip or central processing unit (CPU). Codecs require a fair amount of CPU processing time because of the compression they perform, so CPU utilization can become an issue on any softphones you are running. And if you add RTP header compression as part of a Quality of Service scheme on your network, VoIP will require even more CPU at the routers, which perform this compression. Finally, call performance will not be excellent if VoIP servers do not have enough extra CPU cycles to accommodate call processing as quickly and efficiently as possible. Competition for CPU time can add to delay.

Therefore, always keep track of CPU utilization statistics on routers and on critical VoIP servers. By default, Vivinet Diagnosis flags an issue on your network if router or switch CPU utilization exceeds 80%. Set a new threshold for CPU utilization by clicking Thresholds on the Options menu and then clicking the Device/Link tab.

5.3.3 Delay

End-to-end delay, or latency, as measured between the Target Devices is a key factor in diagnosing a problem with VoIP call quality. Using test traffic, Vivinet Diagnostics takes a delay measurement for datagrams traveling between the devices in a single direction. The delay measured includes the several factors:

By default, Vivinet Diagnostics uses a threshold value of 350 ms to determine when delay on your network is considered an issue. Change the default threshold by clicking Thresholds on the Options menu. Most callers notice round-trip delays when they exceed 250 ms. ITU-T standard G.114 specifies 150 ms as the maximum one-way delay tolerable for high-quality VoIP, so consider these factors when configuring a delay threshold.

Delay is calculated between the Target Devices regardless of whether you selected a phone, an endpoint, or a generic device as the Device Type. Delay values have different sources depending on whether you are calculating delay between Cisco IP phones or Nortel devices.

5.3.4 Insufficient Bandwidth

The amount of WAN or LAN bandwidth your VoIP traffic needs depends on the type of codec you are using. The codecs with the highest theoretical maximum Mean Opinion Score (MOS) use the most bandwidth. For more information, see Section 4.2.2, Reviewing Codecs.

Vivinet Diagnostics checks each WAN or LAN interface between the two Target Devices you included in the problem definition and reports an issue if bandwidth falls below the threshold.

You can change the default threshold of 35 by clicking Thresholds on the Options menu. Keep in mind, the G.726, G.729, and G.723 codecs require substantially less than 50 kbps of bandwidth. However, other network traffic on these links may take up a large amount of the available bandwidth, particularly during the busiest hours of the day. Vivinet Diagnostics also takes network congestion into consideration when diagnosing a problem. For more information, see Section 5.3.8, Network Congestion.

5.3.5 Jitter Buffer Loss

As simulated calls run during a Diagnosis, the endpoints calculate jitter, a factor known to adversely affect call quality. Jitter, also called delay variation, indicates the differences in arrival times among all datagrams sent during a simulated VoIP call.

When a datagram is sent, the sender gives it a timestamp. When a datagram is received, the receiver adds another timestamp. These two timestamps are used to calculate the datagram’s transit time. If the transit times for datagrams within the same call are different, the call contains jitter. In a video application, jitter manifests itself as a flickering image, while in a telephone call, its effect may be similar to the effect of packet loss: some words may be missing or garbled.

VoIP equipment typically has a jitter buffer that holds datagrams, buffering them until a segment of the voice transmission can be reassembled to reduce inter-arrival time variability. For more information, see Section 4.2.5, Defining Jitter Buffer.

If Vivinet Diagnostics detects jitter on the network, it measures jitter buffer loss — the percentage of datagrams that overran or underran the jitter buffer emulated by the call script used in a Diagnosis. Jitter buffer overruns or underruns are equivalent to lost data, which is a source of call-quality impairment. For more information, see Section 5.3.6, Lost Data. The jitter buffer loss statistic is shown in the Results table as part of the MOS calculation during a Diagnosis.

The measurement/gathering method varies slightly by phone vendor. In a Cisco environment this statistic is measured only if you are using endpoints for the Diagnosis. In a Nortel environment, this statistic, called “average discard rate,” is gathered when an AppManager event triggers a Diagnosis.

To calculate jitter buffer loss between Nortel Target Devices, Vivinet Diagnostics uses the RTCP-XR Average Discard Rate value. RTCP does not provide a value for jitter buffer loss.

Vivinet Diagnostics uses a default threshold of 0.5000% to determine when jitter buffer datagram loss is considered an issue. You can determine what levels of jitter are acceptable on your network by configuring thresholds. For more information, see Section 3.5.5, Setting Thresholds.

5.3.6 Lost Data

In diagnosing a problem on your network, Vivinet Diagnostics weighs relevant statistics on lost datagrams, expressed as a percentage of all test data sent between the Target Devices. If the Target Devices are Performance Endpoints, these statistics are also used to calculate a MOS score for VoIP calls between these devices.

When a datagram is lost during a VoIP transmission, you can lose an entire syllable or word in a conversation. Obviously, packet loss can severely impair call quality. Vivinet Diagnostics therefore includes packet loss in calculating a MOS for each simulated VoIP call.

To measure packet loss using endpoints as the Target Devices, one endpoint computer in each pair of devices keeps track of how many bytes of data it sent. The sending endpoint reports the number of sent bytes to the receiving endpoint, and the receiver compares that value to the actual number of bytes received to determine whether data was lost.

You can get packet loss values without using endpoints as the Target Devices. The measurement/gathering method varies slightly according to your phone vendor. In a Cisco environment, Vivinet Diagnostics uses Cisco IOS IP SLA tests to find out how much data was lost between Cisco routers. In a Nortel environment, Vivinet Diagnostics uses the “Avg. Network Loss Rate” value from the R-value trap. Or, if a trap did not trigger the Diagnosis, Vivinet Diagnostics can use the “Pkt Loss” value from RTPStatShow.

Vivinet Diagnostics flags data loss as an issue only if it exceeds the configured threshold for packet loss. By default, this threshold is .500%, reflecting general industry standards for VoIP. Set a new threshold by clicking Thresholds on the Options menu.

For more information, see Section 3.5.5, Setting Thresholds.

5.3.7 Mean Opinion Score

As part of any Diagnosis involving Performance Endpoints, Vivinet Diagnostics sends simulated VoIP traffic between the Target Devices and measures its performance. Using the performance metrics collected from the test traffic, Vivinet Diagnostics then calculates an estimated Mean Opinion Score (MOS), which summarizes the quality of the test VoIP transmission.

NetIQ uses a modified version of the ITU G.107 standard E-Model equation to calculate a MOS estimate for a pair of endpoints. The E-Model, developed by the European Telecommunications Standards Institute, is an algorithm developed to evaluate the quality of a voice transmission by factoring in the “mouth-to-ear” characteristics of a speech path. These characteristics were in turn derived from studies of user satisfaction with varying levels of transmission clarity and stability.

The E-Model takes as input an R-value, which correlates directly with the MOS. The factors of network delay in a single direction, delay introduced by the codec’s packetization technique, lost data packets, and datagram loss due to jitter and jitter buffer size are measured between the endpoints and then used to calculate the R-value (and thus, the MOS).

A MOS of 5 is excellent. A MOS of 1 is unacceptably bad. The following table, taken from ITU G.107, summarizes the relation between the MOS and user satisfaction:

By default, Vivinet Diagnostics considers a MOS of less than 4.03 to be an issue. However, you can determine at what level a MOS is considered problematic in your diagnoses. Click Thresholds on the Options menu to change the MOS threshold.

5.3.8 Network Congestion

To find out how much of a particular network link’s capacity is being filled with network traffic, including VoIP and any other concurrently running applications, Vivinet Diagnostics uses SNMP to query router and switch network interfaces. Each interface supplies information about the number of bytes that have passed through it, as well as indicating its bandwidth.

Because VoIP traffic is extremely sensitive to delay, it is never a good idea for it to be traveling over WAN links that consistently experience more than 50% utilization. For LAN links, more than 25% utilization often inhibits VoIP call quality because most LANs are collision-prone, and collisions add plenty of delay while contributing to packet loss. For more information, see Section 5.3.6, Lost Data.

When checking bandwidth on a link, Vivinet Diagnostics reports the maximum bandwidth utilization in one direction. If 80% of the link is used in one direction and 50% of the link is used in the other direction, the bandwidth utilization will be reported as 80%.

5.3.9 R-value

Defined by ITU (International Telecommunication Union) recommendation G.107, the E-Model is a complex calculation, the output of which is a single score called an R-value that is derived from delays and equipment impairment factors. An R-value can be mapped to an estimated MOS. R-values range from 100 (excellent) to 0 (poor). As shown below, an estimated MOS can be directly calculated from an R-value:

Cisco IOS IP SLA does not generate R-value metrics. When diagnosing call quality between Nortel Target Devices, Vivinet Diagnostics uses the data from one of two places: the Nortel R-value trap or the R-value metric provided by RTCP-XR. RTCP does not provide an R-value.