No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Test Tools for Voice and Video

I'm at Enterprise Connect this week and my first session was on How to Keep Video from Blowing Up Your Network. It was a great session, well attended, with a lot of really good questions. The key take-away is that you need to identify the video traffic that you do want to support, provide proper QoS handling for it, as well as identifying the video traffic that you don't want and limiting its impact on the network. Allocate some fraction of network bandwidth to video and watch link utilization so that you know when to add bandwidth as the use of video grows. Make sure that the applications that generate money for your business are not starved, perhaps by also using QoS to prioritize them above some types of video traffic.

I emphasized the need to monitor the network to know when links are becoming congested. QoS is only used when congestion exists, so it is important to know when congestion is occurring. You also need to know when voice and video traffic that you want is being impacted, perhaps due to a lack of bandwidth allocation or perhaps because the volume of all, voice, video, and application traffic has increased to the point that the only recourse is to add more bandwidth.

A variety of test tools can alert you to problems with voice and video, either by detecting issues in actual voice and video traffic, or in active path testing. I also hosted a session at Enterprise Connect this week to highlight three categories of tools for monitoring voice and video.

Call System Monitoring
One class of tools monitors the call systems, such as call controllers, gateways, session border controllers, and media control units (MCUs). The voice and video endpoints, including MCUs and gateway, communicate with the call controllers to record statistics about the calls, including factors such as delay, jitter, and packet loss. I like to look through the collected statistics to find sites or subnets that have problems. If a problem is affecting a particular subnet, it will impact all the phones or video systems on the subnet. Based on the statistics and the other endpoints involved in the call, I'll be able to determine a specific set of tests or other data to collect that will allow me to quickly pinpoint the source of the problem. It may be something as simple as a configuration in which QoS is missing or improperly configured. Or it may be a link that has been oversubscribed, in which case I'll need to plan to increase the link bandwidth to transport the volume of traffic that is being generated.

Make sure that you perform a Proof of Concept (PoC) with any proposed tools, paying particular attention to usability at the scale of your voice and video deployment. I was talking with one vendor at the Enterprise Connect exhibition whose product immediately took me down to an individual phone's connection statistics. I could not see the product scaling easily to large numbers of phones. What I need is a summary that allows me to view statistics across hundreds or thousands of phones and video endpoints (with video conferencing on many phones and on the desktop these days, it makes sense to just talk about voice and video as essentially the same type of service--a person-to-person communications mechanism).

Packet Analysis
Another class of tools looks at packets on the wire and is able to perform some quite remarkable analysis of the contents. A couple of tools can detect things like echo, which is something that no other tool that I know about can perform. This type of analysis goes way beyond simply identifying delay, jitter, and packet loss.

Some people object to these types of tools, because it implies placing numerous packet capture probes within the network. In practice, I find that there are typically a number of choke points within the network that will allow most of the voice and video data to be captured. I've also recently become a proponent of span port aggregation boxes (Vendors: Anue, Gigamon), which allow capturing large volumes of data and filtering the data for voice/video monitoring, security, network management, and troubleshooting.

Active Path Testing
The last category of voice/video test tool is active path testing. These are systems that simulate voice and video calls over the network. Their advantage is that you can run tests over paths where real voice and video calls are not yet supported, checking for network readiness prior to a deployment. They are also useful tools for performing network assessments. When a customer complains about voice/video problems, it is useful to implement some tests to verify whether the simulated calls are also experiencing a problem.

In a PoC, check whether the tool you are evaluating can help determine which hop along the path is the one where the problem is originating. Some tools excel at this task, so make sure that your evaluation includes a way to check for the depth of analysis.

The challenge with active path testing tools is to identify and configure enough tests to provide good coverage of the network. I prefer to use bi-directional tests between a couple of core sites and all the non-core sites. This avoids the need to identify and maintain a full mesh of tests. Also examine whether the tool you are evaluating has the ability to create endpoint groups and to automatically generate and perform tests between endpoints within the groups. A few mechanisms for helping administer the set of tests can remove a substantial load from deploying and maintaining this type of tool.

I have found that active path test tools that have the ability to generate alerts is great for ongoing monitoring of the network. If something changes, or if new traffic causes congestion at a certain time of day, I get an alert about it. That way I don't have to look at the reports every day. Instead, I configure the system to run and it tells me when it encounters an exception that I should examine.

Summary
The type of test tool that you acquire is dictated by your needs. If you are having problems, get a PoC of each type of tool and see how quickly it can help you to diagnose one of the problems. If the setup time and analysis time is short, and it accurately reports the problem and its source, then you've found a useful tool.