I've had cause to do some investigation recently into best practices for planning, deploying, and managing VoIP. While I won't go into all of the details tonight, I did run across an interesting inconsistency.
Most VoIP hardware/software vendors and consulting agencies that I've dealt with recommend a fairly telephony heavy planning measurement period prior to any VoIP deployment. This phase will involve, among other things, pulling reports from your old school telephone on phone usage so that you complete your erlang calculations to estimate the additional bandwidth that the VoIP traffic will require. With this method, bandwidth is provisioned prior to the VoIP deployment and based upon non-optimized network configurations. While this may seem like a method for oversubscribing bandwidth, what usually happens over time is that the amount of traffic on the network increases, which caused MOS to degrade, and then the network is optimized over time with advanced services such as QoS to mitigate the circumstance.
That said, the process that I'm seeing most engineers use is somewhat different. In most cases, rather than invest significantly in planning before rolling out VoIP, I'm seeing a significant planning investment during the VoIP deployment. Many engineers have found that they can be very effective by deploying VoIP on a limited basis, to a pilot user group or WAN site, with little to no planning so long as there is available bandwidth and they're willing to react in real-time to performance issues as they arise. During this initial deployment they experiment with different CODECs, QoS parameters, queueing strategies, and bandwidths until they find the model that is "right" for their environment. At this point, they've come up with what is effectively a best practice for their particular environment and can go forward with planning and deploying VoIP for the rest of the enterprise.
As I was researching this I came across several free, web based erlang calculators. I thought this one was pretty cool:
http://personal.telefonica.terra.es/web/vr/erlang/eng/cerlangb.htm
Anyhow, for those of you that have pioneered VoIP within an organization, I'm curious as to how you went about the initial deployment...
Flame on...Josh
Rolling out VoIP service to our customers was not an easy task at all. We provide VoIP services to customers on our network via T1, NxT1, and Ethernet. It took us several months after initial deployment to get things right. What's worse, engineering was learning everything as we went - we deployed VoIP without even going through extensive R&D. Management wanted to sell the product to spur the R&D, but at the expense of some customers (who knew they were part of a 'pilot', but STILL!).
We started out with the mindset that all you need is bandwidth and that QoS is unnecessary until you start filling up your "tubes". This was quite wrong. While a VoIP call on our network is only 80K and many of our customers were not utilizing their WAN links anywhere near capacity, quality issues still occurred.
What we found out was that while there may be plenty of available bandwidth on a WAN link, you're still fighting with traffic spikes that you normally wouldn't see on a bandwidth graph or even during a 'show interface' session, as well as interface buffer congestion. Because of these issues, we ended up upgrading our entire TDM network to support much more granular QoS, which helped things tremendously. By ensuring VoIP traffic take precedence throughout the network, we were able to virtually eliminate every call quality problem within our ticketing system.
QoS is absolutely necessary in any VoIP deployment, whether you think you have enough bandwidth or not. Interface buffer congestion was our biggest problem and it was solved by QoS tweaking. It will take some time to get the right settings for your network and will likely be very painful.
Those are really some great comments. I couldn't agree more - QoS is a necessity. I worked with the guys at Cisco on a TechWise TV episode last week and they outlined the three critical factors for VoIP as being QoS, codec, and LANs. Of the three, I have to say that the QoS certainly seems to be the trickiest.
Thanks again for the comments.
Josh