Measuring Voip Call Quality

The biggest roadblock to VoIP adoption today is simply making sure that a phone call sounds as clear as a call made from the traditional PSTN. Poor VoIP network quality can cause phone conversations to skip, sound tinny or choppy, or become unintelligible to the point where the talking parties have no choice but to hang up. As you would expect, network attacks and congestion problems can also affect the signaling aspect of VoIP by delaying dial-tone or initial call setup after dialing.

The media compression algorithms (codecs) inherent in VoIP applications are very sensitive to network delays and congestion. Depending on the particular compression algorithms, a one-second network outage may actually impact several seconds of speech. VoIP call degradation can be generally lumped into the following three root causes: network latency, jitter, and packet loss. The International Telecommunication Union (http://www.itu.int) has developed two documents that provide some general requirements for the clear transmission of VoIP calls:

  • ITU-T G.113   Transmission impairments due to speech processing

  • ITU-T G.114   One-way transmission time

Another great resource from Intel, "Overcoming Barriers to High-Quality Voice over IP Deployments," can be found at: http://www.intel.com/network/csp/pdf/8539.pdf.

Network Latency

Quite simply, latency is the amount of time it takes for a packet to travel from the speaker to the listener. Obviously in the traditional PSTN world, there's usually a slight speech delay due to latency when making an international call because of the traversed distance involved. VoIP latency is affected by things such as the physical distance of network cabling, large numbers of intermediate Internet hops, network congestion and oversubscription, and poor or no internal bandwidth prioritization. The aforementioned ITU recommendation (G.114) states that a one-way VoIP latency of more than 150 ms will be noticeable to the speaking parties. The majority of this latency measurement will probably be incurred from the Internet since your enterprise network will typically have low network latency. Many Internet service providers will uphold a service level agreement to maintain a maximum latency through their network. Table 4-1 details a few sample numbers taken from some of these service providers' service level agreements, as of the time of this book's publication.

Table 4-1: Latency, Jitter, and Packet Loss Service Level Agreements for Several ISPs

ISP

Latency

Jitter

Packet Loss

AT&T Managed Internet Service (http://www.att.com/abs/serviceguide/mis/sg_mis_ service_lvl_mgmt.html)

39 ms maximum latency

Not given

00.1 percent maximum packet loss

Verizon Voice over IP (http://www.verizonbusiness.com/terms/us/products/ advantage/)

55 ms maximum latency

1 ms maximum jitter

0.5 percent maximum packet loss

Qwest SLA (http://www.qwest.com/legal/docs/Qwest_Internet_SLA__10_ 07_04_.pdf)

50 ms maximum latency

2 ms maximum jitter

0.5 percent maximum packet loss

Verio SLA (http://www.verio.com/global-ip-guarantee/)

50 ms maximum latency

Maximum jitter not to exceed 10 ms more than 0.1 percent of the time

0.1 percent maximum packet loss

Internap SLA (http://www.internap.com/product/technology/ performanceip/page1525.html)

45 ms maximum latency

Less than 0.5 ms jitter

0.3 percent maximum packet loss

Jitter

Jitter occurs when the speaker sends packets at constant rates but they are received by the listener at variable rates, resulting in choppy or delayed conversation. Jitter most often occurs in networks with no bandwidth or QoS management, resulting in equal prioritization of the VoIP traffic with all other data traffic. IETF RFC 3550 ( RTP: A Transport Protocol for Real-Time Applications ) and RFC 3611 ( RTP Control Protocol Extended Reports (RTCP XR )) describe how to calculate jitter. If a caller experiences jitter greater than 25 ms, it will be noticeable to the speaking party.

Many VoIP applications and devices try to compensate by building a jitter buffer . A jitter buffer stores a small amount of the VoIP conversation ahead in order to normalize packets received later. Jitter buffers are typically only effective when the amount of jitter is less than 100 ms. Similarly, many ISPs also build maximum jitter restrictions into their service level agreements, also shown in Table 4-1.

Packet Loss

Packet loss in a data network generally occurs under heavy load and congestion. In most traditional TCP/IP data applications, lost packets are typically retransmitted and there is no noticeable disruption in service. With VoIP applications, however, resending a lost VoIP packet is useless as the conversation has already moved on at that point. Today most VoIP applications use UDP anyway, which has no capacity for loss detection. A mere 1 percent packet loss can seriously impact any VoIP applications on the network. Table 4-1 lists the service level agreements from ISPs pertaining to packet loss.

VoIP Call Quality Tools

There are a variety of tools for measuring and monitoring the health of VoIP traffic in your network. Some tools are free software downloads, while others are fairly expensive appliances that you can place at strategic points within your network. Some network switch vendors also provide the ability to leverage existing infrastructure to measure VoIP quality.

Cisco, for instance, provides several tools that interface with your Cisco routers, switches, and VoIP gear to keep tabs on VoIP health (see "Monitoring Voice over IP Quality of Service" at http://www.cisco.com/warp/public/105/voip_monitor.html). One such tool is the CiscoWorks QoS Policy Manager, shown in Figure 4-1, which provides real-time QoS reporting capabilities based on predefined policy groups (http://www.cisco.com/en/US/products/sw/cscowork/ps2064/index.html).

image from book
Figure 4-1: Cisco Policy Manager 3.2

Voice quality tends to be a fairly subjective characteristic to measure, in part because no one hears the same sound in quite the same way. The Mean Opinion Score (MOS) (defined in ITU P.800) is measured subjectively by having a group of listeners rate different voice selections through the same circuit on a scale from 1 (unintelligible) to 5 (very clear). Another ITU recommendation (ITU-T G.107) defines a more mathematical way of predicting the MOS through some of the objective network characteristics mentioned earlier (latency, jitter, and packet loss). This more scientific measurement is known as the R-value , calculated from 1 (unintelligible) to 100 (very clear), and tends to be a fairly accurate measure without having to go out and survey 20 of your cubicle mates. Table 4-2 is a general mapping of R-value to MOS values.

Table 4-2: R-Value to MOS Mapping from the Telecommunication Industry Association, "TelecommunicationsIP Telephony EquipmentVoice Quality Recommendations for IP Telephony"

R-Value

Characterization

MOS

90100

Very satisfied

4.3+

8090

Satisfied

4.04.3

7080

Some users dissatisfied

3.64.0

6070

Many users dissatisfied

3.13.6

5060

Nearly all users dissatisfied

2.63.1

060

Not recommended

1.02.6

The following broad categories of "VoIP health" measuring tools may help you get a handle on degradation issues. Many will try to calculate R-value or estimate MOS in addition to latency, jitter, and packet loss statistics.

VoIP Software Network Sniffers and Analyzers

There are several network sniffers available that are able to analyze VoIP RTP media packets. Wireshark (formerly Ethereal) (http://www.wireshark.org) is a free packet analyzer that has the ability to collect raw packets and decode them on a variety of predefined protocols including VoIP (see Figure 4-2). To generate traffic over the Internet, we used Vonage's softphone client, which is a rebranded version of the Counterpath SIP XTEN softphone (http://www.counterpath.net).

image from book
Figure 4-2: Wireshark raw packet capture

By selecting Statistics RTP Show All Streams, we see a tabulation of Packet Lost and Max Jitter and Mean Jitter, as shown in Figure 4-3. We can also graph these statistics by selecting the Graph function, as shown in Figure 4-4.

image from book
Figure 4-3: RTP Streams overview
image from book
Figure 4-4: Graph of jitter over time

Commercial analyzers typically provide more reporting features including R-value and MOS values, as shown in Figures 4-5 and 4-6.

image from book
Figure 4-5: Empirix Hammer Call Analyzer
image from book
Figure 4-6: WildPackets EtherPeek VoIP analysis

VoIP Quality Measurement Appliances

There are also a plethora of appliances that have the ability to analyze real-time VoIP traffic passively . Many of these appliances also have the ability to generate calls and simulate various network conditions to stress test your network. A brief list of traffic quality appliance vendors include the following:

  • Agilent Technologies   http://www.agilent.com/

  • Brix Networks   http://www.brixnet.com/

  • ClearSight Networks   http://www.clearsightnet.com/

  • Empirix   http://www.empirix.com

  • Finisar   http://www.finisar.com

  • Fluke Networks   http://www.flukenetworks.com

  • NetIQ   http://www.netiq.com

  • Qovia   http://www.qovia.com

  • SecureLogix   http://www.securelogix.com

  • Sunrise Telecom   http://www.sunrisetelecom.com/

  • TouchStone   http://www.touchstone-inc.com/

  • WildPackets   http://www.wildpackets.com/

A fairly extensive list of additional vendors is located at http://www.voip- info .org/wiki/view/How+To+Debug+and+Troubleshoot+VOIP.

Tip 

When performing some of the following attacks on your own network, many of the packet analyzers mentioned in the previous sections are useful in gauging how susceptible your VoIP applications are to network disruption. It makes sense to first baseline your normal VoIP application performance, and then monitor any deviations once you try some of the following techniques.



Hacking Exposed VoIP. Voice Over IP Security Secrets & Solutions
Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions
ISBN: 0072263644
EAN: 2147483647
Year: 2004
Pages: 158

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net