Running VoIP via VPN (SSL) – voice quality

The protocol overhead caused by the encapsulation of VoIP protocol within VPN dramatically increases the bandwidth requirements for VoIP calls, thus making the VoIP over VPN protocols too “fat” to be used over a mobile data connections like GPRS, EDGE or UMTS. Although VoIP over VPN is not as usable in mobile environments, it is sometimes used to create “encrypted VoIP trunk” between different sites of a corporations, running VoIP PBX interconnections over a VPN connection.

VoIP is often written off as an application that will not work well over an SSL VPN link. To test that argument, we have discovered ten VPN products (SSL) in four network scenarios to see how well VoIP calls were handled in this conditions.

The news is generally good. In high-bandwidth, low-latency environments, there is virtually no difference in quality between an unencrypted VoIP call and the same call made over an SSL VPN.

Even better news is our discovery that a VoIP call made over SSL VPN on a typical broadband Internet connection is of higher quality than an unencrypted call. The only bad news comes with truly awful network connections: ones with high loss and limited bandwidth. In this environment, neither unencrypted VoIP calls nor SSL VPN-protected calls will be considered acceptable, below MOS of 3 (Mean Opinion Score).

While our results do show some differences between products, small variations in the MOS should not be considered significant. What is more important, our testing demonstrates that SSL VPN and VoIP work together well over broadband networks, even in the face of some network loss and congestion. We also found that datagram-based SSL VPN techniques, such as those used by Nortel and Juniper (both optionally), do not appear to offer any real advantage for VoIP traffic and may give poorer results than TCP-based SSL VPN from the same vendors.

To test VoIP over SSL VPN, we used a product from GL Communications that measured the quality of voice calls using standardized testing procedures. To see how VoIP would behave in the real world of broadband ISPs, we used a Shunra Virtual Enterprise to inject latency, loss and other impairments, based on our measurements of broadband IP service at wireless hot spots, hotels and other temporary locations around the world. We used common “soft-phone” Session Initiation Protocol software on the SSL VPN client side, with a SIP “hard phone” inside the SSL VPN server.

We examined four scenarios, ranging from a perfect 100Mbps network with a few millisec of latency, all the way to a poor-quality 100Kbps network with 60 milliseconds of latency and other impairments. We called these four scenarios “unimpaired,” “good,” “bad” and “bad/slow.”

Our first tests set a reference to see how the SIP software and hardware would work without a VPN in the way. The GL Communications Voice Quality Tester gave us MOS ratings for our calls, with higher scores being better quality. Most people would consider a call with a score as low as 3.0 to be acceptable, although obviously degraded. These no-VPN networks set the standard for SSL VPNs to meet: acceptable quality over unimpaired and good networks, with poor calls over the bad and bad/slow networks.

Our next set of tests measured how each SSL VPN device behaved carrying VoIP calls over an unimpaired network. The results were good. In general, the SSL VPN devices caused very little degradation in the quality of the VoIP calls. With a perfect MOS being 4.24, as set by our base test, the worst score we saw (with F5 being the exception) was 4.16. And, as we noted above, the difference between that and the perfect score is not likely to be noticeable. Even the low score registered by the F5 FirePass device, at 4.02, would still be considered a very good call. Granted, testing over an unimpaired network with zero latency doesn’t tell you much about how these devices would work in the real world.

Performance tests run across the good network yielded counterintuitive results. We had predicted that the quality of a call over an SSL VPN could not be better than over a clean wire, just because of the additional interactions between TCP and SSL on the protocol level that SSL VPNs put under the User Datagram Protocol (UDP)-based VoIP traffic. We were astonished with the results from the first test runs on the good network; it showed that many SSL VPNs improved the quality of VoIP calls – we retested everything, twice just to confirm the results. The improvement in call quality from our baseline of 3.31 ranged from less than 5% to as much as 20%. Only with extremely detailed analysis of the packets crossing the good network did we discover what was happening: TCP was improving the quality of calls by reordering and retransmitting packets.

In every case, adding an SSL VPN to a VoIP call over a good broadband network improved call quality. So in effect, wrapping a VoIP call in SSL gives it more structure, kind of like the rind of good Brie. What we had not counted on was the huge difference between what VoIP requires (64Kbps) and a typical broadband connection of 500Kbps or more. Because the broadband connection was so fast, TCP was able to repair the impairments without reducing voice quality.
One twist of SSL VPNs is that not every vendor uses SSL over TCP in its network extension client implementation. Nortel’s client encrypts TCP traffic over TCP, but encrypts UDP traffic over UDP. If the UDP doesn’t get through, the client falls back to pure encrypted TCP. Juniper’s client uses the Encapsulating Security Protocol (ESP) transport of IPSec, a datagram service similar to UDP, for TCP and UDP traffic. This is optional, with the client able to try ESP first and if that doesn’t get through, fall back to standard SSL over TCP.

We tested Juniper with TCP and ESP because these are under the control of network managers. Our initial predictions were that VoIP over TCP would behave poorly compared with VoIP over datagram services such as UDP and ESP, because TCP’s retransmissions would interfere with voice quality. Our tests showed that for a good network, Nortel’s and Juniper’s datagram services gave 15% lower call quality than corresponding TCP-based services. The call quality was roughly the same as for an unencrypted network, a result that made sense.

The best news of all our testing came when we set up the bad network, representing the lower end of quality of the broadband services. In this test, TCP and a high-speed network again came to the rescue. All but three of our SSL VPN vendors also improved the unacceptable call but took call quality up enough for the call to be considered acceptable.

In these tests, we saw as much as a 45% to 50% improvement in call quality. For network managers looking to deploy VoIP over SSL VPN for traveling users, this means calls from all but the worst broadband networks will have very acceptable voice quality.

Our last test, run over a bad, slow network, showed that when the network is horrible, nothing helps. In some cases, such as with F5′s, Nortel’s, SonicWall’s and Juniper’s ESP-based transport, the call quality over these degraded links was about as bad as the reference. In all other cases, though, the interaction between a bad, slow network and VoIP gave awful results.

Network managers who wish to use SSL VPN with VoIP services can roll them out in most network scenarios knowing that SSL VPN can clean up an average network connection. For home users who have good-quality broadband, and for most travelers, any of the SSL VPN devices would give a good experience. Because this test focused only on one aspect of SSL VPN remote access, VoIP call quality, our results may not help to significantly differentiate products. Instead, our testing shows that VoIP and SSL VPN can coexist very happily.

Original text by Joel Snyder