You need a squeaky clean network for crystal clear VoIP
Thursday, 02 April 2009 08:39.
We were recently performing some VoIP Readiness Assessments audits on a client’s network and experienced some interesting test results when we came to testing compressed codec performance. As you may know, a common driver for using compressed voice over IP is that of bandwidth cost saving, in terms of getting as many consecutive VoIP calls as possible across a limited amount of WAN bandwidth.
Sure enough we all recognise there is no such thing as a free lunch and that trade-offs have to be made when looking to compress voice traffic, typical industry figures being:
G711 (64kbps) codec packetisation delay around 1msec, 160kbps bandwidth per 2-way call.
G729 (8Kbps) codec packetisation delay around 25msec, 60.4kbps bandwidth per 2-way call.
We were using MOS scores to verify synthetic call quality testing for the above 2 codec types and well understand the theoretical maximum MOS scores of 4.4 and 4.07 respectively are often difficult to achieve in many client networks today.
What we found from our testing was that variations in network delay and packet loss had a much more profound effect on the compressed G729 codec VoIP quality, so much so that acceptable MOS scores measured on G711 calls (that look to have tolerated network performance impairments) were unacceptable for G729 and the tests failed.
We looked into the network performance issue and found it be related to some subtle, but significant interface errors related to a service providers network. Hence armed with this information the client was able to approach their local carrier in a very informed manner and demand remedial action.
So if you are considering deploying VoIP and in particular compressed VoIP in the drive to save or defer WAN bandwidth costs then make sure you first check out your current infrastructure is squeaky clean, otherwise you could be in for a long battle fighting off your disgruntled VoIP users on call quality issues and convincing your service provider that the problem resides in their space!
Subscribe to this comment's feed
