Oh, wow. CNET just mentioned a startup that’s aiming to run VoIP over SSL VPNs:
Net6 has developed technology that it says will get voice and video traffic to its destination securely and without delays. The way the technology works is that the Net6 device sends false TCP acknowledgements so that the sender continues sending packets. Murli Thirumale, Net6’s chief executive officer, admits that some packets may be lost along the way, but he said that has little effect on voice quality.
Oh, ouch. There is a fundimental mis-match between SSL VPNs (which tunnel traffic over a TCP connection encrypted using SSL) and voice over IP, which uses UDP packets. TCP, while generally wonderful for moving data from point A to point B, really sucks when latency is important, because it handles packet loss by stopping new traffic and patiently retransmiting the lost packet until it’s received. That’s exactly what you want for email or web browsing, but it destroys VoIP, because it’ll produce a big dead spot in the middle of the conversation, followed by a huge lag for the rest of the connection. You’d much rather have the network just forget about dropped packets and move on, and that’s basically the antithesis of TCP’s whole design. So, you really don’t want to use TCP for VoIP conversations.
For better or worse, SSL VPNs have been taking hold lately, mostly because IPsec VPNs are a total bastard to configure. SSL is a lot easier to work with, so SSL VPN companies have been getting a lot of buzz. VoIP has also been getting a lot of press (and VC) interest, so I suppose it’s natural for someone to come along and try to combine the two–it’s buzzword heaven. The only problem is that they mix like oil and water. In order to get things to work, you need to rip out most of the core of TCP and replace it with something evil.
Fortunately, the company in question has patented their approach; hopefully they’ll be aggressive enough with their patent to keep anyone else from even thinking about doing something this dumb.
For what it’s worth, there are actually a couple specs for integrating SSL and SIP directly. First, you can use SSL and TCP directly for the call setup side of SIP. Since the call setup doesn’t actually carry any voice traffic, TCP’s packet loss behavior isn’t a problem. Then, once the conversation starts, you can use encryption inside of the RTP packets that carry the voice call. Unfortunately, neither spec is widely supported yet. There have been rumors of an Asterisk implementation for almost a year, and I’m only aware of one phone that directly supports encryption: the Zultys 4x4.