VoIP team ventures into new terrain

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.

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.

To NAT or not to NAT

One of the most difficult decisions in this testing demonstration was whether to use NAT. Network architect and team leader Jim Martin – his day job is distinguished architect at Netzwert – initially opposed its use on the grounds that NAT breaks the end-to-end principle of Internet communications and might also introduce interoperability issues. As it turned out, he was right on both counts.

Other team members argued that regardless of whether NAT is good or evil, it’s in widespread use today and should be included in at least part of the test bed. The pro-NAT argument prevailed. Team engineers configured one of the five enterprises to use private net-10 addresses and enabled NAT on a Check Point firewall linking this enterprise to the rest of the test bed.

Enabling NAT proved to be troublesome from the start. Initially, neither inbound nor outbound calls reached their destinations. It took two hours of capturing traffic from various points and then an hourlong discussion in front of a whiteboard to lay out the various issues.

In situations where one side used NAT but the other didn’t, the SIP proxy received traffic but didn’t return it. That’s because SIP proxies get source IP addresses from the SIP header by default, not from the IP header. In this case, NAT translated the source IP address in the IP header, but not in the SIP header. Because the SIP proxy had no route to the source address using NAT, there was no way for the proxy to return traffic (see diagram).

The team set a “nat=yes” parameter on the Asterisk SIP proxy, forcing it to read addresses from IP rather than SIP headers. This solved the first problem of the SIP proxy not being able to send return traffic. It did not help with the second problem: the Check Point firewall not sending return traffic through an IPsec tunnel (this isn’t a knock on Check Point’s firewall; virtually any NAT box would do the same thing).

This second problem proved more intractable than the first. Even though the SIP proxy now processed traffic correctly, the firewall at the enterprise site forwarded VoIP traffic onto the public network instead of placing it inside an IPsec tunnel for routing back to the remote-side caller.

Engineers from Check Point and the InteropLabs team worked to resolve the problem but couldn’t get VoIP working with NAT during the HotStage event. Check Point’s engineers believe the problem is caused by the configuration’s parameters. At press time, Check Point was building a duplicate test bed in its labs, intending to correct the configuration in time to demonstrate VoIP and NAT working together at the show.

Cutting the cord

The WLAN setup comprised a mix of access points and WLAN switches from such vendors as Aruba Wireless Networks, Cisco (in IOS and Linksys versions), Extreme Networks and Symbol. In addition, Check Point and Juniper supplied remote-office devices that combine firewall and VPN concentrator functions with access points.

Hanging off these devices were softphones and wireless handsets from Cisco, CounterPath Solutions, SpectraLink, Unex and UTStarcom.

A key goal of the testing was enabling the Wi-Fi Alliance’s Wi-Fi Multimedia Extensions (WMM) to ensure better treatment for voice traffic. Based on the IEEE’s 802.11e standard, WMM introduces a new twist to QoS enforcement. Instead of simply queuing VoIP packets ahead of others on any given station, it seeks to transmit VoIP packets first from any station, helping to keep delay and jitter to a minimum.

Determining which devices supported WMM wasn’t always intuitive. For example, a consumer-grade Linksys access point offered WMM support out of the box, but new SIP-enabled handsets did not create packets with WMM’s QoS headers. The SpectraLink problem could be caused by the handset or SIP proxy configuration, and at press time team engineers were continuing to examine it.

Another problem in prioritizing VoIP traffic has to do with lining up multiple QoS mechanisms. IP-forwarding devices, such as routers, generally use Layer 3 criteria such as DiffServ code points (DSCP) or IP precedence flags to classify traffic. In contrast, Layer 2 devices, such as wireless switches, use WMM access classes found in the 802.11 header.

Most sites will generally use only one WMM access class for VoIP traffic, but there may well be multiple DSCPs in use. As the team learned, it’s critical that devices with both IP and WLAN capabilities (such as WLAN switches) map all the relevant DSCPs to the appropriate WMM access class.

Yet another issue for WLAN forwarding had to do with virtual LAN (VLAN) tagging. Network designs often use separate VLANs for VoIP traffic, and the InteropLabs VoIP network was no exception. This generally worked fine, with two exceptions: First, a relatively old Symbol switch supported only VLAN IDs between 1 and 31 – too narrow a range to accommodate the VLAN IDs between 100 and 300 in use on the show network. To its credit, Symbol promptly supplied its newer WS5100 switch, which supports any VLAN ID.

Second, the SpectraLink SIP proxy required that handsets reside in the same VLAN and IP subnet as the proxy. The workaround: On each access point, the team allocated two VLANs (each with a unique service set identifier), one for the local subnet and one for the SpectraLink proxy’s subnet. The enterprise-grade WLAN devices all handled this workaround, but some consumer-grade access points (such as a Linksys WRT54GX) don’t support VLANs at all.

Despite the various hurdles encountered, team engineers generally were able to call from any location to any other location (including offsite) by the end of the HotStage testing period. Team engineers and vendors continue to work to resolve the few outstanding issues, and most agreed that VoIP is getting easier to deploy, even in environments that aren’t necessarily VoIP-friendly.

Newman is president of Network Test, an independent engineering services consultancy in Westlake Village, Calif. He can be reached at dnewman@networktest.com.