SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
Prepare your Network for VoIP
Discover how a few key design and connection changes prior to installing your first IP phone can result in a smooth-talking VoIP system.
July 2, 2004
11 Min Read
Your switches and routers may have the necessary VoIP features, but you still must inventory software code versions and check that you have the most recent iterations. Expect to upgrade some software, because not all equipment comes VoIP-ready with bug-free versions of QoS. But don't get too hung up on QoS--think of it as an insurance policy should you exceed the bandwidth.
Many VoIP vendors offer preinstallation assessment services and will recommend changes. This kind of help will save you some work and minimize finger-pointing if problems occur later on.
Reassess your network regularly, too. New applications are added, people and departments move around and the network gets reconfigured, all of which can change traffic patterns. Monitoring your network's capacity and performance helps you avoid problems. In addition, VoIP monitoring tools can assist you in reassessing how well your network supports VoIP (see "VoIP Monitoring Tools,").
Back to Basics
Most VoIP vendors say duplexity mismatches--full duplex on one end of an Ethernet connection and half duplex on the other--are the biggest cause of VoIP performance problems. Check the duplexity settings of your connections, and use your network-management systems to check switch and router settings.Start with the backbone connections, because these have a huge impact on VoIP performance. Manually set both ends of every backbone connection to full duplex. If you have both ends set to autonegotiate, you can get clues about duplexity from the error counters. If one end experiences collisions, for example, it probably has been set for half duplex. If the opposite end has lots of CRC (cyclic redundancy check) errors and no collisions, it likely has been set for full duplex. A quick look at the configurations of most devices, especially switches and routers, will tell you their duplexity settings.
It's best to test PC-to-switch and phone-to-switch connections using autonegotiate if you have standardized on NICs and wiring-closet switches. If autonegotiate gets the highest speed available with full duplex, use it. If you want VoIP phones with built-in switches, choose ones that let you change duplexity settings. Also, check the connections from the phone's built-in switch to the PC and the edge switch.
To ensure that voice packets get priority treatment and experience minimal packet loss and delay, turn on Layer 2 (802.1p) and Layer 3 (DiffServ) QoS throughout your network. Your VoIP equipment, including phones and media gateways, should support QoS. Keep in mind that Layer 2 QoS settings are lost when the router rebuilds the frame. Most routers can translate the appropriate Layer 2 QoS information using Layer 3 QoS before they transmit a packet--make sure your router does this at wire speed.
If you're plugging a desktop into your VoIP phone, be sure your PC doesn't overwhelm your connection with data. This won't be a problem if the phone's built-in switch and the wiring-closet switch support 802.1p. If they don't, a data transfer may interrupt your voice conversation.
Bottom line: Your QoS policy should give all VoIP traffic first priority. The only exceptions are routing updates and other control packets.The legacy phone network is well-known for its five-nines (99.999 percent) availability. A VoIP application, though, will be only as reliable as the data network supporting it.
You can increase your data network's reliability with redundancy, mainly at the network core, where it affects the largest number of users. It also helps to add redundancy where your VoIP servers are connected. At a minimum, you should have dual power supplies, dual CPU cards and mirrored drives at both the core and the edge of your network.
You should also connect redundant core routers to your building switches with redundant connections (read how various vendors add redundancy). And to avoid downtime, make sure you have spares for all critical components. With redundant equipment set up in high-availability mode, spares are put into production within seconds (whereas it might take you hours to install new equipment).
Test high-availability schemes in your lab before your rollout. In some cases, a backup CPU card in a core router will need several minutes to reboot and load routing tables after the primary card fails. Some routers handle this process more quickly.
Of course, adding redundancy adds cost. If you're having trouble getting funding for this, help management understand the implications. Tell them how long the network could be down when a replacement or repair is needed. Let the management team have input into determining how much downtime is acceptable.Where possible, use failover standards such as the IETF's VRRP (Virtual Router Redundancy Protocol) and the IEEE's 802.3ad link-aggregation protocol to connect redundant equipment to the edge. Interoperability won't be a problem with redundant connections linking two core routers, for example, because they're from the same vendor. But standards are important at the connection from the core to the edge, because you're bound to have equipment from different vendors throughout your network. A vendor-proprietary failover protocol could be best if the failover time is improved, but weigh the trade-offs of using vendor-proprietary schemes versus standards.
You've Got the Power
VoIP requires backup power for your LAN equipment, your IP phones and your VoIP servers. You probably have backup power in your data center. If so, it's just a matter of upgrading the KVAs (kilo volt-amps).
Backup power is necessary in your wiring closets for phones and switches. You can power your phones from the closet using the IEEE 802.3af Power over Ethernet standard, which uses Category 5 or better Ethernet wiring. Even a 15-minute backup will get you through a few brownouts or a short outage. Remember, though, that any outage will cause your switches and phones to reboot, possibly extending the outage for several minutes and damaging equipment. It's a good idea to have battery-powered backup in the wiring closets. (See "You've Got the Power,", for more on PoE.)
Your VoIP system should be protected, especially from Internet access--VoIP phones are computers and, therefore, can be hacked. You can protect the phones by segregating them to their own VLAN using private addresses so that only the VLAN has access to the VoIP servers.Obviously, you want to deny access to the phones and servers from the Internet. Aside from the risk of denial-of-service attacks and possible break-ins, there's also the danger of toll fraud--someone hijacking your phone and using it to make calls. You'll also want to filter access within your internal network. Allow access to only those ports that are necessary, and make sure you have authentication and VPNs in place for telecommuters who want to use the corporate phone system from home.
Finally, to load IP configurations onto the VoIP phones, use DHCP. It also can be used to tell the phones where to download new software and configurations via TFTP (Trivial FTP). If the phones reboot and cannot reach a DHCP server, they will go down, so the DHCP server's reliability and availability are important.
It's easy to get caught up in the technology, but processes are just as important. Before you make a change to your network--like adding a new feature or changing a configuration--make sure you understand its impact on your VoIP system. Keep thorough, updated documentation regarding your data network and the VoIP components so you can use that information for troubleshooting. Then your voice traffic will flow smoothly over your network.
Peter Morrissey is a full-time faculty member of Syracuse University's School of Information Studies, and a contributing editor and columnist for Network Computing. Write to him at [email protected].
VoIP Monitoring Tools
Agilent, www.agilent.com
Brix, www.brixnet.com
Empirix, www.empirix.com
Shunra, www.shunra.com
Spirent, www.spirentcom.comTo ensure your network voice is loud and clear, you need to know the three worst enemies of VoIP: delay, jitter and packet loss.
Delay is the time it takes for data to get from Point A to Point B on a network. VoIP is sensitive to delay because human conversations occur in real time; call quality degrades if a delay affects the rhythm of the conversation.
The ITU G.114 recommends a maximum one-way delay of 150 ms, or 300 ms round-trip. It's best, however, to keep the round-trip delay to no more than 250 ms because at that point conversation quality declines. A VoIP phone typically adds 60 ms of delay, but this figure varies by vendor and the size of the jitter buffer (see "Codecs: The Bandwidth + Delay Equation,").
You can prevent the delay from overloaded router queues or an oversubscribed network by designing your architecture with good QoS and enough bandwidth. Delay on slower WAN circuits and long-distance circuits can be an issue, especially with overseas connections. Although you can avoid some delay, you can't eradicate it. Delay typically isn't a LAN issue (assuming the LAN was designed properly), but a lower-speed WAN circuit can add delay.
Distance alone on a WAN circuit will increase delay. The speed of light adds at least 5 ms of delay for every 1,000 miles of fiber. So a coast-to-coast connection of 3,000 miles will have a round-trip delay of 30 ms, which shouldn't be a problem. But the delay will be noticeable over international distances, VPNs or an overloaded network.Delay also can magnify echo--a concern even on conventional TDM (Time-Division Multiplexing) networks. VoIP phones have built-in echo cancellation, but as delay is added between the original speech and the caller, the echo becomes more obvious. And echo-cancellation algorithms will have a harder time filtering out echo. Ask your VoIP vendor about its echo-cancellation features. Different vendors use different algorithms, and some work better than others.
Jitter is the variance in delay. It's bad news for the same reason as delay is: Voice is real time. When some voice packets arrive with little delay followed by additional voice packets with greater delay, parts of the conversation on the receiving end will become uneven. Jitter buffers compensate somewhat by buffering packets and controlling how they are played out, but if the jitter buffer is too large, it can generate too much delay. Codecs also may compensate by repeating the last portions of speech.
Packet loss can plague VoIP, too, but not as dramatically as you might think. When voice is transmitted over an IP network, the voice application typically uses the RTP protocol running atop UDP (User Datagram Protocol), which doesn't retransmit lost packets. Retransmitting voice packets doesn't make sense because voice is real time, and speech is broken up into such small chunks that losing a few is barely noticeable.
Some VoIP vendors say their systems can handle up to 10 percent packet loss. In general, it's best to keep packet loss in the 1 percent to 2 percent range on the WAN and even less on your LAN. If you rely on DTMF tones, you can't afford any packet loss--one dropped packet could cause a customer to get lost in an automated attendant tree. In that case, you're better off using TDM trunking on the portions of the network that support an automated attendant. Customers dialing into your phone system from the PSTN could easily be kept on TDM connections, since they are coming in over TDM anyway.
Two different codecs are commonly used for VoIP. When planning your network, you need to know which codecs and related features are available from your VoIP vendor. If you are only running VoIP on the LAN, G.711 (85 Kbps) is best because LAN bandwidth is so inexpensive. On the WAN, G.729 makes more sense because it uses less than half the bandwidth. The catch is that G.729 adds more delay. In the chart below, we've assumed a 20-ms packetization delay at each end and a receive jitter bugger of 20 ms.Some vendors implement VAD (Voice Activity Detection) and silence suppression, which transmits packets only when users are talking. This reduces bandwidth utilization even further. However, speech may get clipped as VAD or the suppression switches on and off.
Beware that setting up voice calls generates additional traffic, as do control packets for RTP (Real-time Transport Protocol) that track the statistics. Integrating your VoIP with software applications, too, adds traffic overhead, so test the applications on your network. Make sure you have enough bandwidth to support the maximum number of simultaneous calls that will occur during peak calling times, as well as the peak traffic utilization for your existing applications.So you're ready for the increased productivity and cost savings of voice over IP. But to reap the greatest benefit, you can't just drop it in and start talking. IP voice needs the right network foundation so your voice calls don't suffer from the deadly sins of VoIP--delay, jitter, packet loss and overall unreliability. Before you install the first IP phone, make sure your network devices support Layer 2 and Layer 3 QoS (Quality of Service) and virtual LANs, and that your existing bandwidth can handle voice traffic. You'll probably need to upgrade your device software, and perhaps your hardware, too.
Check all your network connections to ensure you don't have any mismatches of full duplex on one end and half duplex on the other end of an Ethernet connection. And remember that redundancy, both of core devices and power, is crucial to a smooth IP voice implementation. Securing voice means putting your VoIP phones on their own VLAN using private addresses, plus minimizing and monitoring access to your internal network.
And even after your VoIP system is up and running, keeping updated documentation of your data network and VoIP components will help ensure IP voice quality.0
You May Also Like
More Insights
