7.11 Increasing Assessment Accuracy

A VoIP Quality assessment increases in accuracy if you run simulated traffic that closely resembles the actual VoIP traffic you will be running once your VoIP implementation is operational. And you can also increase assessment accuracy if you add background traffic when you design your assessment.

Installing VoIP equipment entails a series of choices that affect voice traffic and how the network must handle it. Therefore, before you select VoIP Quality assessment parameters, acquaint yourself with the following options and how they can affect VoIP network performance:

  • Seven different codec types, emulating different compression algorithms, data rates, and datagram sizes

  • Packet loss concealment for G.711 codecs

  • Voice datagram sizes

  • The ability to use silence suppression

  • A jitter buffer

  • Any additional, fixed delay values that apply

  • The typical amount of TCP/IP application, or “background,” traffic that will share the network with VoIP

  • Quality of Service

Once you understand these conditions and parameters, you will be better equipped to determine which ones your VoIP implementation will deploy. Or you can experiment with them to see if the VoIP Quality of the simulated traffic improves.

Consult the following topics for more information about these parameters.

7.11.1 Understanding Background Traffic

Find out how good VoIP calls will sound on the network during times of heavy or average network usage by adding background traffic to your VoIP Quality assessment. The Background Traffic Connector in the Design view lets you add a specific amount of TCP/IP traffic to emulate network utilization levels.

Background Traffic Connectors send TCP/IP packets between the endpoints in your network. You select a connector’s data rate to match an expected or projected level of network bandwidth utilization for that path. For example, if you want to assess the VoIP readiness of a T1 line (1.544 Mbps), you would probably select 128 kbps (Fractional T1/ISP) to simulate heavy network traffic, or 64 kbps (Fractional T1) to simulate lighter network utilization. You may want to select a data rate based on the results from the Utilization assessment.

You can also set a “custom” data rate for background traffic. For example, you can send a single packet of a specific size every few seconds. For more information, see Section 7.4.6, Setting a Custom Data Rate.

The extra network traffic generated by a Background Traffic Connector helps you test the effects of QoS, or it shows how VoIP quality is affected when small VoIP packets get behind larger TCP/IP packets in the network.

For information about adding background traffic to a VoIP Quality assessment, see Section 7.4.5, Creating a Background Traffic Connector.

For more information about the background traffic results you can view in Analysis Console, see Section 9.2.6, Background Traffic Tab.

7.11.2 Reviewing Codec Types

In a VoIP transmission, the codec samples the sound and determines the data rate. You can perform voice over IP assessments using seven codec types, represented by seven call scripts. For more information, see Section 7.10, Working with Call Scripts.

Codec

Description

G.711u

ITU standard for H.323-compliant codecs. Uses the u-law for companding, the most frequently used method in the USA. PLC is enabled.

G.711a

ITU standard for H.323-compliant codecs. Uses the A-law for companding, a popular standard in Europe. PLC is enabled.

G.726

A waveform coder that uses Adaptive Differential Pulse Code Modulation (ADPCM). ADPCM is a variation of pulse code modulation (PCM), which only sends the difference between two adjacent samples, producing a lower bit rate.

G.729

High-performing codec; offers compression with high quality. Optimized for voice over frame relay, teleconferencing, and other applications.

G.729A

Also known as G.729 Annex A. High-performing codec; offers compression with high quality. Same as G.729, but less complex to implement.

G.723.1-MPMLQ

Uses the multipulse maximum likelihood quantization (MPMLQ) compression algorithm.

G.723.1-ACELP

Uses the conjugate structure algebraic code excited linear predictive compression (ACELP) algorithm.

7.11.3 Reviewing Packet Loss Concealment

Packet loss concealment (PLC) is an option if you are using the G.711u or G.711a codecs. PLC describes a number of techniques for minimizing or masking the effects of data loss during a VoIP conversation. When PLC is enabled (the default setting), Vivinet Assessor assumes that the quality of your conversation would be improved, but this improvement is only factored into the MOS estimate calculation if any data is lost.

In the table below, “packetization delay” refers to the delay this codec introduces as it converts a signal from analog to digital; this delay is included in the MOS estimate, as is the jitter buffer delay, the delay introduced by the effects of buffering to reduce interarrival delay variations. For more information, see Section 8.5, Reviewing VoIP Quality Assessment Factors.

Codec

Default Data Rate

Default Datagram Size

Packetization Delay

Default Jitter Buffer Delay

Theoretical Maximum MOS

G.711u G.711a

64 kbps

20 ms

1.0 ms

2 datagrams (40 ms)

4.40

G.726

32kbps

20 ms

1.25 ms

2 datagrams (40 ms)

4.22

G.729 G.729A

8 kbps

20 ms

35.0 ms

2 datagrams (40 ms)

4.07

G.723.1-MPMLQ

6.3 kbps

30 ms

67.5 ms

3 datagrams (60 ms)

3.87

G.723.1-ACELP

5.3 kbps

30 ms

67.5 ms

3 datagrams (60 ms)

3.69

7.11.4 Setting Datagram Sizes

With each new call script you add, you can choose to Override delay between voice datagrams. This option is recommended only for advanced users, and it is not likely that you will need to set it.

However, the following is an explanation of what happens when you choose to override the delay associated with the codec you are using.

The delay between datagrams determines the datagram size to be used in the simulated VoIP calls. VoIP applications break voice data into chunks based on delay, or the amount of time between successive datagrams. Each call script uses a delay value appropriate to its codec: the faster codecs use 20 ms and the G.723.1 codecs use 30 ms. This means, for example, that every 20 milliseconds, the VoIP application adds a header to any voice data it has received and places the datagram on the wire. Smaller delay values mean that the header-to-payload ratio is larger; more, smaller datagrams are sent, which increases processing overhead. Greater delay values mean that fewer, larger datagrams are sent, and that delay is probably higher.

Some VoIP equipment refers to the delay between voice datagrams as the “speech packet length.” For example, at 64 kbps, a “20-millisecond speech packet” implies that the sending side creates a 160-byte datagram payload every 20 ms. A simple equation relates the codec speed, the delay between voice packets, and the datagram payload size.

Datagram payload size (in bytes) equals:

Codec speed (bits/sec) x packet delay (ms) / 8 (bits/byte) x 1000 (ms/sec)

In this case:

160 bytes = (64000 x 20)/8000

For a given data rate, increasing the delay increases the datagram size because datagrams are sent less frequently. A delay of 30 ms at a data rate of 64 kbps would mean sending 240-byte datagrams.

Unless you are an equipment manufacturer, you are much better off leaving the datagram sizes at their default values. These values were selected because they match those of the codec being emulated and allow for realistic simulation of VoIP datagram traffic.

Values for Override delay between voice datagrams must be between ten and 200 ms. Vivinet Assessor may adjust values slightly after you enter them so that no partial buffers are sent.

For more information, see Section 7.10.1, Adding a Call Script.

7.11.5 Understanding Silence Suppression

When you edit a call script for an assessment, you can enable silence suppression in the voice over IP call traffic Vivinet Assessor sends on the network. The codec performs silence suppression, also known as voice activity detection. By default, silence suppression is disabled in all call scripts.

When you enable silence suppression, no data is sent on the network during periods of call silence, that is, when no one is talking. Enabling it means that each simulated call contains less data. For all call scripts, the silence suppression option uses a default voice activity rate of 50%, which means that data is being sent during 50% of each simulated call’s duration. You can set a voice activity rate to include more or less data in calls using silence suppression.

For more information, see Section 7.10.1, Adding a Call Script.

7.11.6 Understanding Jitter Buffers

To minimize call disruptions from delay and jitter, VoIP phones and gateways typically have jitter buffers. A jitter buffer can be either frame-based or absolute: a frame-based jitter buffer will hold a given number of voice datagrams, while an absolute jitter buffer is based on time. For example, a frame-based jitter buffer might hold two datagrams, buffering them until a segment of the voice transmission can be reassembled to reduce inter-arrival time variability. An absolute jitter buffer, on the other hand, might be set to 43 ms, and, given a typical 20-ms speech frame, could hold two speech frames and allow for an extra three milliseconds of variability.

Jitter buffers may also be static or dynamic. Each buffer implementation has its strengths. But buffering adds delay while smoothing out variability; therefore, one goal of VoIP network tuning must be to minimize jitter buffer sizes while maintaining call quality.

By default, all the call scripts used in VoIP Quality assessments emulate a frame-based jitter buffer of two datagrams. You can configure buffers based either on time (in milliseconds) or on number of datagrams. Configure your own jitter buffers by clicking Call Scripts on the Options menu. The supported range of values is 10-1600 ms for an absolute jitter buffer, and 1-8 for a buffer configured in number of voice datagrams. For more information, see Section 7.10.1, Adding a Call Script.

NOTE:The Vivinet Assessor jitter buffer call script option does not smooth out jitter. Instead it provides a more accurate Mean Opinion Score (MOS) by better accounting for datagrams that would have been lost due to underrun or overrun of the jitter buffer. In addition, the delay incurred by using a jitter buffer is factored into the MOS. For more information about how Vivinet Assessor uses jitter buffer sizes to assess call quality, see Section 8.5.3, Jitter.

7.11.7 Reviewing Quality of Service

Using a prioritization or QoS scheme can make a significant difference in call quality, particularly if you are running VoIP on a crowded enterprise network. Vivinet Assessor ships with a default QoS definition that was designed to emulate the QoS used in typical VoIP implementations. The VoIPQoS definition specifies that each voice datagram

  • is assigned a priority that makes it unlikely to be queued or dropped

  • is flagged to receive the lowest possible delay

When you select VoIPQoS from the QoS name list in the Adding a Call Script dialog box, Vivinet Assessor sets the three IP Type of Service (TOS) precedence bits in the IP header, using the “CRITIC/ECP” setting (101 or value 5). These same bits are known as the Expedited Flow (EF) setting in the Differentiated Services (DiffServ) standard. More recent DiffServ implementations use all six DiffServ Code Point (DSCP) bits, so this definition has been supplemented by 13 new DiffServ settings you can select when configuring QoS definitions.

To run assessments using other types of QoS, click QoS Definitions on the Options menu. In the QoS List dialog box, definitions are listed according to type. Click Add to create a new definition. A menu lets you add an 802.1p Definition or a DiffServ Definition.

For more information, see the following topics:

If you have not tried QoS for your VoIP traffic, you can set up a few call groups that use QoS and a few that do not. Depending on your routers’ ability to process requests for QoS, you should see a difference in the groups’ Call Quality scores when you compare the results.

802.1p Definitions

IEEE 802.1p is an OSI Layer 2 standard for prioritizing and queuing network traffic at the data link/MAC sub-layer. It can also be defined as best-effort QoS at Layer 2. 802.1p traffic is classified and sent to the destination with no bandwidth reservation.

To run a VoIP Quality assessment using 802.1p, add a QoS definition as instructed below, and then add or copy a Call Script, using the new QoS definition. For more information, see Section 7.10, Working with Call Scripts.

To add an 802.1p QoS definition:

  1. Click the Assess VoIP Quality view tab.

  2. On the Options menu, click QoS Definitions.

  3. Click Add and then click 802.1p Definition.

  4. In the QoS name field, assign a name to your definition. You use this name to identify your settings when you apply QoS to a Call Script.

  5. In the Priority field, select the desired priority setting:

    • 000--(0) for lowest-priority traffic. Equivalent to no QoS.

    • 011--(3) for medium-priority traffic. Often used for call setup packets.

    • 101--(5) for high-priority traffic. Recommended for VoIP data packets.

The three-bit Prioritization field in the 802.1p tag establishes eight levels of priority, similar to the IP Precedence bits. A level-eight priority is the highest, and is thus reserved for router-update traffic. However, Vivinet Assessor only supports three priority levels, two of which are appropriate for VoIP traffic.

Network adapters and switches route traffic based on the priority level. The hardware itself-usually a NIC card or an IP phone-does the tagging. Many recently developed IP phones are marking voice packets with a priority of five (101).

NOTE:

  • Definitions to simulate 802.1p QoS can be used only in call scripts running to Windows 2000 and Windows XP endpoints

  • Some older switches support just two or three priority queues, so their implementation of 802.1p does not actually support all of the eight priority levels in the IEEE 802.1p specification. Such switches place 802.1p values of 0 through 3 in a low-priority queue, and priority levels 4 through 7 in a high-priority queue, using only two different priority levels.

DiffServ Definitions

The DiffServ standard for QoS defines an individual packet’s per-hop behavior (PHB), or the treatment it receives from routers. PHB depends on a packet’s likelihood of being dropped in congested conditions (its “drop precedence”) and the amount of forwarding resources—buffer space and bandwidth—that will be devoted to it.

DiffServ-enabled routers can subdivide networks into DiffServ (DS) domains, within which all IP traffic competes for a finite share of bandwidth determined by a committed information rate, or CIR. To ensure that traffic that exceeds the CIR is still delivered without compromising the performance of high-priority traffic, packets within a DS domain are placed into PHB groups, including Expedited Forwarding and Assured Forwarding. Of these two groups, Expedited Forwarding receives slightly lower drop precedence and slightly higher bandwidth allocation than Assured Forwarding.

These groups allow for very exact policy-based QoS: they can be further subdivided to determine which packets are least likely to be dropped and most likely to be forwarded quickly despite congestion. Assured Forwarding includes four classes, AF1-AF4. Within each class, three subclasses may be defined, with increasing drop precedence. For example, AF1 may be the highest class of traffic, but within that class, AF13 will be dropped before AF11 or AF12.

Two DiffServ settings once used as part of the standard implementation may soon be deprecated, or rendered obsolete. Those settings, Expedited Flow and Assured Flow, used only the first three bits of the DiffServ codepoint, the type of service (TOS) bits. More recent DiffServ implementations use all six bits, for a total of 64 possible settings.

The predefined QoS definition that ships with Vivinet Assessor, VoIPQoS, is a DiffServ definition that marks bits for Expedited Flow, highest-priority service.

To run a VoIP Quality assessment using your own DiffServ settings, add a QoS definition as instructed below, and then add or copy a Call Script, using the new QoS definition. For more information, see Section 7.10, Working with Call Scripts.

To add a DiffServ definition:

  1. Click the Assess VoIP Quality view tab.

  2. On the Options menu, click QoS Definitions.

  3. Click Add and then click DiffServ Definition.

  4. In the QoS name field, assign a name to your definition. You use this name to identify your settings when you apply QoS to a Call Script.

  5. To use a Predefined DiffServ codepoint, select bit settings from the list. When you make your choice from the list, the graphic illustrating the Bit field settings changes to reflect these choices.

  6. To create a User-defined Diffserv codepoint, click the buttons for customized Bit field settings. The following table shows the DiffServ choices that are available in Vivinet Assessor. TOS-only settings are still supported:

    Bit Settings

    PHB Class

    000000

    Best Effort. Default settings in IP. No special treatment given.

    101000

    Expedited Flow (TOS). Highest-priority service.

    101110

    Expedited Forwarding. Highest-priority (premium) service. Recommended for VoIP.

    011000

    Assured Flow (TOS). Medium-quality service.

    001010

    Assured Forwarding (AF11).

    001100

    Assured Forwarding (AF12).

    001110

    Assured Forwarding (AF13).

    010010

    Assured Forwarding (AF21).

    010100

    Assured Forwarding (AF22).

    010110

    Assured Forwarding (AF23).

    011010

    Assured Forwarding (AF31).

    011100

    Assured Forwarding (AF32).

    011110

    Assured Forwarding (AF33).

    100010

    Assured Forwarding (AF41).

    100100

    Assured Forwarding (AF42).

    100110

    Assured Forwarding (AF43).

  7. Click OK to save your new QoS definition.

NOTE:Some endpoint operating systems require extra configuration to support DiffServ bit settings. For more information, see Section 7.12.1, Configuring Endpoints for Assessments with QoS.