GNU Telephony

Driv Inkubator and the Norwegian Competence Center for Open Source today awarded the GNU Free Call project 100 000 Norwegian kroner (17500 USD) for best eHealth solution using Free Software in their annual competition. This award has been presented to project coordinator Haakon Meland Eriksen and project architect David Sugar. Mr. Eriksen was present to receive the award during the GoOpen conference being held in Oslo.

GNU Free Call is a new project to develop and deploy secure self-organized communication services worldwide for private use and for public administration, and it will be released as Free (as in freedom) Software. GoOpen is a publicly-funded conference about using Free and Open Source Software for sharing.

It is often a challenge to provide basic humanitarian and medical care in stressed environments. Medical personal need to communicate, and to do so privately with regard to the dignity of their patients. In times of national emergency the communications infrastructure is often broken, and our goal is to address this through the development and deployment of self-organizing mesh calling networks. These can be built on the existing GNU SIP Witch package and deployed through IP capable cell phones and low cost FreedomBox servers, as well as through traditional locally connected desktop and laptop computers. Put simply – eHealth through a secured healthnet of cell phones.

Free Software means that the program’s users have the four essential freedoms:

* The freedom to run the program, for any purpose (freedom 0).

* The freedom to study how the program works, and change it to make it do what you wish (freedom 1). Access to the source code is a precondition for this.

* The freedom to redistribute copies so you can help your neighbor (freedom 2).

* The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

For more information, please visit our project’s site or contact us at the addresses below:

GNU Telephony – http://www.gnutelephony.org
David Sugar – project architect – dyfet@gnutelephony.org
Haakon Meland Eriksen – project coordinator – haakon.eriksen@far.no

I was both surprised and pleased with the community response to the announcement for GNU Free Call. Rather unfortunately our hosting for the wiki, Ibiblio, was down, as they were doing a large move on Tuesday. Even more amusing, Haakon’s email provider also decided to do some relocation this week.

With the many comments I received, it is clear to me some are best answered on the wiki, especially now that it is back. This includes things like a more detailed project roadmap, which Haakon has been hard at work updating. Other things are probably best handled through the mailing list (sipwitch-devel). In particular, I think many concerned issues that either were not well explained in the FAQ attached to the original announcement, or not covered at all, and so I think we need to have a new or further extended FAQ on the wiki for GFC.

What I wanted to talk about right now is some general things in GNU Telephony as a whole. In particular, there are a few things in development now, and some of them do require additional help.

The first of these is an effort to consolidate GNU Common C++ with GNU uCommon, and have the entire ZRTP stack build under cmake. There already is an experimental branch in svn for a ucommon library that also builds commoncpp, and an experimental branch of ccrtp that builds against that. I am hoping to see this released for ucommon 4.2, or maybe 5.0, as there are also some abi issues I would like to change in ucommon itself.

I had asked Simon L’nu to help me coordinate establishing a public portal so people could create accounts and connect through sipwitch to each other securely such as with a ZRTP enabled SIP client, as well as receive calls from the general public under a public sip uri, if they so wish. I also want to use this to coordinate internal project communications, and I have thought about setting up freeswitch as a conference server backend for this purpose. But we do not yet have a public site to run these things at, though several nations, including the Cherokee of Idaho, have asked about possibly helping with this.

There is also an experimental sipwitch gui that has been started, in Qt. This may eventually become a desktop Gui to match Haakon’s very impressive vision, but initially it may only exercise some core sipwitch services for desktop users. At least it is a starting point down that path.

I had also thought about writing a wiki document explaining our policies and coding practices. Most are essentially the same as used in the GNU project, especially when speaking of packages that are already part of GNU proper. However, in some of the newer packages, we may diverge in some areas as is convenient for our users so long as there is no effect on freedom. For example, much like in KDE, there is a growing tendency it seems in GNU Telephony to prefer cmake over autotools.

For those who have offered to help with GFC, I especially appreciate that. I hope all can join the mailing list, so that it will be easier to communicate and collaborate together in freedom.

“Free as in freedom, and free as in no cost, too!”

GNU Free Call is a new project to develop and deploy secure self-organized communication services worldwide for private use and for public administration. We use the open standard SIP protocol and GNU SIP Witch to create secured peer-to-peer mesh calling networks, and we welcome all participation in our effort.

Who
Haakon Eriksen – Project Coordinator – haakon.eriksen@far.no

David Sugar – Project Architect – dyfet@gnu.org

What
Our goal is to make GNU Free Call ubiquitous in a manner and level of usability similar to Skype, that is, usable on all platforms, and directly by the general public for all manner of secure communication between known and anonymous parties, but without requiring a central service provider to register with, without using insecure source secret binary protocols that may have back-doors, and without having network control points of any kind that can be exploited or abused by external parties. By doing so as a self organizing meshed calling network, we further eliminate potential service control points such as through explicit routing peers even if networks are isolated in civil emergencies.

We do recognize this project has significant long term social and political implications. It also offers potentially essential utility in public service by enabling the continuation of emergency services without requiring existing communication infrastructure. There are many ordinary public service uses, such as the delivery of eHealth services, as well as medical, and legal communication, where it is essential to treat all with equal human dignity by maintaining privacy regardless of race, religion, or political affiliation. Equally important is the continuation of emergency medical services even when existing infrastructure is no longer available or has been deliberately disabled.

How
Initially we will extend sipwitch to become aware of peer nodes by supporting host caches, and then support publishing of routes to connected peers. This work builds upon the already existing routing foundation in sipwitch itself. The use of host caches is a mechanism used in older p2p networks, it is generally well understood, it would meet the initial goals of establishing a self organized mesh network, and it is rather easy to initially implement to fully demonstrate the potential of sipwitch as a mesh calling system. More advanced methodologies can then be added later on.

Related to this goal is having sipwitch operate as a SIP mediation service for desktops users and IP enabled cell phones such as Android. This introduces the needs for users to be able to “pilot” their local sipwitch instance through a desktop and cell phone gui, whether to see what calls are being placed through it, or to see the verification status of secure key exchange. There are today IPC interfaces in sipwitch to allow for desktop integration, but a specific GUI to use these interfaces and present server and call states in a manner for people to understand still needs to also be constructed, and hence this too is part of the plan of work for this project.

In addition we will be extending GNU SIP Witch to offer secure VoIP proxy. Much like what was done initially by Phil Zimmerman to develop ZRTP using zfone, this mode of operation will enable development of key elements of a secure infrastructure without having to also initially create new SIP user agent applications. By offering secure proxy through a SIP Witch instance running at the endpoint, any existing SIP standard compliant softphone or device will be able to establish a secure connection to another standard compliant SIP device or SIP peer that is using GNU SIP Witch at the destination.

This project’s definition of secure media is similar to Zimmermann’s work on ZRTP, in that we assure there is no forwarding knowledge by using uniquely generated keys for each communication session. Furthermore, we will use GNU Privacy Guard (GPG) to fully automate session validation. This will be done by extending the SIP protocol to exchange public keys for establishing secure media sessions that will be created by each instance of SIP Witch operating at the end points on behalf of local SIP user agents, and then verifying there is no man-in-the-middle by exchanging GPG signed hashes of the session keys that were visible at each end.

Why

1. Why GNU SIP Witch?
GNU SIP Witch is a destination router for the SIP protocol. This means it is primarily concern is not in making things interconnect “with” the SIP Witch Server, like say something like Asterisk does very well, but rather instead is designed to enable two (or more) endpoints to find and then directly connect with each other. By handing off media operations directly to communicating endpoints, GNU SIP Witch requires a minimum of system resources, making it very suitable even for low end embedded routers, as well as for freedom boxes, shared virtual server instances, desktop systems, and IP connected cell phones such as Android, rather than requiring a dedicated server.

2. Why on the desktop and cell phone?
Ultimately we want to be close to the user so that no third party or external service must be connected to before establishing secure sessions since we are using unmodified SIP clients. If an external party is required, the connection between the SIP client and that external service would of course be completely insecure. A user with their own local infrastructure can of course also run a single sipwitch server, such as on a freedom box or a virtual machine, to meet all their local connectivity needs rather than doing so on each machine or device. An organization can also run a sip witch server on a completely remote site, such as a public portal, when interconnecting existing security enabled SIP clients, such as SIP Communicator and Twinkle, which support the ZRTP protocol stack. Another side benefit of having SIP Witch on the desktop and cell phone is that as we develop SIPWitch NAT services, it can act as a single point of contact for mediating all SIP protocol services for a user, as well as offering a single place where NAT support and mobile re-connection will only need to be configured and implemented once, rather than in each SIP client separately.

3. How to get GNU SIP Witch?
GNU SIP Witch is formally distributed as a package that is part of the GNU Project. It is also packaged in a number of popular GNU/Linux distributions, including Ubuntu and Fedora, GNU SIP Witch can also be built on most BSD systems from source, including OS/X, and supports compilation on Microsoft Windows as well.

4. How to configure GNU SIP Witch?
In the past GNU SIP Witch has been difficult to configure, even for ordinary uses. To address this issue we are hoping to finally introduce a model public portal that anyone will also be able to download and use to construct and configure a SIP Witch site or private service. To address the needs of peer-to-peer calling, we are introducing a desktop and cell phone GUI interface.

5. Why do I need a local SIP account to use it?
Since GNU SIP Witch is a SIP service one needs a SIP identity to authenticate yourself to your own local SIP server. However, we wish to eliminate manually creating local SIP users by offering to automatically detect and generate a local user account with a matching SIP user agent configuration for you as a single click operation from the new GUI. Initial clients proposed for this include Android CSipSimple, which is also being extended with GNU ZRTP, the Twinkle Softphone, and perhaps SIP Communicator, which uses the GNU ZRTP4J stack. Other clients, like GNOME Empathy and Linphone, may also be supported in this way as well.

6. How can I participate?
We have a wiki site used for GNU Telephony as a whole (http://www.gnutelephony.org/), as well as a mailing list for sipwitch itself (sipwitch-devel@gnu.org). In addition, to discuss core architecture, privacy issues, and social consequences, we have another mailing list gnucomm-privacy@gnu.org.