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.
Miercom offers new special report on IP PBXs
Readers respond: Give us our telephony features
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.