Measure VoIP Networks for Jitter and Loss

Voice over Internet Protocol can save businesses money on long-distance calls. But, IP networks are not as reliable as the phone network, so they require testing for call setup, voice quality, and packet analysis.

Martin Rowe, Senior Technical Editor -- Test & Measurement World, 12/1/1999

The radio reception in my office is awful, so I use the Internet to receive out-of-town radio stations. Unfortunately, reception over the Internet—like the method of transmission—is digital. Reception is either very good or nonexistent, and dropouts are common. Still, listening to broken reception beats listening to our other technical editor, Rick Nelson, in the next office.

Listening to live radio is an example of using computer networks, including the Internet, to receive digitized audio. Because computer networks—and the Internet—can transmit digitized voice signals, many businesses have begun using their LANs, WANs, and the Internet in place of traditional telephones. The technology known as voice over Internet Protocol (VoIP) offers potential savings over using the public switched telephone network (PSTN) for voice conversations.

But the dropouts that disrupt my radio reception can also affect a phone call, making conversation impossible. Eliminating the disruptions requires specialized VoIP hardware and software that can decode the digital signals and convert them back to analog. Naturally, this technology requires thorough testing of audio quality and protocol analysis.

Taking Advantage of VoIP
VoIP eliminates long-distance telephone charges by sending voice signals over a private LAN or WAN or over the Internet. Currently, if I’m sitting in my Boston office and want to call someone in my company’s Chicago office, I have to use a PSTN and incur a long-distance charge. With VoIP, I could send packets of digitized voice data over the company WAN to my colleague in Chicago, essentially making a free call.

Alternatively, I could use a combination of the WAN and the PSTN. VoIP networks can connect to LANs, WANs, the Internet, the PSTN, ISDN networks, and wireless networks (Fig. 1). Suppose I wanted to call someone else in Chicago—someone who doesn’t work for my company. With the proper VoIP equipment, I would use my company’s WAN to route my call from Boston to our Chicago office, and at that point the company’s equipment would switch my call to the local PSTN to complete the connection. The conversation would bypass the long-distance carrier and avoid long-distance charges.

So far, the idea of using VoIP sounds great and promises to save businesses bundles of cash, but using IP networks to carry intelligible voice isn’t easy. When you use the PSTN, your digitized voice travels over a circuit-switched network. Circuit switching establishes a dedicated channel that remains connected for the duration of the call. A dedicated channel gives you the high quality of service (QoS) you’ve come to expect from the PSTN.

IP networks are designed to carry data that isn’t time sensitive. They can’t guarantee the performance needed for real-time audio transmission and reception. IP-based networks use packet switching that routes packets over many paths. Data can travel over a packet-switched network in packets that arrive at varying times. A “receiver” that runs IP can reassemble the packets into the correct order.

For voice transmissions, however, you wouldn’t tolerate hearing packets of digitized voice in anything but the correct order—a garbled or inconsistent voice would be unintelligible. You can improve the QoS by using special VoIP hardware and software that compensates for many of the problems of sending voice over packet-switched networks—delay, jitter, and lost packets. This equipment lets you send packets of digitized voice data over a network, and then it decodes the packets, extracts the digitized voice, and converts it back to an analog signal.

The VoIP Pieces
VoIP hardware includes terminals, gatekeepers, gateways, and multipoint control units (MCUs). All VoIP networks need a terminal. A terminal can be an Ethernet phone or a PC containing a VoIP interface card, a headset, and a microphone. VoIP networks can also use analog phones connected to routers. Where VoIP networks use analog phones, you can think of the router as a terminal.

Most VoIP networks require a gateway to connect the VoIP terminals to other networks. Terminals on the same side of a router can communicate directly with each other; calls between people in the same department might not pass through a gateway.

Figure 1.  VoIP terminals communicate through gateways and over IP networks. Gatekeepers manage VoIP traffic in zones of a LAN. (Courtesy of RADCOM.)

While gateways provide the interface to other networks, gatekeepers manage several terminals within a zone on a LAN. Gatekeepers route calls from gateways to terminals, a process called address resolution. Gatekeepers also manage the calls based on the available bandwidth of the LAN.¹ A multipoint unit (MCU) lets a VoIP network carry multiple conversations in one call—a conference call. For simplicity, I’ll limit this article to point-to-point calls.

Each of the above components requires software that implements communications protocols defined by several International Telecommunications Union (ITU) recommendations. The ITU has developed Recommendation H.323 as a standard for VoIP protocols.² H.323 incorporates other protocol standards, which perform specific tasks on top of the IP protocol (Fig. 2). These protocols define audio and video coder-decoders (codecs) that digitize and possibly compress voice and image signals prior to transport. Not all VoIP equipment follows the Recommendation H.323, for the document is just that—a recommendation. Most VoIP equipment, however, is based on H.323.

Figure 2.  The H.323 standard adds several protocols (shown in red) on top of Internet protocol for connecting calls and transporting voice packets. (Courtesy of RADCOM.)

Several standards define algorithms for codecs. All H.323-compliant terminals must support ITU recommendation G.711, which defines the protocols for sending uncompressed voice at either 56 kbps or 64 kbps. Uncompressed data produces the highest audio quality, but it consumes more network bandwidth than codecs that compress digitized voice signals.³ Terminal, gateway, and gatekeeper manufacturers may also use several other standards for their codecs, such as those specified by ITU recommendations G.723⁴ and G.729⁵, which compress digitized voice. The greater the compression, the less network bandwidth the voice will need, but compression can affect a network’s QoS.

Other protocols under H.323 handle call setup, call breakdown, and signaling protocols for dial tones, DTMF tones, and so on. To initiate a call, a VoIP terminal must go off hook. As part of the call setup process, the terminal must inform the gateway or gatekeeper of the user’s desire to make a call. The user must get a dial tone and dial the destination number. Each of these processes requires that call-setup messages be sent between the various network components. That call-setup messaging is based on ITU Recommendations Q.931, H. 225.0 and H.245.^6,7,8 The process is similar to a call initiated by an ISDN phone, which also incorporates protocols defined in Q.931.

Establish Communication
After using Q.931 protocols to establish a call, the VoIP equipment on each end of the call negotiates using H.245 protocols until they find a common means to communicate. They negotiate parameters such as the type of codec available at each end of the call. The process is analogous to how two modems negotiate to find a common data rate. Following negotiation, the VoIP terminals or phones can send voice packets to each other. The equipment uses a protocol called real-time transport protocol (RTP) to handle the data transfer. The H.225.0 protocol, called registration/admission status (RAS), handles communications between H.323 terminals and gatekeepers.⁹ During the call, the real-time transport control protocol (RTCP) sends messages between the two stations that contain information such as lost packets.

Setting Up the Tests
Because IP doesn’t guarantee a QoS level, it can lose packets. So, you must test VoIP products for several parameters such as audio quality, jitter, and lost packets. Testing of VoIP networks and components takes place at two levels. You can test a network or a component by measuring the end-to-end audio quality, or you can capture and analyze the IP packets. When evaluating a VoIP terminal, gateway, or gatekeeper design, you will probably start with a protocol analyzer and simulate the rest of the network. As you move to real-world tests, you might add audio-quality tests. Some protocol analyzers have DACs that turn decoded VoIP data into analog signals, then play back the captured voice through a speaker.

Audio-quality tests are essentially QoS tests. You measure the quality of the audio across the network under test. To do that, you need a call generator, test-sound files, and VoIP audio analyzer software in a PC that controls the test equipment. A call generator lets you make calls and perform QoS tests. It also lets you test for the call-setup and call-breakdown messages defined in Q.931.

A call generator digitizes received analog audio and analyzes it for gaps and frequency content. Manufacturers of VoIP systems such as PC plug-in cards and terminals use these tests in production. Manufacturers also use QoS tests on various configurations of routers, gateways, and gatekeepers.

Figure 3 shows how you connect test equipment to a VoIP gateway to test audio quality over a network. Typically, a call generator establishes a call and sends an audio file (such as a WAV file) over the network. The test system digitizes the received audio and analyzes it. Test systems may use any of several methods to analyze speech.¹⁰ Other applications besides VoIP (such as voice over frame relay, voice over ATM, or just testing the voice quality of PSTN) use the same audio-quality tests.

Figure 3. The PSQM test method analyzes the audio quality of a WAV file transmitted over a network.

Using these methods, the test equipment attempts to simulate how the human ear perceives incoming audio. A method called perceptual speech quality measurement (PSQM) grades the audio quality on a scale of 0 to 6.5, with 0 being perfect quality.¹¹ Figure 4 shows a plot of PSQM values vs. number of calls.

QoS test systems identify QoS problems, but they don’t tell you where or why a problem occurs. For that, you need a protocol analyzer. Protocol analyzers decode the IP packets, and they also decode the H.323 set of protocols in the packets. You can a connect protocol analyzer at any point in your network—you just need the proper line interface, such as Ethernet. Protocol analyzers capture data and look at information such as the order of the received packets and their arrival times. With that information, protocol analyzers can calculate statistics on the delays between sent times and arrival times on a packet-by-packet basis. The statistics tell you if VoIP packets arrive in acceptable times to produce acceptable voice quality.

Figure 4. Equipment that tests for voice quality can calculate PSQM values(x axis) versus number of calls (y axis). (Courtesy of Zarak Systems.)

You can connect a protocol analyzer across a network component, such as a gateway, and measure the time between when a packet arrives at and when it departs from the gateway. The analyzer time stamps IP packets and measures the delay, called latency, across the gateway under test. Typically, IP audio will pass through two gateways, one at each end of the IP network.

A gateway is but one contributor to network latency. Each component adds latency to the network. If the latency across a network is too long, you’ll find a conversation impossible to hold. Typically, people can tolerate delays of no more than about 200 ms to 250 ms before the conversation gets annoying. Delays of 400 ms to 500 ms make conversations impractical.12

Latent Times
When you evaluate a new design for a gateway or gatekeeper, you need to measure the amount of latency the product adds to a network. By measuring the latency of each network component, you can build a latency budget that shows where each component adds to the total latency of the network. That information can help you decide if the size of a gateway’s or gatekeeper’s jitter buffer is sufficient to deliver acceptable voice quality over a network. In addition, you must measure jitter and packet loss across a network.

Jitter describes the variations in latency of a VoIP transmission. In data networks, jitter refers to packet jitter, not bit jitter. Too much packet jitter causes voice to sound garbled. Network components compensate for jitter with buffers. Jitter buffers store incoming packets and send them in a more constant stream; the buffers smooth the delivery of packets to produce a more even flow of voice data.

The size of a jitter buffer affects both jitter and latency. If audio transmissions have enough jitter to annoy users, then increasing the capacity of a jitter buffer can reduce jitter to acceptable levels. Too large a buffer, however, may cause latency to increase to where it’s annoying to users. A typical jitter buffer delay is 20 ms, but often reaches 80 ms.13 There is no optimal size of jitter buffer because the buffer size will vary from network to network.

Figure 5.  Jitter measurements tell you the distribution of arrival times among received VoIP packets. (Courtesy of TTC.)

Figure 5 shows a protocol analyzer plot of arrival times for two streams of packets. The packets in the red trace have considerably less jitter than the packets in the blue trace. Network installers often use protocol analyzers to measure jitter and alter the jitter buffer’s capacity. During the tests, installers also monitor latency to see if the jitter buffer produces unacceptable delays in reception of voice packets. Installers have the ability to adjust the size of a jitter buffer for best audio quality.

Excessive packet loss also affects the QoS of a VoIP system. Typically, more than 5% lost packets will annoy users. Protocol analyzers will display the number and percentage of lost packets. They can also tell you when lost packets occur in bursts. For example, if you lose every 20th packet (5%), you’ll still be able to understand the voice. That’s not as bad as losing 1 s of audio followed by 19 s with no lost packets. One full second of lost audio will certainly annoy users.

You should also test VoIP equipment under simulated network conditions. To simulate a network, you’ll need a call generator to automatically generate traffic. Remember that some VoIP networks may use the Internet as a transport medium. On the Internet, packet latency and jitter are more unpredictable than on a private network. You can, however, add an Internet simulator to your test setup. An Internet simulator lets you inject impairments into your packet transmissions. For example, you might limit the bandwidth of the network or force bursts of lost packets. Limiting the bandwidth can introduce latency into the packet transmissions. Bursts of lost packets result in some voice being lost.

When you test VoIP equipment and networks, be sure to simulate more than one call at a time. You should test VoIP equipment with as many simulated calls as possible to see how the equipment operates under a heavy call load.

VoIP is an evolving technology that’s gaining in popularity. As VoIP evolves, so will test equipment and tech methods. It’s a step toward what people really want, real-time conferences, presentations and video without paying long-distance charges. As more companies deploy VoIP, more IP networks will have to carry time and jitter-sensitive packets. Test equipment and test procedures will evolve, too. T&MW

FOOTNOTES
1. “Intel Internet Video Phone Trial Applet 2.2,” Intel, Santa Clara, CA, developer, 1997.
2. ITU-T Recommendation H.323: Packet-based multimedia communication systems, February 1998, International Telecommunications Union, Geneva, Switzerland, www.itu.ch.
3. A Primer on the H.323 Series Standard, Databeam, Lexington, KY, May 1998, p.11.
4. ITU-T Recommendation G.723.1: Speech Codecs: Dual rate speech codes for multimedia transmitting at 5.3 and 6.3 kbits, March 1996.
5. ITU-T Recommendation G.729: Coding of Speech at 8 kbits/s using Conjugate-Structure Algebraic-Code-Excited Linear Prediction (CS-ACELP), March 1996.
6. ITU-T Recommendation Q.931: ISDN user-network interface layer 3 specification for basic call control, May 1998.
7. ITU-T Recommendation H.225.0: Call signaling protocols and media stream packetization for packet-based multimedia communication systems, February 1998.
8. ITU-T Recommendation H.245: Control protocol for multimedia communication, September 1998.
9. A Primer on the H.323 Series Standard, op. cit.
10. PSQM, based on ITU Recommendation P.861, is one of several audio-quality testing algorithms that attempt to simulate a person’s perception to voice quality. Others include PSQM+ and perceptual analysis/measurement system (PAMS).
11. ITU-T Recommendation P.861: Objective quality measurement of telephone-band (300-3400 Hz) speech codecs, February 1998.
12. Percy, Alan, “Understanding Latency in IP Telephony,” Brooktrout Technology, Needham, MA, www.brooktrout.com/pages/technical/white_papers/iptel_latency.htm, February 1999.
13. Boger, Yuval, “Fine-tuning Voice over Packet Services,” available on RADCOM Analyzer Applications CD-ROM, RADCOM, Mahwah, NJ, 1999, www.radcom-inc.com.

FOR FURTHER READING
Ahonen, Jarkko, and Arttu Laine, Realtime speech and voice transmission on the Internet, www.tcm.hut.fi/Opinnot/Tik-110.551/1997/seminar_paper.html, April 1997.

Application Note 11: “Testing VoIP Using PSQM,” Zarak Systems, Sunnyvale, CA, www.zarak.com/ftp/app_0011.PDF.

H.323 Tutorial, Trillium Data Systems, www.webproforum.com/h323/index.html.

Muraskin, Ellen, “VoIP Standards: Industry Food Fight Sprays Alphabet Soup,” Computer Telephony, October 1999, p. 112, www.computertelephony.com.

A Primer on the H.323 Series Standard, Databeam, Lexington, KY, www.databeam.com/h323/h323primer.html, May 1998.

“Protocols for LAN, WAN, ATM data communications and telecommunications,” a Web site sponsored by Radcom: www.protocols.com.

Willis, David, “Measuring Voice Quality: Listening by the Numbers,” Network Computing, May 31, 1999, CMP Media, Manhasset, NY. www.nwc.com/1011/1011colwillis.html.

Brown, Dave, “Videoconferencing 2000: H.323’s Year?” Network Computing, September 6, 1999. www.nwc.com/1018/1018f3.html.

You can contact Martin Rowe at m.rowe@tmworld.com.