VoIP team ventures into new terrain

What happens when devices try to work through security devices and across wireless LANs?

By now, basic interoperability is generally a given in multivendor VoIP settings. What happens, however, when VoIP devices go to work in decidedly unfriendly environments, such as through security devices and across wireless LANs?

Results of the testing completed by the InteropLabs VoIP team suggest new QoS mechanisms can work effectively, but security remains as tricky as ever to get right. Even though it's not a security mechanism, network address translation (NAT) also proved especially troublesome.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

By now, basic interoperability is generally a given in multivendor VoIP settings. What happens, however, when VoIP devices go to work in decidedly unfriendly environments, such as through security devices and across wireless LANs?

Click to see: InteropLabs logo

Results of the testing completed by the InteropLabs VoIP team suggest new QoS mechanisms can work effectively, but security remains as tricky as ever to get right. Even though it's not a security mechanism, network address translation (NAT) also proved especially troublesome.

The team built a complex test bed connecting the VoIP phones of five enterprises across a vast armory of firewalls, IPSec and SSL VPN concentrators, and intrusion-detection systems.

The security-gear suppliers included Aventail, BorderWare, Check Point, Cisco, Juniper and Nokia. Some vendors shipped multiple security devices: For example, Juniper supplied a firewall, an intrusion-prevention system (IPS), two IPSec VPN concentrators - and three engineers to get everything working.

In addition to security boxes at the edge of each enterprise's network, the security apparatus included IPSec and SSL VPN clients for remote users. Corporate network managers planning VoIP rollouts will probably deploy similar setups, configuring IP phones and security devices and drop-shipping them to remote users.

All this equipment ensured tight security - in some cases, a little too tight. For example, BorderWare's SIPAssure offered detailed control over Session Initiation Protocol (SIP) but didn't provide the access controls needed in a general-purpose firewall.

The team redesigned the network by placing this device alongside another firewalls. The BorderWare box became a VoIP session border controller alongside another BorderWare firewall.

The test bed also comprised numerous wireless LAN (WLAN) switches, access points and end-stations, all using the new 802.11e standards for QoS enforcement. Phones in this year's event were equally diverse, ranging from softphones on PC and Mac clients to old analog handsets with SIP adapters and Wi-Fi and Ethernet SIP handsets.

Unlike past years, where the focus was on interoperability among multiple vendors' SIP proxies, the InteropLabs team this year standardized on the open source Asterisk SIP proxy for four of the enterprises. At the fifth were two proxies: an Asterisk box and the SpectraLink SIP proxy, which SpectraLink's new SIP-enabled handsets require. In general, however, the focus wasn't on the SIP proxy used but on the diversity of the equipment around it.

In all, around 20 vendors contributed equipment and engineering resources to the effort, making this among the largest VoIP test beds yet constructed by the InteropLabs team.