He Said/He Said: VoIP Engineering Challenges

Over in our News Analysis section, we wrote up a story about a Network Instruments survey in which network engineers expressed concern about their ability to keep VoIP apps up and running. Our technology editors had their own thoughts:...

March 29, 2007

3 Min Read
Network Computing logo

Over in our News Analysis section, we wrote up a story about a Network Instruments survey in which network engineers expressed concern about their ability to keep VoIP apps up and running.Our technology editors had their own thoughts:

Sean Ginevan: I wonder if network engineers are really concerned or if they just don't understand the issue. "Forty-one percent were unsure of their network's ability to handle the extra bandwidth consumption from VoIP calls?" Each G711 VoIP call (according to Cisco) consumes a whole 87.2 Kbps of network bandwidth. Even if you had an entire LAN segment of phones all going (254 simultaneous calls) that would only equal 22 Mbps of traffic on the LAN. The real impact isn't VoIP's impact on the overall network but the overall network's impact on VoIP. That's where proper planning and implementation of QoS comes in--to ensure that traffic is prioritized properly such that non-VoIP traffic doesn't provide a negative effect on VoIP.

Obviously Network Instruments is biased with their numbers; vendors (security vendors are notorious for this) often put out surveys to demonstrate that there's a problem so that people buy more products to address that problem. That said, Network Instrument's overall idea isn't wrong. IT administrators should provide their staff with the tools they need to troubleshoot problems, whether they're looking at VoIP, WLAN or other advanced services. Saying that there's excess latency on the network that's causing problems with VoIP doesn't help if you can't find the source and address the issue. Mike Fratto: Sean's right. It's not so much the impact of VoIP on the network, but the network's impact on VoIP and it is only going to get more difficult. I think there are a number of issues. Engineer unfamiliarity with VoIP can be addressed with education and experience. The second issue is getting real visibility into network performance--you've got to be able to monitor key points throughout the network to make sure that end-to-end performance for VoIP is adequate. And finally, there's the need to apply QoS everywhere, even if that means simply prioritizing UDP over everything else.

Getting that visibility is expensive. You need to have probes everywhere and the monitoring software to make any sense of it. I don't think that using flow-based monitoring will be adequate because all UDP looks the same. It's only getting worse, by the way. I have been doing some performance testing for an upcoming story on the stack changes in TCP/IP and Vista. Vista has some significant improvements over XP and previous Windows versions that have to do with receive side window--Vista is more than twice as fast as XP pulling a file from a W3K file server. So the upshot is that as Vista, and at some point Longhorn, starts to creep into the enterprise, it will have a significant impact on the network. Microsoft's answer is to use QoS, which is probably a good idea anyway, but I think Vista will force its use. Frank Bulk: Adding my two cents: It's also important to remember that there are over 2 million Vonage users running their traffic over the...Internet. Of course, enterprises will demand higher availability and quality than consumers, but the fact that VoIP phones have 100 Mbps or 1 Gbps edge links with 1 Gbps distribution links helps put things in perspective. Most enterprises trust that throwing enough bandwidth will solve the problem, and most of the time, that's enough. More important are voice services to branch offices running over bandwidth-constrained WAN links.

What do you think? Can your network handle VoIP traffic? Can your engineers? Add your thoughts to the comments section below?

Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like

More Insights