Keeping the videoconference moving

Radvision (Fair Lawn, NJ, www.radvision.com) manufactures videoconferencing systems. Testing of videoconferencing systems starts with connectivity. The system must work with Microsoft Windows PCs and connect to conferencing equipment such as phones and room systems. Radvision desktop CTO David Bundy explained that engineers test the company’s products with audio and video endpoints. Thus, the lab is equipped with a wide range of audio and video sources and displays. “Even though there are industry standards,” he explained, “companies interpret them differently. Testing lets us find those differences.”

To test connectivity and interoperability, Radvision engineers start by connecting audio/video equipment to PCs running its videoconferencing server and client software. An MCU provides clients and servers with access to a conference (see figure). Testing starts with a “clean” network where engineers can verify that the system can add calls to a conference. They use the company’s testing software to verify proper call setups and teardowns using H.323 and session-initiation protocol (SIP) protocols.

Test equipment connects to a live network to monitor protocols for videoconferencing equipment.

After verifying connectivity, the engineers add impairments to stress their videoconferencing hardware and software. Network simulators add packet jitter and latency to the test network. The engineers use bandwidth limitation to verify that their systems will drop the bandwidth of connections as needed. For example, a 256-kbps connection might drop to 64 kbps as network bandwidth drops.

Radvision engineers must verify that conferencing software can traverse firewalls. To do that, they verify that the software runs like a Web-based application using HTTP.

The final test measures audio and video quality, which engineers measure with live participants. While Radvision will use voice-quality testers, the company mostly relies on live participants.

“Even with standards and emulation tools,” said Bundy, “you need to test with the actual third-party endpoints for audio and video conferencing. Network stress tools and analysis tools are a must to emulate and evaluate performance in real networks, but you must also capture real network conditions and emulate them with your tools.”