Vivinet Diagnostics call scripts emulate each of the following popular codec types: G.711u, G.711a, G.726, G.729, G.729A, G.723-ACELP, and G.723-MPMLQ. In each call script, parameters such as the size of the jitter buffer to emulate are selected for you. To change a parameter value, create a new call script based on one of the default scripts.
For more information, see the following topics:
By default, call scripts correspond to codecs, as indicated by their names. Although you cannot change default call scripts, you can create new call scripts based on the default scripts. After you create a call script with customized settings, you assign it a name to distinguish it from the default call script on which it was based. A call script you modify and rename is available in the Call Scripts List dialog box and can be edited.
To review a call script’s parameters, click Call Scripts on the Options menu. Select a script and click View.
To create a new call script based on an existing script, click Call Scripts on the Options menu. Select the script you want to copy and click Copy.
To create a new call script from scratch, click Call Scripts on the Options menu and then click Add.
To modify a call script you created, click Call Scripts on the Options menu. Select the script you want to edit and click Modify. You cannot modify a default script.
To delete a call script you created, click Call Scripts on the Options menu. Select the script you want to delete and click Delete. You cannot delete a default script.
The following table defines the fields on the Add a Call Script dialog box. The default call script parameters affect how test traffic appears to devices on the network.
|
Field |
Definition |
|---|---|
|
Call Script name |
The name of the call script. Can be the default name or one you assign to a new or copied script. |
|
Codec |
The type of codec used in your network. The default codec is G.711u. For more information, see Section 4.2.2, Reviewing Codecs. |
|
Packet Loss Concealment |
Packet Loss Concealment (PLC) is enabled in the G.711 call scripts because VoIP phones that use this codec now perform PLC. For more information, see Section 4.2.3, Understanding Packet Loss Concealment. |
|
Use silence suppression |
Emulates the effects of silence suppression, or voice activity detection, on the line during the Diagnosis. Disabled in all call scripts. For more information, see Section 4.2.4, Understanding Silence Suppression. |
|
Override delay between voice datagrams |
Determines the datagram size to be used in the call script. VoIP applications break voice data into chunks based on delay, or the amount of time, in milliseconds (ms), between successive datagrams. For the G.723 codecs, the value is 30 ms. For all other codecs, the value is 20 ms. |
|
QoS name |
Emulates the effects of a Quality of Service (QoS) scheme for VoIP calls. To enable QoS, select a QoS setting that determines how the traffic will be marked. QoS is not supported by all endpoint operating systems. For more information, see Section 4.3, Working with Quality of Service. |
|
Jitter buffer |
Emulates the effects of jitter buffering on your VoIP network. Jitter buffers can be configured based on time (called an “absolute” jitter buffer) or based on number of datagrams (a “frame-based” jitter buffer). All call scripts have a jitter buffer of two voice datagrams. For more information, see Section 4.2.5, Defining Jitter Buffer. |
|
Additional fixed delay |
Additional milliseconds of delay you choose to add to a call. |
In a VoIP transmission, the codec, short for compressor/decompressor, samples the sound and determines the data rate. If you installed Performance Endpoints on your network, you can perform diagnoses using various codec types, which are represented by call scripts in Vivinet Diagnostics. For more information, see Section 4.2, 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. Vivinet Diagnostics uses this codec when running diagnoses in environments that use unsupported codecs. G.711u mimics the traffic behavior of the known unsupported codecs. |
|
G.711a |
ITU standard for H.323-compliant codecs. Uses the A-law for companding, a popular standard in Europe. |
|
G.726 |
A waveform codec 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, this is a less-complex version of the G.729 codec. Developed for simultaneous voice and data applications for which the G.729 codec is too complex. Speech quality is virtually indistinguishable between G.729 and G.729A. |
|
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. |
Packet Loss Concealment (PLC) is an option for the G.711u and 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, Vivinet Diagnostics assumes the quality of your conversation would be improved, but this improvement is only factored into the MOS calculation if any data is lost.
In the following table, Packetization Delay refers to the delay a codec introduces as it converts a signal from analog to digital. This delay is included in the MOS and in delay diagnoses on the Target Devices, as is the Default Jitter Buffer Delay, the delay introduced by the effects of buffering to reduce inter-arrival delay variations.
|
Codec |
Default Data Rate |
Default Datagram Size |
Packetization Delay |
Default Jitter Buffer Delay |
Theoretical Maximum MOS |
|---|---|---|---|---|---|
|
G.711a G.711u |
64kbps |
20 ms |
1.0 ms |
2 datagrams (40ms) |
4.40 |
|
G.726 |
32kbps |
20 ms |
1.25 ms |
2 datagrams (40ms) |
4.22 |
|
G.729 G.729A |
8kbps |
20 ms |
35.0 ms |
2 datagrams (40ms) |
4.07 |
|
G.723.1-MPMLQ |
6.3kbps |
30 ms |
67.5 ms |
3 datagrams (60ms) |
3.87 |
|
G.723.1-ACELP |
5.3kbps |
30 ms |
67.5 ms |
3 datagrams (60ms) |
3.69 |
Call scripts include an option to use silence suppression in the VoIP call traffic Vivinet Diagnostics sends on the network between endpoints. Silence suppression is disabled in all call scripts.
Silence suppression occurs when no data is sent on the network during periods of call silence, that is, when no one is “talking” in the simulated call.
To minimize voice disruptions from delay and jitter, VoIP equipment typically has a jitter buffer. A jitter buffer can be either frame-based or absolute. A frame-based jitter buffer holds a given number of voice datagrams. 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 variability in arrival times. An absolute jitter buffer, on the other hand, might be set to 43 ms, and, given a typical 20-ms speech frame size, could hold two speech frames and allow for an extra three milliseconds of variability.
All call scripts used in Vivinet Diagnostics call performance tests emulate a frame-based jitter buffer of two datagrams.
During a Diagnosis, Vivinet Diagnostics calculates packet loss due to the sizes of the jitter buffers between the Target Devices and uses this statistic in estimating the quality of simulated VoIP calls. If jitter occurs on the network, jitter buffers can smooth it out, but they also exacerbate data loss: datagrams not contained by the jitter buffer are discarded. The jitter buffer lost datagrams statistic includes:
jitter buffer overruns — datagrams that had a delay variation greater than the jitter buffer size or were delayed too long. For example, a datagram with a delay of 50 ms would not be contained in a jitter buffer set to 40 ms. Or if five datagrams were delayed sequentially, an absolute jitter buffer set to two datagrams would discard three datagrams.
jitter buffer underruns — datagrams that arrived too quickly while the jitter buffer was still full.
Jitter buffers may also be static or dynamic. Each type of buffer has its strengths, but it is in the nature of IP networks to exact a trade-off. Buffering not only causes loss, but also adds delay, which can offset the positive effects of smoothing out jitter. Check the “Jitter Buffer Loss” statistic in the Results table of the Report view to see whether jitter buffers are also adding data loss. For more information, see Section 5.3.5, Jitter Buffer Loss.