| ||
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.
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.
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 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 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.
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).
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.
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.
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).
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.
Commercial analyzers typically provide more reporting features including R-value and MOS values, as shown in Figures 4-5 and 4-6.
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. |