Tips from the trenches on VoIP

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

In a voice-over-IP deployment, the hotspots aren’t as obvious as you might think. The clear-cut decisions center on VoIP-specific products such as IP phones, IP PBXs and voice gateways, but weaknesses in your data network will become magnified when you introduce VoIP.

The first question to ask in order to avoid some postdeployment surprises is: In what kind of shape is my existing network? Real-time voice traffic will be affected by any bottleneck on the network. A delay of 1 second in retrieving a data file from a server because of congestion might be barely noticeable to the user, but add just 50 millisec of delay on a phone call and it’s the difference between high-quality and very poor-quality voice communications.

Readers respond: Give us our telephony features

Emergency 911

Graphic: Prepping your data net for voice (PDF)

Before deploying any VoIP gear, you must scrutinize your network with an audit that includes three primary considerations:

•  Utilization and network statistics. Maximum, minimum and average metrics for bandwidth consumption, latency, jitter and packet loss should be included in your audit.

In the case of bandwidth utilization, the hotspot for potential bottlenecks lies in the interswitch links that make up your backbone. Maximum bandwidth utilization should be dictated by failover considerations, says Joe Tomasello, of Foundry Networks.

“Uplinks should always be deployed redundantly, at least,” Tomasello says. “If one link fails, the other link should be able to handle the load for both links. Therefore, utilization on a trunked Ethernet uplink, for example, should never exceed 50%.”

Latency, jitter and packet loss that would be detrimental to business-quality voice are rare occurrences on today’s LANs. Where they do exist, they are usually the result of antiquated equipment (such as hubs, 10M bit/sec Ethernet switches or switches with low memory capacities) or silly mistakes. Examples would be a switch with its autonegotiation algorithm disabled, forcing all switch ports to default to 10M bit/sec half-duplex communications; or a swath of Ethernet cable that’s a lot longer than 328 feet, the maximum supported Category 5 cable length for Ethernet.

Check that your network latencies don’t exceed 100 millisec, and maximum jitter should never be more than 40 millisec. Packet loss should be zero, but the rule of thumb for tolerable voice quality is less than 1%.

•  Review of infrastructure elements. The gear that powers the network should be reviewed for necessary feature support and correct configurations. Ethernet switches that will be touched by VoIP traffic should support virtual LANs. This will allow segmentation and isolation of your voice traffic across the data network.

IP-based quality of service (QoS) — such as type of service (TOS) or Differentiated Services (Diff-Serv) — should be supported. In a large VoIP deployment, this allows prioritization of packetized voice over more delay-tolerant traffic that must travel multiple subnets in a routed environment. A few IP PBX systems also require multicast support.

Next, these features should be reviewed to ensure that they’re turned on, and to ascertain whether any configurations could pose problems. For example, if the Spanning Tree Protocol is enabled, changes in the Layer 2 topology could cause outages of up to 60 seconds while the updates are made to each switch’s database.

•  Estimating bandwidth requirements. Most value-added resellers and integrators have tools to help you ascertain how much voice traffic is currently carried by your voice network, both incoming and outgoing, on a per-station basis. If you prefer to arm yourself with your own calculations, there are two places to go for guidance. The first is to your existing PBX system. Most have reporting capabilities that yield utilization information. Some are easier to get at than others, but the utilization information you need — both station-to-station and station-to-trunk — should be there. The second is www.erlang.com, a Web site full of calculators and tutorials on voice traffic utilization.

When translating voice-utilization statistics into bandwidth requirements, we use the following rules of thumb for base, worst-case LAN bandwidth calculations. First, go with a G.711 coder/decoder (codec), because it consumes the most bandwidth and provides the best voice quality. For packetization rate — or the amount of voice payload per VoIP packet — assume 20 millisec, the default setting on most IP PBX systems. Using G.711 with a 20-millisec packetization rate, bandwidth utilization rounds up to 88K bit/sec per voice conversation. In calculating a worst-case, busy-hour scenario, assume that one out of every four users will be on the phone simultaneously.

In a 1,000-user IP voice system, multiply 250 (for the number of concurrent conversations) by 88K bit/sec per station for an additional bandwidth requirement of 22M bit/sec on your LAN.

The situation is far more complicated on the WAN.

There’s no single rule of thumb for calculating bandwidth per call over a WAN because consumption varies by which voice coders (vocoder) and WAN protocols are used. Among low bit-rate vocoder options, G.729a is preferable. Repeated tests in our labs confirm this codec delivers the highest voice quality.

Voice Activity Detection (VAD) — also known as Silence Suppression — should be supported for each vocoders on the IP-PBX you select and, for purposes of calculating bandwidth, assume that it is enabled. With VoIP, speech and silence are packetized. To conserve bandwidth, VAD prevents “silence packets” from being transmitted. While the conventional rule of thumb is a 35% savings, our testing has seen bandwidth savings of 50% when VAD is used.

Assume the same 20-millisec packetization rate and, again, a 4-to-1 user-to-channel ratio.

For example, assume the use of frame relay as our WAN protocol, and G.729a vocoder. Plugging in the other variables outlined above, VoIP bandwidth over a frame link — with 35% bandwidth savings using VAD — rounds up to 18K bit/sec per VoIP conversation. So again, with 250 VoIP station users on the phone simultaneously as your worst case, assume you need an additional 4.5M bit/sec of bandwidth on your IP WAN.

One more tip concerning WAN bandwidth is to find out if your router supports RTP header compression. The standard IP/User Datagram Protocol (UDP)/RTP header consumes 40 bytes in a packet. If supported by your router, enabling RTP header compression can reduce the header information to just 2 bytes, yielding an overall bandwidth reduction of up to 50%.

Once you determine how much VoIP data will likely be running across your network, you can focus on the network it will be touching to accommodate it.

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.