GNU Telephony

This monday (04/23) at 21:30 GMT we are having our second GNU Telephony public meeting on IRC freenode.net, in #friendica.

I had moderated the first meeting last month, and I am thinking we will rotate this, perhaps with Haakon Meland Eriksen moderating this one, and maybe Simon L’nu moderating the one after. I like the idea of rotating moderators. I had been kept rather busy this week and weekend organizing systems, so I am a bit late catching up on things and in getting this post out.

This is what I have so far for the agenda:

Old business:

* Update on bug reporting (yes, we now have bugs.gnutelephony.org kinda up)

* gnutelephony blog in debian planet?

* video/screenshot tutorial (Haakon has made an excellent start here)

* roadmap – yes, this is not yet updated…

* upcoming conferences we should attend

* friends.gnutelephony.org to become our public friendica site.

* hosting our public services with hipatia.

New business (proposed):

* Haakon updates on FSF Directed Donations, and what we should do. Should we also use kickstarter?

* Request for a user friendly page for describing free as in freedom telephony software

* Possibility of using gnunet for peer-to-peer dns

* Packaging sflphone for debian

* Should we have a jitsi tutorial?

* Freenode #gnutelephony room?

* Third meeting schedule (5/21 proposed)

Cross platform development is always an interesting challenge. Often it can be useful to identify or expose bugs that might be less visible on some platforms, or even on some compilers.

With cross platform development comes some important questions of software freedom. There would be no true software freedom if we said we would permit our software to compile and run only on specific platforms, that is after all what proprietary software vendors often do. However in GNU Telephony we do principally develop and test our software on GNU systems specifically and do not have expertise in or interest in supporting proprietary ones.

If people wish to work on or support other platforms also, they are certainly free to do so. As one of our goals in GNU Telephony is ubiquity, this is essential. However, unlike some groups who choose such goals, or distributions who choose “popularity” as their essential goal, we will never do so if it means also compromising the freedom of our contributors and users. Given this, if people want to submit patches for building and running on other platforms, we are happy to take such patches in, so long as they do not break features or functionality on free software platforms, and do not impose any additional restrictions on how we convey software to others.

For those who do choose to develop on or for Microsoft Windows, and wish to contribute to our packages, we do suggest using the mingw toolchain hosted on Debian GNU/Linux. We have done some preliminary tests with this, and have built things which then do run in wine. This does make it possible to do a complete build and qa test cycle for applications that will run on Microsoft Windows systems using entirely free software tools and platforms, as well as making it easier to avoid traps in undocumented proprietary api’s. We will accept patches and bug fixes from those who do build on proprietary compilers as well, assuming there is no restrictions or breakage to do so, since, as I note different compilers sometimes do expose useful bugs, however our desire is to support development tools and platforms that do support and encourage software freedom.

Software freedom and complete free software platforms is our projects essential goal, for without it, there is no possibility for communication privacy or security. This makes fully free software platforms, which are hostile to hosting malicious features or hidden backdoors, equally essential. While we do the best we can to facilitate secure communications in our packages, we do not recommend using or running our software on proprietary platforms, as we consider these untrustworthy and potentially insecure by design.

Yesterday we held our first regular IRC meeting for GNU Telephony. While it was not widely circulated, I was happy with the turnout and those things we were able to accomplish. This is particularly good as there were no predefined agenda. We have set some clear goals particularly for helping making our software more easily usable and better documented for the next month. We also have adopted someone who I think will be in the role in our project as the user’s advocate, that is the one who will advocate directly what we need to do to help people participate and work with our software.

We are going to continue to have regular IRC meetings open to everyone. As we touch upon politically sensitive work, such as openly providing peer-to-peer cryptographic communication solutions to enable human privacy directly to the general public in societies that are becoming more closed to human freedom, or otherwise in direct conflict with the goals of the modern surveillance state, historically we have operated much more as a conspiracy than a public project in some key ways. However, we do have people spread worldwide, and I had wished to finally change how we operate so that we are even more effective at what we do as well as more transparent.

Our goal remains to empower people, individually and collectively, to communicate and collaborate, whether publicly, privately, or anonymously, in real-time worldwide through the use of free software. We choose to explicitly facilitate secure and anonymous communication to enable users to exercise their basic human birthright to privacy. We choose to do so on all computing and communication platforms where possible.

Our next meeting will be held April 23 at 21:30 GMT in #friendica on irc.freenode.net.

Today is a good day. I am back from presenting at LibrePlanet 2012 this weekend.

While I wanted to present on and speak about what others in GNU Telephony were doing since often their work gets less attention, it seems many were most interested specifically in hearing about how we are addressing the Skype hole to freedom. While I am actually happy with how this presentation went, I ended up a bit short for time in my presentation, and did not get to the final point I had wanted to discuss, which is something we have been discussing internally for some weeks now, whether we should commit to a “moonshot” goal, such as to deliver a complete turnkey secure phone system by the end of the year in something that could be delivered on a small server (such as a freedombox), and also to do those other hard things. However, it was a brief discussion I had with Eben Moglen right before heading out that I think most directly reflects on this question.

The problem I see in committing to such a goal is that I do worry that we do not presently have enough time, and hence people, or funding to do it, at least that quickly and completely right now. I would hate to commit to a goal that we cannot yet achieve. On the other hand out of the discussion with Eben came some ideas that I think would make this goal even more relevant and interesting if we could commit to it. I was also happy to hear Eben is a knowledgeable user of secure communications, and of Twinkle in particular as privacy is also very much about freedom.

Actually one thing I am also looking for is a hackerspace to do some local development in. We are also looking to broaden participation in GNU Telephony, especially if we do commit to that goal. There is work in GNU SIP Witch I need time to do, including cleaning up access policy, media proxy, and nat handling, and those things alone could consume much time for me already, let alone the many other areas that do need at least some attention. We also want to use GNU Bayonne to offer voice mail and other services for a complete solution.

My LibrePlanet presentation can be found at http://www.gnutelephony.org/data/libreplanet2012.odp.

Happy hacking

Today is a good day. I just distributed ucommon 5.1.0, and a second api and utilities snapshot for what will eventually become GNU Bayonne 3.0. I think GNU Bayonne will become strategic to our goals in 2012, along with GNU SIP Witch and the GFC client. We have already discussed internally an outline and possible goals for 2012 development in GNU Telephony, and I have made preliminary plans to attend LibrePlanet2012 in March.

GNU Bayonne is currently in reconstruction and fits into our plans in respect to offering things like dialing plans, automated voice response, voice messaging, etc. Finishing reconstruction of GNU Bayonne is one of our goals for early next year, and one that should not be too hard to complete, since we have a complete codebase to start from.

Another important feature is local multicast registry operation in GNU SIP Witch. I also have open items related to NAT support, presence, and subscribe-publish operations to complete. On user facing aspects of sipwitch I want to start a qt based GFC client to replace switchview. A Friendica addon is also on the roadmap.

Finally, we will look at converting sipwitch from a server daemon into a library link kit, so we can link it directly into a GFC client. This will be particularly useful for delivering GFC on things like android and still allow us to “link” it into a more traditional daemon server application as needed for other kinds of conventional deployments too. Hence GNU SIP Witch as a package could eventually be able to build both a sipwitch server with supporting utilities (keeping switchview for this use case), and also provide a complete and stand-alone GNU Free Call application.

It is also possible to offer sipwitch, with it’s very low use of system resources, as part of a complete turnkey GNU secure small office VoIP phone system, such as by having it embedded on a router, running on a plug server like FreedomBox, or alternately as a hosted office phone system, where it’s additional attributes such as management of secure extensions become particularly effective. If funding and opportunity become available we will likely explore that also.

One reason I had for awhile considered cmake so strongly in GNU Telephony is that I choose to experiment with using Qt to build applications, and at the time I thought it rather difficult to build QT applications under autconf/automake. A week ago I revisited this question on my own, and found I was actually wrong about this.

My interest in using Qt actually was from the period immediately prior to when Elop joined Nokia as CEO and then, much like Belluzo did to SGI, proceeded defraud the shareholders, employees, and customers of Nokia for the exclusive benefit of Microsoft and one presumes for his own personal gain. However, whatever his personal, and what I do happen to believe as being purely sociopathic, motives may be, it is very clear that Qt itself, with the help of the KDE foundation, and even MeeGO which I am less interested in, but even that, with the help of many others, would and do continue to survive and even thrive, and it matters not whether Nokia continues as part of that process or not in the future. This is just one real tangible benefit of freedom, that tools which you learn and use cannot be then taken away by either arbitrary or criminal actions. There are of course many other benefits to true software freedom as well.

But moving past the question of Nokia for the moment, much of the information I originally found about using Qt with automake was either incomplete or in some cases even incorrect. This was made in my case more complex because I also use qrc resource and qt designer ui files, all of which, like is done with headers with moc, also have to be preprocessed. Some of these also actually produce headers rather than source files.

One resource suggested that one can create a nodist_appname_HEADERS = .. entry, and I found this to be unsupported, at least in the version of automake I was using. However, when I saw this, what I did figured out instead was that I can use “BUILT_SOURCES” to do the same thing, and this answered the question of how to stage the construction of headers correctly from Qt ui templates in automake. What I ended up with is something like this (from the most relevant parts…):

BUILT_SOURCES = ui_options.h ui_mapped.h

noinst_HEADERS = switchview.h options.ui mapped.ui switchview.qrc \
error.png info.png switchview_down.png switchview_live.png warning.png

nodist_switchview_SOURCES = moc_switchview.cpp qrc_switchview.cpp
switchview_SOURCES = switchview.cpp events.cpp mapped.cpp options.cpp \
startup.cpp

ui_options.h: options.ui
@UIC@ -o $@ $<

ui_mapped.h: mapped.ui
@UIC@ -o $@ $<

moc_switchview.cpp: switchview.h
@MOC@ -o $@ $<

qrc_switchview.cpp: switchview.qrc
@RCC@ -o $@ $

I could of course used pattern rules for the transform of headers through moc, ui to ui_headers, and qrc files, but I decided not to since that would make the result depend on gnu make, and in fact automake warns about this. Explicitly writing the make rules for the individual transforms kept it more generic.

This is actually not more complicated than supporting Qt in cmake or even with qmake, and retains real benefits of using automake, whether one wants to use anjuta as an ide, support cross-compiling cleanly the way autotools does, or os targets and pathname transforms. Finally we have again a build system that only depends on native tools commonly found on posix systems.

We will of course continue to fully support and maintain cmake builds in GNU Telephony, for there are certain use cases where cmake does offer clear benefits for some of our users. But I will want to make sure going forward we do fully support automake and autotools as well. It is not so bad continuing to maintain both for I have found they each do clearly meet different needs and hence to some degree are complimentary.

Having made it possible to build the switchview desktop client fully with autotools, we are now ready to distribute switchview as part of that next release of GNU SIP Witch (what will be 1.1.0). Switchview was developed as a very early part of the transition to using sipwitch for delivering GNU Free Call services, for it represents a model implementation of desktop integration of the sipwitch service daemon, and hence is meant to help others in implementing GFC clients, as well as being a tool to enable monitoring of sipwitch activity when that is used as desktop SIP mediation service.

Replacing Skype, that is, to offer a public service anyone can use with public protocols and published standards that includes free software clients, and is fully cross-platform, is in one sense rather easy to do today. Someone recently suggested gnome meeting with ekiga.net for this purpose. I might suggest considering jitsi (http://www.jitsi.org), which is cross-platform, and includes the GNU ZRTP4J stack, either along with iptel.org (http://www.iptel.org), or even better, a similar kind of service powered by GNU SIP Witch, if one were looking for something that does simply this, and just call it a day.

However, simply replacing one “enclosed” network with another, even if one that is using free software and published protocols, simply makes a fundamental barrier to people communicating with each other become even more obvious. What happens if some of the people you communicate with choose ekiga.net, some choose iptel.org, and others choose something else? Does one go back to multiple accounts in multiple places? Does one require network effects to in effect “appoint” a new widely used communication monopoly to replace the old one with critical mass just for people to be able to reliably find and communicate with each other, until that single point of commonly chosen connectivity fails for some reason (whether commercial, political, technical, or otherwise) also?

This is where GNU Free Call most clearly differs from most others who are looking to replace Skype. As GFC is already designed for use with any SIP capable client, we have no interest in re-inventing protocols or even how VOIP clients work. This is not the problem we are looking to solve. We are instead interested in, not simply having people join or connect through yet another specific service provider to mediate their communications (whether iptel.org, ekiga.net, etc), but rather in enabling anyone to discover and communicate with each other directly without the need for a mediating service at all. It is how users are empowered to discover each other which is most important in GFC’s design. This is best illustrated by the GFC client, which is in reality contact focused rather than communication driven. This I think becomes more clear from the GFC GUI design (and experimental client), as illustrated here.

http://www.gnutelephony.org/index.php/GNU_Free_Call_GUI

What I think becomes immediately clear is that we are not looking to replace Skype, that is, as a service or facility, but rather instead we are seeking to replace the entire paradigm that originally lead to Skype, and that is still fundamental in many of the other alternatives presently being discussed.

May 14, 2011 (Bayonne, NJ). We are distributing today a 1.0 release of the GNU SIP protocol provisioning and peer-to-peer call server, GNU SIP Witch. GNU SIP Witch is developed within GNU Telephony and has been selected for use in the GNU Free Call project. This will provide a stable release that we will support for existing applications while we actively develop GNU Free Call services.

GNU SIP Witch is available as part of the GNU project. Stable releases will also power a web site later this summer to provide initial worldwide secure calling services for free directly to the general public for use in conjunction with any ZRTP enabled standards compliant softphone applications and SIP devices. GNU SIP Witch can be used to deploy private secure calling networks, whether stand-alone or in conjunction with existing VoIP infrastructure, for private institutions and national governments.

GNU SIP Witch is distributed as free software, that is, it is licensed using the GNU General Public License (GPL) version 3 (or later), explicitly to provide others the freedom to use, modify, learn from, redistribute, and participate in it’s continued development, and can be obtained in source directly from http://ftp.gnu.org/gnu/sipwitch. A number of GNU/Linux distributions already distribute GNU SIP Witch in binary form for easy installation. GNU SIP Witch is cross-platform and can also be built on Apple OS/X, BSD systems, and for Microsoft Windows. Future releases will also support Android devices for use in GNU Free Call. Our services and applications are intended to offer the benefits of software freedom on all common computing platforms.

GNU SIP Witch is a free software project and is being developed by volunteers from around the world. The Free Software Foundation and the GNU project provides technical, infrastructure, and organizational support for GNU SIP Witch development. Future work will focus on delivering GNU Free Call services such as self-organizing peer-to-peer calling networks directly to the desktop and mobile devices of users worldwide.

In conjunction with this release, the GNU Free Call project is distributing an initial release of our technological assistance package for common computing platforms by providing our switchview desktop client for use with GNU SIP Witch on your local machine. In the future TAP will enable multi-platform personal encryption, include further support for desktop and mobile secure calling, and provide other basic and common computing services missing on some platforms.

About the Free Software Foundation:
The Free Software Foundation, founded in 1985, is dedicated to promoting computer users’ right to use, study, copy, modify, and redistribute computer programs. The FSF promotes the development and use of free (as in freedom) software—particularly the GNU operating system (used widely today in its GNU/Linux variant)— and free documentation. The FSF also helps to spread awareness of the ethical and political issues of freedom in the use of software. Their web site, located at http://www.gnu.org/, is an important source of information about GNU/Linux.

About GNU Free Call:
GNU Free Call is a 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.

Contact Information:
Haakon Eriksen – Project Coordinator – haakon.eriksen at far.no
David Sugar – Project Architect – dyfet at gnu.org
Mailing List – Participation – sipwitch-devel at gnu.org

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.