VoIP federation: another milestone

Slashdot recently picked out Federated VoIP as one of the compelling features in the upcoming Fedora 19 (Schrodinger's Cat) release. The same capability was recently part of the Debian 7 (wheezy) release and it is in Ubuntu too.

It is ironic that the debates about Federated VoIP have long mirrored the debate about Schrodinger's famous feline - is it dead, is it alive, or is it just a theory? Well, the answer is here today (for VoIP, not the cat).



Does it work?

Yes, it does work. Even better, users on all the supported platforms can call each other, for example, user1@debian.org should be able to seamlessly and securely place a call to user2@fedoraproject.org

What is involved?

Server: Each domain needs a SIP proxy, XMPP server or preferably both. They are alternatives and they happily co-exist. For convenience, they can run on an existing mail server as long as the load is not excessive. See the Real-time communcations (RTC) quick start guide for setting up the server, firewall rules, DNS entries and all other details

Clients: Each user can have a hard phone, softphone such as Jitsi or Empathy or a mobile VoIP client like Lumicall. Each of these projects has their own email support lists where users can ask any questions about getting started.

Is the server difficult to set up and maintain?

Setting up fully featured Asterisk or FreeSWITCH servers and keeping them secure for public Internet use is a daunting task. That's why federated VoIP with a basic SIP proxy is so compelling. It is possible to set up the SIP proxy now, get people talking, and add in a soft PBX later if optional features like queues or menus are needed.

The repro SIP proxy from reSIProcate is one of the easiest to set up. It can be configured through a web interface or directly entering users into the MySQL tables. Here is a screenshot:

Where to next for federated VoIP?

People should not be waiting for their ISP to deploy federated VoIP. Many of them are either looking for ways to monetize VoIP, or keen to keep costs low by just selling bandwidth.

Rather, it will be up to power users (like those of us who run their own mail server at home), corporate IT departments and also the IT departments of universities and other large, distributed organisations to take leadership. There is huge opportunity here: by displacing the phone companies, IT departments can provide a wider range of services to their organisations. Money previously lost in contracts for phone systems can bolster the IT department as the one-stop-shop for technology, giving IT workers greater career opportunities and stability in their organisation. The organisation benefits from having a system designed and operated around their business needs with much better value for money and a visible support team.

Comments

Too bad SIP cannot be integrated in common authentication systems such as PAM or LDAP. This is the main reason why I only use XMPP for now, and I do not think it is about to change.

SIP suffers from the same problem as Apache HTTP `DIGEST' authentication, it uses a H(A1) hash instead of a UNIX salted password hash. LDAP does support these hashes though, it just requires an extra configuration telling the LDAP server to save each password in multiple hash formats. Windows passwords also use a different hash, and LDAP servers have to deal with exactly the same problem to support Samba authentication. On top of that, RADIUS has a special mode for SIP DIGEST authentication, which is supported in reSIProcate's authentication code. Personally, I use both SIP and XMPP every day.

You might want to explain what a SIP proxy does. I.e., what does it proxy from where to where?

SIP proxy can be a misleading term. Sometimes it is called a SIP router or just a SIP server. A SIP proxy has a much bigger role than a HTTP proxy. Technically, SIP is a kind of peer-to-peer protocol and most of the hard work (media processing) is done in the end-points (e.g. softphones, desk phones). A SIP proxy usually has a stable IP address and domain name and does whatever it can to help route SIP messages between the end-points. Due to things like DHCP, the end-points normally can't find each other directly. On the other hand, a SIP proxy/router is not a full-blown PBX like Asterisk: it usually can't do things like giving the user menu options and processing the DTMF responses.

I really love your efforts to get people to set-up there own federated-voip-server.
When I skimmed rtcquickstart.org I was a bit sad to see there was little help for people like me who run their "sever" on a Xdsl with dynamic dns / changing ip's.
Is this because running e.g. ejabbered on such a server makes no sense?
If you think there is merrit to voip server on a dsl, could you maybe point out the stumbling blocks.
e.g. when i need the to ip's can i replace one of them with the DNS-Name if yes which. can the other ip be one in my home network, e.g. 192.168.x.y?
many thanks for your help

Having servers work is one aspect of the picture. Having clients just work is another important aspect. Is there any overview documentation on what clients available in Debian just work? And with what? And in which Debian distribution? Is there a wiki page?

Example issues I ran into:

* psi (jabber) supports voice chat, but psimedia is no longer packaged, so it doesn't.
* jitsi (sip, jabber) is a great client, but it isn't available in any Debian distribution. (It's work in progress on mentors.d.n!)
* ekiga (sip) is nice, but it doesn't support zrtp.
* twinkle (sip) supports zrtp, but upstream is dead.

This (missing?) documentation is nothing upstreams can provide for Debian. Can you help getting this started?