Figure 5 - H.323 protocol stack

Control messages (Q.931 signalling, H.245 capability exchange and the RAS protocol) are carried over the reliable TCP layer. This ensures that important messages get retransmitted if necessary so they can make it to the other side. Media traffic is transported over the unreliable UDP layer and includes two protocols as defined in IETF RFC 1889: RTP (Real-Time Protocol) that carries the actual media and RTCP (Real-Time Control Protocol) that includes periodic status and control messages. Media is carried over UDP because it would not make sense for it to be retransmitted: should a lost sound fragment be retransmitted, it would most probably arrive too late to be of any use in voice reconstruction. RTP messages are typically carried on even-numbered UDP ports, whereas RTCP messages are carried on the adjacent odd-numbered ports. The following figure illustrates the different encapsulations by showing a side-by-side display of actual RTP and H.22 5 messages:

 

In contrast to broadcast-type media transmission (e.g., RealAudio), a two-way phone conversation is quite sensitive to latency, Most callers notice round-trip delays when they exceed 250mSec, so the one-way latency budget would typically be 150 mSec. 150 mSec is also specified in ITU-T G.114 recommendation as the maximum desired one-way latency to achieve high-quality voice. Beyond that round-trip latency, callers start feeling uneasy holding a two-way conversation and usually end up talking over each other. At 500 mSec round-trip delays and beyond, phone calls are impractical, where you can almost tell a joke and have the other guy laugh after you've left the room. For reference, the typical delay when speaking through a geo-stationary satellite is 150-500mSec.

Data networks were not affected by delay. An additional delay of 200 mSec on an e-mail or web page goes mostly unnoticed. Yet when sharing th e same network, voice callers will notice this delay.

When considering the one-way delay of voice traffic, one must take into account the delay added by the different segments and processes in the network, as shown in the following diagram:

Figure 6 - Delay budget in a network

Some components in the delay budget need to be broken into fixed and variable delay. For example, for the backbone transmission there is a fixed transmission delay which is dictated by the distance, plus a variable delay which is the result of changing network conditions.

The most important components of this latency are:

When designing or optimizing a network, it is often useful to build a table showing the one-way delay budget as in the example below with typical values:

Figure 7 - Sample delay budget

Measuring latency

There are three interesting configurations for measuring latency: measuring latency of a device, measuring round-trip delay and measuring one-way delay.

Measuring latency of a device is important to understand how the delay budget gets spent over the network. In particular, it is interesting to measure the latency of data going through a gateway since several user-configurable parameters such as jitter-buffer size affect the latency. Thus, after configuring such parameters, it is important to be able to verify that the gateway actually behaves as expected.

Another unique application that is extremely suitable for these types of measurement is the latency and loss application. When running this application, the analyzer is placed in non-intrusive monitor (listening) mode on the ingress and egress ports. The gateway continues to perform its role in the network, with actual packets flowing through it. Instead of requiring the user to define test traffic for generation through the device, RADCOM analyzers perform this measurement on the actual data and on any device. The diagram below shows such test configuration.

Figure 8 - Measuring the delay across a gateway

Once the data is captured on both sides of the device, the analyzer runs a heuristic algorithm that automatically correlates the data captured on both segments. Each frame on one side is matched with data on the other side. As a result, the analyzer displays graphical and numerical information about the latency and loss through the device. As latency may be different in each direction, two latency histograms are displayed side-by-side as shown below:

Figure 9 - Latency and loss measurement results

The analyzer can measure the latency through a network using a similar method. When the two end-points are geographically distant, it is often less convenient to perform one-way latency measurements because such an operation requires synchronizing the control and timestamp of two separate analyzers. Instead, many users measure the round-trip time and assume it is twice the one-way time for each direction. Round-trip measurements can be done using a protocol analyzer, or as a first approximation using the ping utility generating ICMP echo requests through the network.

While network latency effects how much time a voice packet spends in the network, jitter controls the regularity in which voice packets arrive. Typical voice sources generate voice packets at a constant rate. The matching voice decompression algorithm also expects incoming voice packets to arrive at a constant rate. However, the packet-by-packet delay inflicted by the network may be different for each packet. The result: packets that are sent in equal spacing from the left gateway arrive with irregular spacing at the right gateway, as shown in the following diagram:

Figure 10 - Packet Jitter

Since the receiving decompression algorithm requires fixed spacing between the packets, the typical solution is to implement a jitter buffer within the gateway. The jitter buffer deliberately delays incoming packets in order to present them to the decompression algorithm at fixed spacing. The jitter buffer will also fix any out-of-order errors by looking at the sequence number in the RTP frames. The operation of the jitter buffer is analogous to a doctor's office where patients that have appointments at fixed intervals do not arrive exactly on time and are deliberately delayed in the waiting room so they can be presented to the doctor at fixed intervals. This makes the doctor happy because as soon as he is done with a patient, another one comes in, but this is at the expense of keeping patients waiting. Similarly, while the voice decompression engine receives packets directly on time, the individual packets are delayed further in transit, increasing the overall latency.

Jitter is calculated based on the inter-arrival time of successive packets. Frequently, two numbers are given: the average inter-arrival time, and the standard deviation. On a good network, the average inter-arrival time will be the inter-arrival time of the emitted packets, and the standard deviation will be low - pointing at a consistent inter-arrival time.

When correct jitter measurements are desired for audio streams, it is important to take into account three phenomena: silence suppression, packet loss and out of sequence errors.

CODECs take advantage of periods of silence in the conversation to reduce the number of packets being sent. Typically, up to 50% bandwidth savings can be realized in this way. The RTP packet immediately after a period of silence is marked with the silence suppression bit. Jitter calculations look at the silence suppression bit and disregard the long gap between the packet right before the silence and the packet right after the silence period.

In the event of packet loss, the inter-arrival time between two successive packets will also appear excessive. For instance, if three packets were sent at a time of 0, 20 and 40 mSec, and the second packet was lost in transit, the inter-arrival time would appear to be 40mSec even if the network induced no jitter. Correct jitter measurements would discover these cases by looking at the packet sequence number and compensate for packet loss in the jitter calculation.

Out of sequence packets may also skew jitter measurements when not taken into account. For instance, consider an example where packet 1 was sent at time 0 and arrived at time 100, packet 2 was sent at time 20 and arrived at time 140 while packet 3 was sent at time 40 and arrived at time 120. Packets arrived to the receiver at times 100, 120 and 140, so no jitter would be detected unless the analyzer also examined the sequence numbers. When doing so, the jitter would be calculated based on a 40 mSec inter-arrival between packets 1 and 2, as well as a -20 mSec inter-arrival time between packets 2 and 3.

RADCOM offers solutions for measuring jitter over any physical interface. In particular, the RADCOM AudioPro is capable of tapping into a VoIP link, separating the individual audio streams and providing simultaneous jitter measurements of these streams while taking into account silence suppression, packet loss and out-of-sequence packets. Such an analysis is shown below:

Figure 11 - Audio jitter analysis

Packet loss is a normal phenomenon on packet networks. Loss can be caused by many different reasons: overloaded links, excessive collisions on a LAN, physical media errors and others. Transport layers such as TCP account for loss and allow packet recovery under reasonable loss conditions.

Audio CODECs also take into account the possibility of packet loss, especially since RTP data is transferred over the unreliable UDP layer. The typical CODEC performs one of several functions that make an occasional packet loss unnoticeable to the user. For example, a CODEC may choose to use the packet received just before the lost packet instead of the lost one, or perform more sophisticated interpolation to eliminate any clicks or interruptions in the audio stream.

However, packet loss starts to be a real problem when the percentage of the lost packets exceeds a certain threshold (roughly 5% of the packets), or when packet losses are grouped together in large packet bursts. In those situations, even the best CODECs will be unable to hide the packet loss from the user, resulting in degraded voice quality. Thus, it is important to know both the percentage of lost packets, as well as whether these losses are grouped into packet bursts.

When the RADCOM AudioPro analyzes audio streams, it provides both top-level statistics as well as drill-down analysis of individual packet loss. The summary statistics for a sample audio stream with heavy losses are shown in Figure 12. Figure 13 shows the packet-by-packet analysis, with packets just before or after a loss clearly marked.

Figure 12 - Summary Statistics

Figure 13 - Drill-down analysis

Using this analysis, it is easily possible to verify whether the current network conditions allow quality voice communications.

 

Having discussed the parameters that affect voice quality, and especially jitter and loss, perhaps it is a good time to elaborate on some of network conditions affect these parameters.

A very important factor affecting voice quality is the total network load. When the network load is high, and especially for networks with statistical access such as Ethernet, jitter and frame loss typically increase. For example, when using Ethernet, higher load leads to more collisions. Even if the collided frames are eventually sent over the network, they were not sent when intended to, resulting in excess jitter. Beyond a certain level of collisions, significant frame loss occurs.

While good network design takes into account the network load, it is not always under your control. However, even in congested networks it is sometimes possible to employ packet prioritization schemes, based on port numbers or on the IP precedence field. These methods, typically built into routers and switches, allow giving timing-sensitive frames such as voice priority over data frames. There is often no perceived degradation in the quality of data service, but voice quality significantly improves. Another alternative is to use bandwidth reservation protocols such as RSVP (resource reservation protocol) to ensure that the desired class of service is available to the specific stream.

To measure the network load, as well as the number of collisions, many different tools are available, including RADCOM protocol analyzers. To gauge the effect of priorities, it is possible to use the latency and loss application to ensure that priorities are configured correctly and indeed voice is given precedence over data traffic.

 

The jitter buffer can be configured in most VoIP gear. The jitter buffer size must strike a delicate balance between delay and quality. If the jitter buffer is too small, network perturbations such as loss and jitter will cause audible effects in the received voice. If the jitter buffer is too large, voice quality will be fine, but the two-way conversation might turn into a half-duplex one.

One can decide on a jitter buffer policy that specifies that a certain percentage of packets should fit in the jitter buffer, say 95%. Since the utilization of the jitter buffer depends on the arrival times of the packets, it is useful to look at the jitter buffer problem using a few calculations, as automatically performed by the AudioPro:

Figure 14 - Jitter buffer calculations using the Jitter Expert ™

In the above table, an audio-stream with a typical inter-packet emission time of 20 mSec is analyzed. the following columns are displayed:

From the Bias column it is now possible to determine the size of the desired jitter buffer. If no packets are to be lost, set the jitter buffer size to the maximum bias value. If you want the buffer to accommodate 95% of the packets, set the jitter size to the 95-percentile value of the bias.

Although this analysis was performed on only one stream, the AudioPro collects the data on all audio streams and allows performing statistical calculations across multiple streams.

Packet size selection is also about balance. Larger packet sizes significantly reduce the overall bandwidth but add to the packetization delay as the sender needs to wait more time to fill up the payload.

Overhead in VoIP communications is quite high. Consider a scenario where you are compressing down to 8 Kbps and sending frames every 20 mSec. This results is voice payloads of 20 bytes for each packet. However, to transfer these voice payloads over RTP, the following must be added: an Ethernet header of 14 bytes, IP header of 20 bytes, UDP header of 8 bytes and an additional 12 bytes for RTP. This is a whopping total of 54 bytes overhead to transmit a 20-byte payload.

In some cases, such an overhead is fine. In others, there are two solutions to the problem:

The AudioPro displays the payload efficiency, average frame rate and average bit rate for each stream, so it is possible to make intelligent decisions on the suitability of the payload size for each network.

Silence suppression takes advantage of prolonged periods of silence in conversations to reduce the number of packets. In a normal interactive conversation, each speaker typically listens for about half the time, so it is not necessary to transmit packets carrying the speaker's silence. Many vendors take advantage of this to reduce the bandwidth and number of packets on a link.

There is no discernible downside to employing silence suppression. To verify if silence suppression is turned on in various devices, and what the typical savings can be gained, the AudioPro reports the silence suppression statistics, as shown below for a NetMeeting recording:

Aside from verifying that silence suppression is turned on, these statistics allow planning for the expected utilization of a network.

 

So-far this article has focused on quality and performance problems related to voice transmission once a voice call has been established. However, the call establishment process also presents a performance challenge, one that is clearly important to the customer. In particular, the following parameters should be noted:

Testing and measuring these parameters involves looking deeply into Q.931 messages, and analyzing the message sequences. Q.931 messages have a field called "call reference" that allows to distinguish one setup procedure from the other. These messages are interleaved with the normal data transfer, so it is sometimes difficult to fish for the Q.931 needle in the total packet haystack.

Fortunately, tools like the AudioPro separate the control plane message from the packet stream and present it in a call-oriented format. Using such tools, you will want to perform the following some or all of the following steps:

1. Analyze the call success ratio, including the ability to look at calls generated or received from specific phone numbers.

2. Look at the call list to identify individual problematic calls.

3. Drill down to specific calls to view conversation-based H.323 decoders.

4. Examine performance statistics such as call setup times.

 

Can voice quality be measured?

With all the factors affecting voice quality, many people ask how one measures voice quality. Standards bodies like ITU are continuously addressing this issue, and have already derived two important recommendations: P.800 (MOS) and P.861 (PSQM). P.800 deals with defining a method to derive a Mean Opinion Score of voice quality. The test involves recording several pre-selected voice samples over the desired transmission media and then playing them back to a mixed group of men and women under controlled conditions. The scores given by this group are then weighed to give a single MOS score ranging between 1 (worst) and 5 (best). A MOS of 4 is considered "toll-quality" voice.

P.861 Perceptual Speech Quality Measurement (PSQM) tries to automate this process by defining an algorithm through which a computer can derive scores that have a close correlation to the MOS scores. While PSQM is useful, many people have voiced concerns over the suit ability of this recommendation to packetized voice networks. It seems that PSQM was designed for the circuit-switched network and does not take into effect important parameters such as jitter and frame loss that are only relevant to VoIP.

As a result of PSQM limitations, researchers are trying to come up with alternative objective ways to measure voice quality. One such proposal is the Perceptual Analysis/Measurement system (PAMS) developed by British Telecom. Tests conducted by BT have shown good correlation between automated PAMS scoring and manual MOS results.

Sometimes, you will have to be your own judge of quality. Tools like RADCOM's AudioPro extract individual voice calls and then decompress the captured data using the detected compression method to allow listening to the actual voice recording. By repeating this process at different points along the voice path it is not only possible to get a sense of quality, but also to determine at what point along the network voice quality degradation occurs.

 

Simulating the effects of the network

With so many potential pitfalls, it is often desirable to simulate the target network before deploying actual equipment. Such simulation allows you to gauge the effect of a sub-optimal communication link on voice quality and configure critical parameters such as jitter buffers before going into the field.

Tools such as RADCOM's Internet Simulator™ allow simulating the effect of the Internet or corporate Intranet on delay-sensitive data. Such solutions allow injection of controlled delay, jitter, out-of-sequence errors as well as frame loss.

Figure 15 - Internet Simulator

The Internet Simulator also works hand-in-hand with the latency and loss application and AudioPro, allowing the extraction network parameters from the customer network and their transfer into the Internet Simulator for simulation in the lab.

Figure 16 - VoIP design and deployment planning cycle

Voice over IP services offer lucrative advantages to customers and service providers alike. However, as with any new technology, it brings its own sets of network design and optimization issues. By understanding the important parameters, and acquiring the proper tools, you can reap the benefits of voice over packet services.

courtesy of RadCom Research