First impression on unpacking the Q702 test unit was the solid feel and clean, minimalist styling.
INTEROP - Massive VOIP tests reveal strengths, weaknesses
- — 05 May, 2006 08:45
The good news is that VOIP equipment among multiple vendors is finally pretty interoperable; the bad news is that there are still lots of potholes that can ruin VOIP implementation.
That's a broad view of results from Interop Labs tests of VOIP gear run on the show's test network and presented at the Lab's Interop exhibit.
Volunteers set up five model enterprise networks fitted with VOIP equipment, network firewalls, application firewalls, Wi-Fi access points and VPNs and ran VOIP calls through them using a variety of VOIP phones -- softphones, hard phones, Wi-Fi handsets and PDAs. The tests involved equipment from two dozen vendors.
The calls ran over a combination of the public phone network and the Internet using a service provider that supports SIP signaling, and then testers tried to disrupt the calls and measure the results.
Some of the results:
-- Network address translation (NAT), the masking of private IP addresses from public view, can break VOIP by making it impossible to set up SIP-based calls over the Internet to devices with private IP addresses. The best option the Labs found was to get rid of NAT if possible. If not, get a SIP proxy server that can ignore the public addresses on VOIP packets and find the actual addresses within.
An alternative is to install a server outside the NAT device -- usually a firewall -- that keeps track of where packets come from and shepherds them through the NAT.
-- Use QoS on Wi-Fi networks. While the Labs didn't quantify the difference, testers say the improvement in quality jumped dramatically to their ears when QoS was turned on. "It was noticeable even on non-busy networks," says Jed Daniels, one of the volunteer testers, who said the biggest improvement was it cut delay.
-- VPNs don't disrupt VOIP. This came as a surprise to testers, who expected that encapsulating real-time UDP voice packets inside TCP packets would cause delay, but that wasn't the case. With IPSec and SSL VPNs there was no significant degradation, Daniels says, although the quality over SSL VPNs was better.