Tips from the trenches on VoIP

Based on our testing, here's how to prepare your network for VoIP.

1 2 Page 2
Page 2 of 2

VLANs and QoS: Gotta have it

A successful VoIP deployment requires VLAN and QoS capabilities at every point on the network, necessitating more intelligence in closet switches than ever before. In a best-practices scenario, all voice traffic should be isolated on a Layer 2 VLAN dedicated to voice and signaling traffic.

Switches also should support Layer 3-based QoS features, such as TOS or Diff-Serv, for prioritizing traffic through multiple subnets. This is particularly important at aggregation points within the network. QoS will ensure that the VoIP traffic gets top billing at congestion points and help to maintain low latency and jitter. Setting the exact QoS value for TOS or Diff-Serv would be handled on a case-by-case basis and would depend on what the network looks like and what other traffic might need to be prioritized.

But prepping for voice-specific VLANs and QoS capabilities doesn't stop at your network switches. IP phone support for 802.1p/Q VLAN tagging, or the ability to "tag" packets coming out of the phone that defines membership in a particular VLAN, also is necessary. Phones should come with the ability to set TOS or Diff-Serv priority bits within the packets' IP headers.

The new breeds of IP phones enable "one-wire-to-the-cube" installations, supporting two-port mini-switches on the backs of the phones. The Ethernet connection from the LAN attaches to one of these switch ports. The other connects to the PC, positioning the phone directly inline between the PC and the surrounding LAN. Both data and voice, then, can access the network over the same 100M bit/sec pipe.

To prevent PC traffic from overwhelming voice conversations, most phones include some kind of traffic-shaping mechanism in the switch. For this reason, phones with hubs in the back -- rather than switches -- are less desirable. Hubs operate at only half-duplex, minimizing bandwidth to the cube, and they cannot implement QoS.

Inline power over Ethernet: Gotta get it

In a VoIP environment, you can look to good old Ethernet to provide an important new functionality over and above a data link -- delivering power inline to IP phones. There are essentially two options for delivering power over Ethernet.

First is to purchase Ethernet switches that deliver data and power. Avaya and Cisco are examples of vendors that sell Ethernet switches with inline power. (See our inline power primer.)

The second is to provide midspan power insertion devices called "power hubs." Most power hubs are OEMed from the Israeli firm PowerDsine. Ethernet cable runs from the cubicles are connected to the power hubs, which are patched to the Ethernet switch. So a 48-port power hub, for instance, will power 24 IP phones.

Most IP phone interfaces are "power aware" to receive power via the Ethernet connection. Power is sent over the unused pairs of a Cat 5 cable or over the same pairs (phantom power) used for data, in which case the Ethernet power sources employ a detection algorithm to determine whether to send power to a connected interface.

Those few IP phones today that do not have power-aware Ethernet interfaces can use a power hub and maintain the one wire to the desktop. They usually ship with special line splitters, or "pig tails." These line splitters have a female RJ-45 connector on one end to receive the powered Ethernet, branching out into two prongs. One is a DC power connector for the phone, the other is a male RJ-45 Ethernet connection to the phone. Power is effectively "peeled off" the incoming Ethernet connection and sent to the phone's DC power jack. The data goes to the Ethernet port.

Determining whether powered switches or mid-span insertion is better is a matter of cost. If you need more switches, or those you have need replacing, you might as well go with powered switches.

Because power failure to your Ethernet switches will leave your company unable to communicate via voice or data, back-up power for your Ethernet switches should be closely examined.

Legacy digital phones sets are terminated at the PBXs, so UPSs for the PBX protect the phones and the PBX. IP station connections terminate at the Ethernet switches. If power to the switch is lost, loss of both voice and data could occur. Upgrading UPSs to prevent longer blackouts also might become necessary. The ratio of necessary switches to UPSs depends on the size of the UPS. Most major UPS vendors provide resources to determine which model UPS a user should get based on the load and the duration of coverage.

Security: Gotta foil eavesdroppers

Security issues have always been a standard refrain for VoIP detractors, and with good cause. Lest we forget, VoIP is data, with all its vulnerabilities. But, while security at the network's edge is always the prevalent concern, we also warn that you have to look inside for security concerns with a VoIP deployment.

Treat your IP-based PBX with at least the same diligence as you would any mission-critical server. Defining VLANs and enabling security features on the switch that map specific media access control addresses to specific ports is a good start. In large implementations, install a dedicated internal firewall to protect the PBX.

Perhaps the most dreaded form of deviant behavior facilitated by a VoIP platform is eavesdropping. TDM-based PBXs sit on physical isolated networks, and they use highly proprietary digital signaling. While conversations can be tapped and recorded, both require physical access to the PBX or physically splicing phone lines.

With VoIP, off-the-shelf packet sniffers can capture conversations and not only replay them, but also store and distribute them as electronic files. VoIP equipment vendors are beginning to add security features to encrypt media streams. For example, on its S8700 Media Server and G600 Media Gateway, Avaya has added Media Encryption on an active IP call. When nonauthenticated users attempt to intercept the packets, they hear white noise when replayed.

While it obviates the economies converged networks can produce, some IT administrators take security concerns so far as to run parallel physical networks for voice and data rather than run both across the same links. Customers with the budget for it can achieve the best of all worlds from a security point of view. But this option is expensive, and tight security can be achieved with a well-conceived deployment.

The edge: Gotta get around NAT

An important fundamental aspect of VoIP is that there are two different data paths: the signaling path and the voice path. When a PBX-attached IP phone goes off-hook, it signals the start of a call-setup process. In most IP PBX systems, the back-end call server will set up, tear down and peripherally monitor call states. But the packetized voice conversation occurs directly between the endpoints (peer-to-peer) without further back-end intervention.

This characteristic makes network address translation (NAT) a troublesome proposition because signaling comes from one network node (the call server), and the media stream comes from another (IP phone). This problem is compounded because NAT functions at Layer 3. Peer-to-peer voice communications occur via the Real-Time Protocol (RTP), which embeds the source and destination IP addressing in the Layer 7 headers, rendering the return data address inaccessible to any NAT engine.

Stateful firewalls are equally problematic. Outbound VoIP communications create "pinholes" through the firewall to allow outbound voice communications. However, inbound voice data will attempt to enter the network using different socket information than the signaling data used, and the firewall will consequently block the RTP stream. Furthermore, creating pinholes for all the possible port ranges negotiated by the endpoints defeats the firewall's purpose.

One possible solution is a VoIP-aware firewall, which adds application-proxy functionality to base firewall products that enable dynamic opening and closing of firewall ports on a connection-by-connection basis. This functionality can be added via upgrades to an existing firewall product, or via third-party hardware that resides logically alongside the firewall, such as those offered by Jasomi Networks and Kagoor Networks.

You also can take a VPN route to support VoIP between sites or for remote access because VPNs circumvent NAT and firewall issues by tunneling. Site-to-site VPN links are becoming more common. If you're considering one, using it to link your PBX network should be added to the plus column. However, the gotchas with VPNs that you should beware of include bandwidth and latency. The overhead and delay encryption adds should be taken into account for optimal planning.

Planning makes perfect

While VoIP can ride over the highways as our data currently does, it is a new application with new rules. Deciding on the right VoIP solution is just the beginning; deploying it on the network properly is the real task.

Knowing your network, ensuring the quality of your voice traffic, making sure your network and personnel infrastructures are up to the task and properly protecting your IP PBX will help your deployment be successful.

Learn more about this topic

Percy is a technology analyst and Hommer is manager of consulting services for Miercom, a network consultancy in Princeton Junction, N.J. They can be reached at and

NW Test Alliance

Global Test Alliance

Percy and Hommer are also members of the Network World Global Test Alliance, a cooperative of the premier reviewers in the network industry, each bringing to bear years of practical experience on every review. For more Test Alliance information, including what it takes to become a member, go to

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2003 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2