A sysadmin's view of VoIP

A sysadmin?s view of VoIP ? Ewen McNeill

Dunedin decided to grace us with a blue sky, making the walk down to the University rather pleasant. The sysadmin miniconf opened with Ewen McNeill?s presentation, ?A sysadmin?s view of VoIP?, a overview of some of the issues involved with using VoIP.

The talk covered quite a bit of ground, but had quite a lot of information on the integration of VoIP with existing analogue telephone systems. VoIP infrastructure is, it turns out, quite similar to the infrastructure for analogue systems: regular phones work by magic; for VoIP we just have to replace the magic with the internet.

Ewen detailed how the magic running our phone system is the cause of a lot of the problems users encounter when using VoIP. As far as the users are concerned, you pick up the phone, hit the buttons, and it just works. If we have software on a computer as our VoIP endpoint (think Skype or GnomeMeeting) then the system won?t work as a phone as far as the user is concerned: the interface is different, and for many people the computer lacks the ?always on? readiness of a phone.

Another violation of user expectations is the security of VoIP; or rather, the lack there of. At least one of the common VoIP protocols effectively results in the user streaming unencrypted WAV files over the ?net. There are efforts to implement SSL/TLS in several open?source VoIP products, but at the moment it seems the enncryption support leaves a little to be desired.

I found the most interesting part of the presentation to be the various protocols used by VoIP systems. The standard seems to be for there to be a control channel opened between the phones (possibly via some intermediary) for exchanging data about the conversation, and then data channels opened on dynamically negotiated ports for exchanging the actual conversation data. You may remember this sort of scheme from FTP.

In fact, the scheme?s so similar to FTP that it has all the same problems of FTP, particularly regarding NAT and firewalls. While it?s easy to allow the control channel through a firewall, as it uses a well known port, the data channels can use any port, making it extremely difficult to allow data channel connections without allowing the world and their dogs in. Additionally, the scheme relies an end?to?end internet, where any host can connect to any other - an assumption that NAT unfortunately breaks.

These problems don?t plague FTP, due to modern firewalls understanding the FTP protocol and so allowing the data connection through, and by the FTP protocol supporting ?passive? mode, avoiding the NAT problem. Neither solution works for VoIP (yet, there are alpha?level patches in iptables for the SIP and H.323 protocols), and so the current best solution seems to be an application-level gateway listening on both the internal and external interfaces of the NAT ? a solution that?s rather sub?optimal for NAT devices which can?t run such a gateway. In these situations it seems Skype (which uses a wholly different, although proprietry, protocol) may be the best bet.

You can read more about this, as the slides Ewen used for the presentation are available on the web at http://www.naos.co.nz/talks/sysadmins-voip/. Check them out.