By Date: <-- -->
By Thread: <-- -->

Running VoIP over SSL VPNs? (Network World article)

Greetings!

On Tue, 21 Feb 2006 14:30:49 -0500
dan_york (at) Mitel.com wrote:

> Network World came out with an article yesterday that detailed 
> their tests on running VoIP over SSL VPNs:
>    http://www.networkworld.com/reviews/2006/022006-ssl-voip-test.html

...which does not tell overly much about the *real* setup. IIRC at least
some of the units come with some kind of QoS or load
balancing/equalization between the established VPNs by default (please
correct me - it's been quite some time).

 
> I'm curious to learn from folks here... are there list subscribers 
> using VoIP over SSL VPNs?  If so, would you care to share your 
> experiences here?  What are you using... softphones? Handsets 
> with ATAs?  Handsets with SSL clients inside?   How does the quality 
> sound?  Have you compared using your phone over an SSL VPN to 
> running the same (hard/soft)phone over an IPSEC VPN?

Actually you are asking about 3-4 VPN techniques here:

   1. IPSec
   2. SSL-style over UDP
   3. SSL over TCP
 ( 4. Plain HTTPS web portal - marketing-hyped SSL accelerator )

The first is the VPN technique used "everywhere" when you get near
firewall-based VPNs.

A prominent candidate of the second one is OpenVPN.

And the fourth is plain marketing garbage.


"SSL-VPNs" (3rd) often do VPNing over TCP - which can lead to timing
problems and resend-races between the inner and the outer TCP stack
whenever packets are lost. Plus encapsulating UDP into TCP can add
*quite* some additional delay over noisy/lossy lines due to
resend/confirmation requests and handshakes. On the other side you won't
have any RTP packets lost as the outer TCP automatically requests
resends. So that actually might "improve" the perceived sound/tone
quality - by sacrifycing delay up to recognizable pauses.

Their main advantage is that tcp/443 plus SSL usually are no problem to
tunnel through corporate firewalls - so an "ideal" solution for
consultants trying "to phone home".

On the other side the implementation sometimes leaves quite a bit to be
optimized (e.g. downloading a monstrous client each and every time the
VPN is being established - yeah, rrrright...). 


I've found that the first two do not differ much. VPN is adding its
(small: few ms) share to the total delay, but that's pretty much it -
unless you have to set up the connection while ringing. This will cause
a recognizable delay - during the call setup phase, so not overly
critical (there are exceptions, though). And this is independent wether
soft- or hardphone. 

If you have softphone and VPN client on the same system that one needs
enough CPU power for both: the VPN and the voice codecs. That usually is
a problem for PDAs - but current PCs and laptops should handle both with
ease - though the latter quite often have abysmal audio interfaces,
adding noise and colouring/distortion.

But of course you need to "enVPN" the traffic somewhere - and unless
your router is doing the VPN stuff, you probably will run into problems
with hardphones as those usually won't run the often proprietary 
Windows-only VPN clients...


One major problem source always to keep in mind when using VoIP over VPN
client: be careful about all routing at *ALL* layers! 

Routing all the RTP out to the internet via a proxy/STUN server usually
is not overly compatible with setting up a call from via VPN...



Back to the beginning: all other things equal I did not find any
difference between using VoIP over ("real") VPN or not. There was a
small added delay, but definitely no improvement.

I have not experimented with VoIP over SSL-VPN-over-TCP, but I think
that the suddenly loss-less (or at least less-lossy) RTP (over TCP)
might actually lead to a perceived sound/tone improvement if the delay
is being ignored during that test.

Bye

Volker


-- 

Volker Tanger    http://www.wyae.de/volker.tanger/
--------------------------------------------------
vtlists (at) wyae.de                    PGP Fingerprint
378A 7DA7 4F20 C2F3 5BCC  8340 7424 6122 BB83 B8CB

_______________________________________________
Voipsec mailing list
Voipsec (at) voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org