Viola Networks' NetAlly 5.0.19A
Voila Networks' NetAlly 5.0.19A software provides in-depth reports of network metrics such as latency, packet loss, jitter and throughput, which help you keep voice-over-IP performance at a high level.
May 17, 2006
Smart enterprise network managers know they should determine the impact of a voice-over-IP system--i.e. responsiveness and reliability--on existing applications before deployment. Viola Networks' NetAlly 5.0.19A helps network managers do this by letting them analyze in-depth reports on network and VoIP performance using simulated voice traffic and detailed call records from Cisco Systems and Mitel Networks setups. NetAlly then continues assessing VoIP impact, monitoring and troubleshooting the network to ensure applications operate at optimal levels. Although the vendor could fine-tune its discovery and reporting features, the product is otherwise well-suited to support VoIP deployments.
Data Collection
Unlike Apparent Networks' AppareNet Professional Voice app, NetAlly works with passive data stored in the call detail and management records of major IP PBX switches. This data provides information on delay, loss and other troubles between calls. That info, plus the product's traffic agents, help deliver a well-rounded picture of performance.Competitors Brix Networks, Empirix and Mercury Interactive all offer VoIP test suites that run or monitor network transactions, probing for conditions that could affect a VoIP call, but these products don't integrate with passive data. NetIQ's Vivinet Assessor and AppManager for VoIP offer capabilities similar to NetAlly's, but in separate products.
NetAlly uniquely obtains difficult-to-get network traffic data by distributing its NetRegard traffic agent (TA), which uses JavaScript within a Web browser, behind firewalls. The product uses a Web server to install TAs on remote devices; these can be uninstalled using the software's Test Center management server or manually from the endpoint.
NetAlly Suite
NetAlly Test Set-upClick to enlarge in another window |
NetAlly uses distributed Linux (Red Hat 9 and 10) and Windows TAs, which are Java-based tools that install as services under Windows or as daemons on Unix, as well as the Web-based NetRegard, to simulate VoIP traffic from the Test Center. The TAs support VoIP call signaling, such as SIP, emulate the output of an IP phone in various codecs during testing, generating traffic using one-way VoIP or RTP (Real-Time Transport Protocol) streams between test locations. Often just one party in the call is having a problem, and NetAlly's approach avoids having to follow a two-way conversation along the line to find the troublesome RTP stream. You could simulate SIP and H.323 calls, too, if you assign a SIP server and URI (Uniform Resource Identifier) to the TAs or an H.323 gatekeeper to the test configuration.The Test Center is managed with an independent GUI that requires Windows, the environment supported by NetAlly's Report Builder. A watchdog service manages the TAs, and Winpcap tracks network stats.
In tests simulating adding an IP PBX and VoIP phones to an enterprise network consisting of a central, branch, and home office (see diagram), NetAlly predicted how well the test network would perform with VoIP. Using the Syracuse University Real-World Labs® and a home office as a test bed and being careful not to saturate the simulated links over the test cable network with calls, the outcome was not so good.
With the latency (between 300 and 500 ms), packet loss (up to 1 percent), and out-of-order packets (random) configured to my Mean Opinion Score (MOS) specs, overall scores did not meet expectations for streams between the branch and central office. I manually confirmed NetAlly's findings, having installed a switch and IP phones in the simulated branch and central offices, by calling myself in the branch office from the central office. Indeed, quality was terrible, a good indicator of overall network degradation.
Once problems are identified, NetAlly's troubleshooting tool can be used to perform codec-specific diagnostic routines between endpoints. It identifies duplex mismatches, problems with QoS precedence, and route-quality results.
An experiment using Cisco CDR (Call Detail Record) and CMR (Call Management Record) imported into a database by a NetAlly engineer provided a view into detailed records between two IP phones. These passive tests are reported with active network tests to provide a complete VoIP assessment.Once latency, loss and out-of-order packets from the T1 and T3 lines were reduced, the results exceeded expectations. Further confirmation that NetAlly had done its job came from manual tests, showing call quality to be excellent.
One quibble is that NetAlly reported average, overall scores in MOS, packet delay, packet loss, and so on, and not minimum and maximum scores for streams along with the averages. Many times, the average score did not indicate the calls that dropped below expectations. Finding out required drilling down into reports that initially gave a green light from the reporting mechanism.
Going Forward
NetAlly makes it easy to keep measuring performance after implementation, with reports available over e-mail, SNMP and the Web. You can get baselines from the tests you've run, which you can use to set schedules for other tests, configure thresholds, and set notifications if those thresholds are exceeded. Active network data on VoIP and passive data for IP phones made for reports that provided graphical views of call data over configurable periods of time, with the ability to view details on individual streams. The reports offered a click-down feature that lets you view a problem's details with specific sessions and streams.
NetAlly's discovery tool, however, is limited to SNMP-based information on routers and any devices directly connected to the router's egress ports. In the test network, intermediate switches and endpoints, as well as the Shunra Virtual Enterprise used to simulate leased lines and add network latency, packet loss, and out-of-order packets to the link between offices, went undiscovered. You could easily enter the items that the discovery tool does not find, or import them from an NMS (Network Management System) using an XML-based file. Since the future of VoIP will rely on SIP, NetAlly will need to increase the functionality of its discovery tool to ferret out SIP end points and interrogate them with device-specific MIBs.The company plans on fixing this limitation, and in its next major release also expects to integrate with call detail records from Nortel VoIP systems, as well as improve discovery and include maximum and minimum call details in the results of tests. That will give NetAlly increased relevance to enterprise VoIP systems from planning to production.
Sean Doherty is a contributing editor to Network Computing. Write to him at [email protected].
You May Also Like