Some cavalierly refer to IP telephony as "just another application" that rides over your data network. But wait and see what happens if VoIP call quality starts eroding or, worse yet, if your organization's phone calls stop altogether.

In this Clear Choice Test, we evaluated a burgeoning class of new products, collectively called VoIP analysis tools. These wares help the VoIP network manager proactively monitor and troubleshoot the IP telephony environment to ensure call continuity.

Seven vendors accepted our invitation: Agilent Technologies, Brix Networks, ClearSight Networks, Fluke Networks, Touchstone Technologies, Viola Networks and WildPackets.

ClearSight's Analyzer garnered the Network World Clear Choice award for its extreme ease of use and its capability to analyze a range of VoIP protocols. Fluke's OptiView package made a strong second-place showing by capturing a substantial amount of information on the VoIP calls. However, it was a bit more tedious to use. There was a near-three-way tie for third place between Agilent, Touchstone and WildPackets, all of which provided much more complete analysis of VoIP traffic in the Session Initiation Protocol (SIP ) environment than proprietary environments.

Protocols matter

We found - and users also need to keep in mind - that VoIP analysis tools are oriented toward particular VoIP protocol environments. Interpreting different call-control-protocol sequences is difficult because the messages vary considerably with the particular protocol used.

We tested each package in four different VoIP environments over a two-month period (see "How we did it" ). Using this methodology, we tested the packages against three proprietary protocols and with two SIP-based implementations.

The tools tested dramatically differ in their abilities to monitor and track SIP standards-based VoIP activity compared to how they work in proprietary protocol environments. Only two of the products, ClearSight's Analyzer and Fluke's OptiView package, did a good job tracking all VoIP activity in both standard-based SIP and proprietary-protocol VoIP environments.

But other products tested - such as Agilent's combination of Distributed Network Analyzer MX (DNA MX) probe and Telephony Network Analyzer (TNA) software and WildPackets' EtherPeek VX - still can view parts of VoIP phone traffic in different protocol environments. This is because actual VoIP conversations follow a fairly standard format across protocol environments. They comprise bidirectional Real-Time Transport Protocol (RTP) over User Datagram Protocol (UDP ) streams, which are fairly easy to spot and decipher using tools that recognize RTP streams even if the IP PBX uses a proprietary signaling protocol.

Plugging in

The tools we tested mostly are specialty PC-based software applications. Many are add-ons to the vendors' network data analyzer, which provide the ability to recognize and process IP-telephony call control and VoIP conversations.

Long-time test-and-monitor vendor Agilent addresses VoIP monitoring through Real-Time Transport Control Protocol and RTP monitor applications that integrate with its popular Network Analyzer package. Its VoIP analysis package can be based on a laptop, run off a mirrored switch port or run on a probe appliance inserted in-line in key backbone network segments. We tested Agilent's 100M bit/sec capacity DNA MX probe that can fit with almost any network interface type, handle Gigabit links at wire speed and be accessed remotely from anywhere on the network. We ran the TNA software on a separate PC that communicated with the DNA MX over the network.

We ran ClearSight's software-only Analyzer on a Windows XP laptop. It sniffs passing traffic and captures all the packets traveling on the network, then analyzes them for VoIP traffic and associates the VoIP packets with the proper conversation. The network analyst's laptop usually is situated on a mirrored switch port to watch traffic that's copied and redirected from key traffic links.

Fluke's OptiView package can run on a PC or on a special probe designed for in-line insertion on a backbone link and is based on packet-sniffing data capture and analysis. We tested it with a Gigabit-capacity in-line probe that cost about $21,800. We also ran it on a Windows 2000 laptop via a mirrored switch port. The VoIP analysis software was the same in both configurations, but the separate-probe approach is better suited to multi-site distributed environments.

Another implementation based on packet sniffing is Touchstone's software-only product, WinEyeQ, which we ran on a Win 2000 PC as it watched passing traffic on a mirrored switch port. WinEyeQ seems to be more focused on VoIP traffic than its packet-sniffing competitors because all of the screens in Touchstone's product were specifically designed for VoIP analysis.

WildPackets' EtherPeek VX is also Windows-based software and is a packet-sniffing monitor tool, which we ran on a Win 2000 PC, on a mirrored-switch-port connection.

Brix's BrixMon relies on hardware probes called verifiers that generate simulated VoIP traffic based on canned tests that you can tailor to your network. This test traffic is sent between verifiers. Brix says the system can monitor and report on real VoIP traffic, but we found it difficult to get this feature to work properly in the different scenarios.

Viola's NetAlly is a software-only package that also issues simulated streams of VoIP traffic sent between its distributed PC clients.

With simulated traffic there is no direct observation or monitoring of real user's VoIP traffic, therefore both BrixMon and NetAlly are indifferent to VoIP protocols. This can be useful if you plan to use the tool in a pre-deployment phase of an IP PBX system to assess if the current network infrastructure can perform adequately for VoIP traffic. But then, when real VoIP traffic is implemented on the network, you don't get the same level of VoIP-level protocol detail and real traffic analysis that the other packages provide.

In this category, our top marks went to Agilent and Fluke in large part because of the additional deployment topologies and options they support. The BrixMon system was notably much more difficult to deploy and get working properly.