I came across an interesting article showing that running VoIP over a (TCP-based) VPN actually improves call quality. This goes against what you would expect – VoIP traffic uses UDP to ensure the least amount of latency, while TCP ensures all packets arrive in order, but means that one holdup can stall the whole stream.

Once they investigated more, it actually makes sense why this happens. The VPN ensures that all packets get there, in order, which yields a better call. What is needed for this is enough burst bandwidth so if a packet is delayed, there is enough headroom to ‘catch up’ to the stream (detect the error, and retransmit enough data to fill the gap). A 64kbps VoIP call takes up about 80kbps when encapsulated in a VPN. Having a 100kbps connection isn’t quite enough, but in the tests 500kbps was enough to improve quality (see the chart). The flipside to this is that on a bad network, nothing helps, which really just seems obvious.

The interesting implication of this is that it’s actually another reason to deploy VPNs to remote workers. Not only is the call now encrypted (something many VoIP protocols don’t do) with proven SSL technology, but it actually helps the quality, provided they have a half-decent connection to begin with.

The other point here is that it’s actually okay to overprovision as long as you have enough burst bandwidth. For example, if you have a 2Mbps pipe, and are serving 12 users from it, they consume just under 1Mbps total. That leaves another 1Mbps for burst capability if any of the streams get left behind, and 12 times more than any single connection requires. (This is of course assuming no other traffic is flowing on the VPN, so adjust numbers accordingly if the VPN is used for browsing, file transfers, etc).

I’d like to see a test done using OpenVPN (they only used commercial VPN products), but it’s clear that it’s a good idea to add SSL. It’ll be interesting to see where this heads: if SIP phone manufacturers will start adding VPN clients or even just SSL transports to encapsulate the SIP traffic. Perhaps even a new TCP-based protocol will be thought up.

digg story