Testing ATAs, Gateways, VoIP PBXs, and other Signal Processing Elements in VoIP Networks

Testing such signal processing elements as gateways, ATAs and VoIP PBXs requires tools capable of not only simulating various network conditions but also accurately measuring output performance under such conditions.

To reliably and efficiently handle voice communications, IP networks contain a myriad of signal processing devices including gateways, analog telephone adapters (ATA), and VoIP PBXs. A PSTN/IP gateway permits calls to be placed between a VoIP (define - news - alert) phone and a PSTN phone. In essence, it provides a bridge between two different network technologies — TDM and IP. An ATA is similar to a gateway but generally handles a few lines common to a home or small office application. A VoIP PBX may have PSTN connectivity (and, therefore, gateway functions) or may be totally IP.

Figure 1 shows these elements in a typical PSTN/VoIP network.

Testing these signal processing elements requires powerful and versatile tools to not only simulate various network conditions, but also to accurately measure the resulting output performance. Typical functions the tools must provide are echo, delay, dual tone detection and generation, out of band features, jitter buffer loading, packet concealment algorithms, voice activity detection, various codecs, and applicable protocols, such as RTP and RTCP. Signaling protocols, such as SIP, H323, MGCP, and Megaco, may also be required to test any interactions between signaling and media. In the final analysis, overall voice quality must be assessed with these devices performing their functions. Testing should encompass functional verification, statistical variation such as light to and heavy loading, anomalous conditions such as impairments from TDM and IP sides, and stability testing for reliability and performance.

VoIP Gateway Architecture
Figure 2 depicts the functions in a generalized VoIP Gateway, ATA, or VoIP PBX. They are from left to right:

• SLIC / CODEC — This is a standard PCM TDM interface and can be either 2-wire or T1/E1. In the T1/E1 case, a single VoIP session is multiplexed into a full duplex single timeslot. In the two-wire case, PCM is converted to analog. Other functions for two-wire interfaces are also provided, such as ringing, four-wire to two-wire conversion, battery, etc.
• Echo Cancellation — Due to the echo produced by the hybrid, echo cancellation function is necessary. IP delays can cause annoying echo, even on short circuit lengths. The echo path may be very short in case of a two-wire loop, since the hybrid is within the gateway. If the TDM interface is T1/E1, the echo path could be substantial, as the 2/4- wire hybrid would be located at the terminating end office.
• Call Progress Tones, DTMF Detection and Generation — Call progress tones are required at the interface to the PSTN for normal call handling. DTMF digits may need to be detected and transported as messages out of band to avoid corruption by IP impairments such as packet loss, reordering, or delay. Also, some codecs cannot reliably pass dual tones due to the voice compression scheme used. At the terminating end, the messages representing DTMF digits are reproduced as dual tones. This out of band transmission is important for IVR (Interactive Voice Response) systems that depend on DTMF digits for banking, voice mail, and other automated applications.
• Silence Suppression, Voice Activity Detection, and Comfort Noise — To conserve bandwidth, silence between speech utterances may be detected and not transmitted in packets at all. At the remote end, the silence is reproduced as a low-level “comfort noise” to the far end listener. Low-level noise is preferable to pure silence, which may be mistaken for a “dead” connection.
• Vocoding or Codec Functions — Sophisticated codecs are used to conserve bandwidth. Standard TDM telephony uses 64 kbps PCM ulaw or Alaw codecs. VoIP networks generally use 32 kbps, 16 kbps, or lower rate codecs, thus reducing bandwidth requirements substantially at the expense of some quality. Lately, wideband codecs at 64 kbps achieve higher quality than PCM at the same rate. Thus, VoIP has the capability to potentially provide superior voice quality in comparison to standard telephone service.
• Jitter Buffer and Packet Loss Concealment (PLC) — Packet delay and loss are an inherent part of IP networks. Delayed packets can be handled by either buffering or discarding if they arrive too late. A jitter buffer smoothes delayed packets at the expense of additional delay. PLC substitutes older packets for lost packets. Other concealment algorithms for lost packets are also used.
• Packetization / Depacketization — Finally RTP, RTCP, IP/UDP protocols are used to reliably transport the packets in IP networks.

For thorough testing, the gateway should be surrounded by TDM and IP test simulators and analyzers working in concert. Below we present guidance for testing various functional areas. The use of GL’s PacketGen™, PacketScan™, RTP Toolbox™, and SIPGen™ are highlighted.

Testing the Effect of VoIP Impairments. Jitter, packet loss, and packet delay are inherent impairments of IP networks. The ability of the gateway to handle these impairments efficiently is critical to voice quality.

Testing Jitter Buffer and Packet Loss Concealment (PLC). A jitter buffer temporarily stores arriving packets in order to minimize delay variations. A gateway also resequences out of order packets. This allows the “playout” of packets to headphones, handsets, and speakers to be smooth and continuous. However, jitter buffers can introduce delay. To strike a balance between delay and jitter, the size of the jitter buffer is usually adjusted. A small buffer helps minimize the delay, but increases dropped packets because of late arrivals. Adaptive jitter buffers that adjust jitter buffer size based on network conditions can improve voice quality.

Packet Loss Concealment (PLC) is a technique used to reduce the effects of lost or discarded packets. PLC is generally effective only for small numbers of consecutive lost packets. It usually involves replaying previous received packets at lower volume.

GL’s RTP ToolBoxTM can simulate network impairments such as packet delay variation within a specified jitter buffer size range. This can verify the Gateway jitter buffer implementation for smooth playout. Out of order packets can be simulated to test the gateway resequencing function. Packet loss can be introduced with varying rate to verify Packet Loss Concealment (PLC) algorithms. At the output of the PLC, packets can be analyzed in detail using GL’s PacketScanTM application.

Testing Prioritization. As traffic on the Internet increases, so does the likelihood of traffic congestion. There is a requirement to differentiate between traffic types and provide quality of service commensurate to requirements. For example, real-time traffic, such as voice or video, should have a higher priority to minimize delay than bulk files. However, voice or video can tolerate higher levels of dropped packets. The IP Type of Service (TOS) field tries to provide this prioritization. Differentiated Services (DS) is an advanced feature of TOS.

This feature can be verified by loading the IP network with RTP traffic and other types of traffic (like HTTP, FTP) and verifying that RTP traffic does not suffer any degradation. This requires a simulation tool to generate IP traffic with different TOS field settings and the ability to measure the flow of packets. GL’s SipGenTM, PacketGenTM, PacketScan™, and RTP Toolbox™ applications can perform these tests when used in concert.

Testing Echo Cancellation (EC). Testing echo cancellation performance requires that test equipment surround the Gateway or ATA from the IP and TDM sides. GL’s RTP ToolBoxTM, along with GL’s T1/E1 test equipment, provides a complete echo cancellation testing solution. This solution permits testing ECs from the IP side while simultaneously simulating echo from the TDM side (See Figure 3). ITU Recommendation G.168 is the specification that addresses compliance requirements for echo cancellers. The tests specified in G.168 specification are listed below in Table 1 and are fully supported by GL’s test tools.

Testing Coder and Decoder (Codec). Various codecs are used in VoIP networks to conserve bandwidth. Some of these codecs are also used in conjunction with Voice Activity Detection (VAD). Table 2 provides details on many popular codecs.

Several methods are available to test and verify that gateways have implemented specific codecs correctly. GL’s RTP ToolBoxTM and PacketGenTM test tools provide a variety of features to test codecs.

A reference file can be encoded, transmitted into the gateway, and then decoded at the output of the gateway. The original reference file can be compared to the decoded reference file using an algorithm such as PESQ. The resulting MOS score is an approximate indication that the specified codec was implemented correctly.

Another more exact technique is to verify that the gateway produces an exact output for a given test vector. Tools that permit file playback, file capture, and file conversion from one codec type to another are essential for this type of testing.

Testing Silence Suppression, Voice Activity Detection (VAD), and Comfort Noise Generation (CNG)
Silence suppression and VAD are used to conserve bandwidth. CNG is used to reproduce the noise that has been masked by silence suppression and VAD. Voice quality is dramatically affected if these functions are not implemented correctly. Testing is crucial. GL’s RTP ToolBoxTM, PacketGenTM, and PacketScan™ tools can effectively test the performance of silence suppression, VAD, and CNG.

Testing VAD and Silence Suppression. VAD and silence suppression can be tested by sending known voice files from the TDM interface and observing and measuring the packets at the IP interface. This test can be run with and without VAD enabled. The efficiency of VAD can be assessed by VQT algorithms and packet rate measurements. GL’s PacketScan™, RTP Toolbox™, and T1/E1 cards have features for transmitting and capturing voice files and measuring packet rates at the IP interface.

Testing Comfort Noise Generation (CNG). Testing CNG involves measuring noise level at the input to the TDM side of the gateway and verifying that the noise level is reproduced at the output of the far end gateway. Alternatively, the IP side packets can be captured and analyzed for proper operation. GL’s RTP Toolbox™ includes a Spectrum Analyzer feature that displays the content of the RTP path and also reports measurements of parameters such as noise and signal level.

The above tests should be repeated for different codecs, since VAD and CNG differ for different codecs. Also, the effect of VAD on voice quality can be checked using MOS and R-factor ratings.

Testing of Digits / Tone Generation and Detection
Digits and tones are important for Interactive Voice Response systems (IVRs), digital phones, voice mail, double stage dialing, and many other applications. In essence, the IP network must provide equivalent services as the PSTN with regard to tone generation and detection. RFC 2833 provides some advanced techniques to overcome the distortions introduced by codecs. Testing should encompass both in-band as well as out-of-band digit generation/detection.

Testing Inband Digits. Testing should be by generating DTMF/MF digits with varying power levels at the TDM side and detection of the same digits on the IP side. The reverse condition should also be tested. This test should be repeated for all codecs supported by the gateway.

Testing Out-of-Band Digits. The above tests should be repeated with RFC 2833 enabled in the gateway. These tests should be performed with different digit ON/OFF times to verify RTP timestamps are generated properly.

Importantly, both in-band and RFC 2833 digit tests should be repeated under various RTP impairments, like packet loss and jitter. The gateway should properly detect digits under adverse conditions. For this purpose, a test tool on the IP side should insert impairments while generating digits. Besides out-of-band digits, RFC 2833 identifies other events that should be carried out-of-band. These should also be tested. RTP ToolBoxTM can effectively test all of these functions.

Voice Quality Testing
Voice quality testing is both a subjective and objective process. In general, clarity of voice in the presence of echo, noise, and delay are assessed together to derive what is called a Mean Opinion Score, or MOS. MOS includes both listening and conversational aspects in its overall score. A widely accepted algorithm for assessing voice is the Perceptual Evaluation of Speech Quality (PESQ LQ/LQO) per Rec. P.862/P.862.1. The general principle is depicted diagrammatically below.

Another technique used to assess voice quality is E-Model (G.107 Specification). This model provides a test rating factor called R-factor. The R-factor attempts to assess impairments, like packet delays, packet loss, duplicate packets, and different codecs into an overall rating that can be related to MOS.

The above two techniques rely on two different methods for voice quality. PESQ relies on an intrusive end-to-end comparison of waveforms, while Emodel/ R-factor is non-intrusive and can be performed anywhere in the end-toend path. Both methods are available in GL’s VQT software and RTP Toolbox™ to provide a comprehensive test bed for voice quality measurements in packet networks (See Figure 4).

Conclusion
This article has reviewed some of the more important features of signal processing elements in VoIP networks and testing methods for verifying quality and performance. VoIP networks are quite different from TDM networks. The right test tools and thorough testing before deployment can save time, money, and headaches. A thorough discussion of the tools mentioned in this article is provided at http://www.gl.com.

Vijay Kulkarni is President of GL Communications, (news - alert) and directs product development and consulting services. He can be reached at [email protected]. John Phipps is a Senior Engineer at GL Communications, and responsible for test and verification of Packet Products. He can be reached at [email protected].