VoIP and Real Time management basics!
Voice over IP (VoIP) is already a business necessity, and video over IP is fast on its heels. The growth of video on IP networks is astounding, and the sum of all forms of video (TV, video on demand [VoD], Internet, and P2P) will be approximately 86% of global consumer traffic by 2016 (see this Cisco paper for details). Though a necessity, the real-time nature of voice and video traffic is often at odds with traditional network traffic, creating undo angst in your IT department. Real-time data, especially video, can bog down enterprise networks and make it difficult to perform mission-critical tasks.
With all this real-time data competing for network bandwidth we need to get back to the basics. Use the right tools for the job, tackle the three VoIP killers - latency, jitter, and packet loss, and effectively manage the end-user experience. Fortunately, there’s no need to reinvent the wheel here. Everything you need is readily available on the market today.
Let’s take a closer look at some of the challanges -
The Right Tools for the Job
Before we can determine the tool, we need to determine the job. Given the maturity of VoIP today, the job is typically ongoing monitoring and troubleshooting for most organizations. But for the sake of completeness, or for those situations where a VoIP upgrade may be in the plans, let’s address the entire VoIP lifecycle, which includes a pre-deployment assessment, deployment and maintenance.
The first step in the VoIP lifecycle process is a complete assessment of network readiness. During pre-deployment, an organization needs to assess the general health and readiness of the network prior to deploying VoIP, focusing on both “traditional” network data and real-time data. One of the best ways to do this is by establishing baselines of the existing infrastructure. This includes overall network metrics like top network users, top applications, and overall application performance, as well as peak performance in each of these areas. Most networks have a “fingerprint,” a reproducible pattern of daily, weekly, and monthly usage. These baselines should be clearly understood before introducing real-time data into the mix.
To be meaningful, this assessment should be carried out across the enterprise network to ensure integrity of the entire system. Along with this assessment, a baseline for the legacy voice environment, if one already exists, should be established. If an organization knows how its network behaves on a regular basis, it will be better prepared to deal with any implications or issues real-time data bring to the equation. For example, how many calls go from building to building? How many calls go outside the network? What are peak usage times? All of this information will show actual traffic patterns, and it is the intersection of the voice environment and the data environment that is truly of interest. It’s important to realize that network conditions that may not cause problems for data applications may be very problematic for VoIP. Baselining can help to provide a level of confidence in identifying potential problems down the road.
What tool is best used to address such a broad scope? Overall network analysis software/appliances are best during this phase. The ability to assess key network metrics and report on them over long time periods, along with the ability to visualize real-time protocols (RTP) as just another data type will provide a single solution to address this phase. Keep in mind that the biggest challenge will be finding a network analysis solution that also addresses RTP adequately.
Once VoIP is deployed, verifying the assumptions made during the design phase is the primary goal. Perhaps your network before introducing VoIP was on the average 30% utilized, with peaks at 70% (but never exceeding that), and your design allows for average utilization to increase to 40% with peaks no higher than 75%, with no more than 5% degradation in overall application response time. As for VoIP, you will use Mean Opinion Score (MOS) as your call quality metric and expect your MOS scores to be no lower than 3.5, with only 10% of your calls falling in the 3.5 – 4 range, and all other calls exceeding a MOS score of 4. This is very specific, but this is the approach that must be taken, as it provides the guidance needed to know if your design is performing as expected. You will also need to compare traditional network performance with VoIP performance in time overlays to assess if the various data types are conflicting with each other.
The best tool in this phase is network analysis software/appliances that utilize deep packet inspection. These tools provide the most complete picture of your network, and because all analysis is done at the packet level, RTP is just another data type, and all traffic is captured simultaneously making conflicts easy to spot. The solution chosen must be capable of analyzing the RTP traffic and calculating RTP performance metrics, like MOS (and other metrics which we will cover shortly) to completely address your design requirements.
The maintenance phase is not substantially different from the deployment phase, with the exception that you no longer want to be actively participating in the analysis 24x7. You want the solution you put in place to continuously analyze in the background, providing alerts only when your design parameters are being violated. The same solution used in the deployment phase will likely have all the capabilities you need to address the maintenance phase as well.
Tackling the Three VoIP - Real Time Killers - Latency, Jitter and Loss!
Latency, jitter, and packet loss exist on every network. Traditional network applications are quite tolerant of these network conditions, at least when they are reasonably controlled. But VoIP, as well as any other RTP-based technology, is not at all tolerant of these conditions. In many cases, what is tolerable for traditional networking may be 10 or even 100 times more than what is tolerable for RTP-based technologies. Let’s take a look at each of these network conditions, and the impacts they have on VoIP and video.
Latency, or the time it takes for packets to travel across the network, is a characteristic of every network. Latency depends heavily on the endpoints of the communication, and includes factors like overall network propagation delay and queuing and decision latency within network equipment. When VoIP is added into the mix, additional latency is contributed by VoIP handsets, including encoding/decoding, compression/decompression, and jitter buffer latency. Given the real-time nature of VoIP, the ITU recommends a one-way latency not to exceed 150ms. If you’re not familiar with current, typical latencies on your network, this is a pretty tight requirement, especially for calls between distant parties. Quality of Service (QoS) is an industry standard technique that must be employed for real-time traffic, but even with appropriately configured QoS on all network devices latency can still be an issue. Even without sophisticated network analysis tools, excessive latency can be detected by just listening. Are callers talking over each other, or is there echo on the line? Both these conditions are a sign of excessive latency. In multimedia sessions, difficulty syncing the audio and video tracks is also a clear sign of latency. Once latency is suspected, you need a network analysis solution that can monitor and analyze each RTP session, packet by packet, to assess overall network latency and confirm appropriate QoS settings.
Whereas latency can be measured by following a single packet from the caller to the callee, jitter measures the variation in that latency from packet to packet. VoIP expects a regular delivery of packets – every 20ms – to the receiver. If every packet arrives 20ms apart, there is no variation and therefore no jitter. When the spacing starts to vary, you have jitter, and this can adversely affect VoIP performance. Because VoIP is so sensitive to jitter, VoIP handsets typically employ a jitter buffer so packets can be put into the right order, and delivered out of the buffer to the decoder at regular 20ms intervals. But the jitter buffer is not always 100% effective, and in cases where the overall latency grows beyond a certain level (like 100ms), packets are too late to even make it into the buffer and just get discarded. Jitter results in odd sound effects like static or stuttering. And if jitter levels are high enough, packet loss results, with parts of the conversation lost forever, leaving gaps of syllables or even entire words or phrases. Again, simply monitoring the call will give you an indication if jitter is present, but a packet-based network analysis solution can provide the detailed jitter analysis you need to confirm the problem and troubleshoot the root cause.
Packet loss is pretty self-explanatory – packets are lost and never become part of the decoded voice string. Although packet loss exists on every network, it is especially troublesome, and more common, with real-time protocols, as packets that are delayed are no longer “real time” and at some point entirely lose their pertinence within the packet stream and are simply dropped. The user notices conditions similar to jitter problems where syllables, words, or even phrases may be missing from the conversation.
Effectively Managing the End User Experience
People have been talking on the phone for well over 100 years, so if there’s one thing that’s well understood it’s how to assess voice quality. Techniques that were developed decades ago have been adapted to apply to digital telephony (VoIP), and they remain excellent indicators of voice quality. As mentioned earlier, one of the key metrics is Mean Opinion Score (MOS). This metric originally started as a qualitative measurement, where individuals would listen to and rate calls as compared to recorded standards. Overall ratings range from one (very poor) to five (excellent). This technique has been adapted to digital voice networks, and the metric can be calculated to reflect various aspects of quality, like listening quality, conversational quality, etc. Routine monitoring of your network should include equipment that can simultaneously analyze your VoIP traffic with your network traffic, analyzing each and every call and determining the MOS for each direction of the call. Remember, “network conversations” can take different paths out and back, so the MOS can differ depending on the direction of the voice traffic. It’s very important to analyze the voice traffic in exactly the same way.
In addition to MOS, the R-Factor is another metric which is often used. The R-Factor takes not only the overall quality into account, but also factors network conditions like jitter, latency, etc. into the overall calculation. R-Factor values range from 0 – 100, and typically track quite closely to MOS calculations. It’s beneficial to have a monitoring solution in place that can report both metrics, providing a “self-check” on overall VoIP performance.
The end user is only concerned with quality, but as a network engineer you’re also concerned with the factors causing poor quality – latency, jitter, and packet loss. Your monitoring solution must be capable of determining these parameters, again for each leg of the call, so you can effectively troubleshoot calls with poor voice quality. Of course you can’t be listening to calls, or even monitoring the metrics behind each and every call, so you need to ensure that your VoIP analysis solution not only calculates, but monitors key metrics continuously and provides the capability to send alarms only when metrics fall outside of normal operating parameters.
VoIP is already a fixture in most businesses, so having a concrete capability to monitor and troubleshoot is a table stake for any network analysis system. As more companies move their communication systems onto digital networks, issues will only happen more frequently, so be sure you have a system in place for dealing with the convergence of voice and data now. Full visibility into all the data types on your network is essential for managing VoIP and other real-time protocols.
Author Profile - Jay Botelho is the Director of Product Management at WildPackets, Inc., a leading network analysis solutions provider for networks of all sizes and topologies. Jay holds an MSEE, and is an industry veteran with over 25 years of experience in product management, product marketing, program management and complex analysis. From the first mobile computers developed by GRiD Systems to modern day network infrastructure systems, Jay has been instrumental in setting corporate direction, specifying requirements for industry-leading hardware and software products, and growing product sales through targeted product marketing.
Recent Comments