RaspberryPi Secure VoIP access points with GNU SIP Witch

November 4th, 2012

coventry wifi voip access point

I have recently been working on RaspberryPi GNU sipwitch servers. I actually have two things in mind for this. The first is a simple and complete stand-alone secure free software voip “switch” anyone could deploy and use, much like a FreedomBox for VoIP, as a kind of wallwort with ethernet you can plug into any router. A low cost and general purpose secure VoIP server does I think have appeal, and producing complete pre-configured and assembled servers would certainly be more interesting than selling project t-shirts. The second idea is a sipwitch VoIP public wifi access point to enable anonymous secure calling, like pictured here.

The RaspberryPi itself shown here was actually won in the recent Fedora participant open hardware giveaway contest. While I do participate in Fedora as a packager, in recent years I tended to focus more on Debian, and currently do have the Debian derived RaspberryPi distro on it. I would be happy to try Fedora for arm on it as well, especially since I do package sipwitch for Fedora.

I also maintain an active package archive in GNU Telephony that now includes both armel and armhf packages for Debian Wheezy, as well as mipsel for use with entirely free hardware and bios, such as the Lemote yeeloong netbooks. This archive can be added to any Debian related distro adding “deb http://www.gnutelephony.org/archive/ wheezy/” to a sources.list. I also have squeeze packages, and I include both source and binary packages for everything I build. Awhile ago I found a simple means to automate production of multiple binary architectures through the use of qemu as part of my normal release process for those packages I maintain. Having a publicly accessible Debian archive updated for each new release seemed a natural extension of this.

The sipwitch coventry voip and wifi access points really came about because I originally wanted a sipwitch raspberrypi server I could take with to conferences to setup and demo, complete with an entirely portable communication infrastructure that I could use. Too often I have been at conferences where infrastructure was not available in the presentation rooms, or otherwise not suitable for this, like what happened to me several years ago at Harvard, which had password restricted wifi and isolated individual machines from each other. It also fits well into GNU Telephony’s goal of developing self-organizing mesh networks and community grids.

In respect to presentations with this initial experimental access point, it could be rather interesting to be able to accept VoIP calls for q&a from the local audience directly. It would be even more interesting if we can get a network to tie to for the ethernet side that would allow remote voice and video participation as well. I want to re-think how such presentations are done, and how to make it easier for remote participation in general. These all offer interesting ways to demonstrate and promote the freedom of free software to think, imagine, and go beyond how things are done today.

The specific use of a powered usb hub was to avoid the problem with too little power on the RaspberryPi to drive a wifi device. This is not needed when using it as a pure voip wall-wort through local ethernet, and that would likely be the most convenient and widespread form factor I would propose building, and of course that has some natural overlap with the FreedomBox effort. Another interesting idea that came out of this effort was to create a RaspberryPi hylafax server using usb fax modems.

The particular choice of coventry itself as a name for our RaspberryPi VoIP servers really came from the idea of what to properly call a collection of bruja de sip del GNU servers, which, spectacularly obviously, would have to be some form of coven.

MinGW, Git, and software freedom for those trapped on proprietary systems

November 3rd, 2012

It has been known that I tend to do some cross-platform development, including for software that can be used by people unfortunate enough to have to use Microsoft Windows. However, I thought it particularly relevant to talk about how we do this, as it offers a much clearer vision of how to maintain freedom in the production of free software even when doing so for otherwise captive users.

For me the most logical approach has been to make use of MinGW (Minimalist GNU for Windows), which is a set of GNU tool chains, GCC compilers, and tools that have already been adapted for compiling applications for Microsoft Windows. However I do not use these on Microsoft Windows itself, as I do not run proprietary systems to develop or build applications, or even have proprietary operating systems on my machines. Instead I use it on Debian hosted systems as a cross-compiler environment.

The MinGW tools for cross-compiling have been present for a long time in Debian. The present form is installed with mingw-w64-dev, and supports building applications for both 32 and 64 bit Microsoft windows. Fedora also includes a version of MinGW in their repositories. In their case, they not only package the cross-compiler, but also common free software related libraries, which can be installed to provide a more complete environment. There is also a PPA out there that does the same for Ubuntu. I am however not so sure this is a great idea. What I do instead is directly cross-compile a common set of free software libraries out of a vendor branch repository that has versions I can test and maintain as needed.

The concept of a vendor branch is that one takes an existing external (3d party) library produced elsewhere and imports that into a local repository. One can then track local changes needed for something different (such as mingw cross compiling). Since the base of the tree is an import of an upstream release, one can easily create and submit patches back to an upstream when appropriate.

I now use git for such vendor repositories. While there are different strategies to do this, for me the simplest was to create a bare repository, and then only push and store tags in it. All intermediary work can be done with local branches as needed.

If I want to make a repo for version 5.0.0 of libfoo, I would create a repository, locally create an import branch, and tag it something like v5.0.0-original. This tag then gets pushed. If I want to do some changes, I can create a temporary work branch locally in git, do the changes, and then create a new tag, like v5.0.0-patch1, and then push that new tag to a remote vendor repository. If I want to then submit a patch upstream, it is as simple as using git to diff between v5.0.0-original and v5.0.0-patch1.

So a new 5.0.1 release comes out. This too I can import into the same repository, using a new temporary local branch, and import in a new tag, v5.0.1-original. In theory I can then apply the changeset between v5.0.0-original to v5.0.0-patch1 to it to get any patches/changes I found needed for local builds, and save that as a new tag, v5.0.1-patch1, as well. This is very similar to how vendor branches used to be handled in cvs.

So far I have been able to rebuild most libraries one finds in a GNU distribution for common application development, as well as cross-platform desktop toolkits like Qt. In the case of Qt, I was able to create new spec files that explicitly support cross-building mingw32 hosted on Debian and then use Qt’s own configure to generate appropriate makefiles. I also have been looking at wxWidgets for some uses.

Building instable binaries on MinGW32 hosted on Debian also provides a much saner way to develop software for Microsoft Windows. Where Microsoft never really seems to have developed a concept for a standard shared place to store common libraries and headers, and I think this is because even the most basic philosophy of code sharing seems completely alien to them, I can organize one on a debian box and build with it with simple configure flags.

Since I also use nsis (also packaged in Debian) to make pretty graphical installers for applications for Microsoft Windows users, and can use wine for testing, this means I can build and test deployable binary applications for Microsoft windows users without ever having to have a license or any other legal instrument with Microsoft, whether for their development tools or operating system, and this too I am happy about. We can build free software for that platform using entirely free as in freedom tools and operating systems. These tools can never be taken away at the whim of a proprietary vendor, nor enable false legal harassment that any form Eula with an entity like Microsoft can potentially enable.

Of course we license our software using the GNU General Public License (v3 or later), and so others do have the freedom to build, modify, run, and distribute our software as well, even on entirely proprietary platforms, if they so wish. Also, we will take patches into our distribution for such uses, so long as they do not interfere with the ability to build and run on free platforms.

Where free software tools and software are needed to empower and liberate users even on defective source secret operating systems, I feel the only ethical means to do so is using free software tools hosted on already free platforms. For this reason I will probably never produce installable binaries for OS/X, as I have yet to find an effective means to support cross-compiling on a free platform for that. Certainly also I will not produce installable binaries that can only be offered to users through closed application stores which are in effect censored. Those I see as dis-empowering both end users and software maintainers, even those producing proprietary software, in ways that are unconscionable. I see it as part of a clear and very deliberate attack on what we call freedom 0. I also see it as a form of restraint of trade and may seek other means to address it going forward.

Secure Calling in Fedora

August 9th, 2012

Sometimes you learn about what’s going on in a distribution by accidentally breaking something. Such was the case for me recently with respect to Fedora.

Fedora is an RPM based GNU/Linux distribution that does focus on providing a free software license clean repository, with the one unfortunate exception of the Linux kernel itself including binary blobs, and that publicly fights against software patenting. Fedora also happens to focus on enabling community self service a lot. For this latter reason too it came to pass that I maintain some of my upstream packages directly in Fedora over two years ago, rather than having this done by an intermediary Fedora package maintainer, as more often occurs in other GNU/Linux distributions.

Often Fedora provides the most current software in the community. Recently (in F17) Fedora choose to upgrade to the latest ortp. We have been in the process of quietly integrating GNU ZRTP into ortp since last year. The result of this was first realized accidentally with this new Fedora release, when my current commoncpp release, for the first time, broke KDE Kopete and Linphone in Fedora 17 over an old and never before identified bug.

Breaking something in a distribution is not the most horrible thing, and we were quick to resolve it by providing a fixed package. However, it made me think about something deeper. In Fedora, we have sflphone, linphone, and kopete, we may even still have Twinkle too (I haven’t checked), and all of them are now offering the potential for secure calling using the GNU ZRTP stack. They may well be the first widely used distribution that now potentially offers media path secure calling in most of the included voip clients by default. And Fedora does also include GNU SIP Witch.

I think it is time again to think about what secure calling means from the perspective of a distribution. How do we effectively put together something at a GNU/Linux distribution level where all the pieces work together seamlessly, and it is easy for anyone to setup and deploy secure calling clients or services, whether for private use or for an organization. And what does this vision mean for what we need to do next with GNU Free Call, how does a GFC client finally help bring these pieces together.

The last time I thought about the question this way was also over two years ago, and it was perhaps premature then. We still did not have all the parts needed to do so available to end users in any distribution at the time. We were still struggling with what was an artificially overly political process even getting packages included in some GNU/Linux distributions. It also before GFC, and what was thought about then is now rather obsolete.

Fedora operates as a true community of equals without politics, and I will give them much credit for doing that also. It was at the time back then, and I think it remains the easiest GNU/Linux distribution to try and work with in this way. This time I want to get more feedback about what others think and expect a distribution that offers the possibility for providing secure communications through free software much more out of the box should look like, and this need not be limited to voip.

If there is interest in this I would be happy to put together and propose a new feature for what will be Fedora 19 and 20, as well as seeing what packages would need to be suggested for inclusion in their repository, or otherwise modified as part of such a feature proposal. Some of this work will be needed anyway to introduce GNU Free Call into Fedora when the time comes to do so. Having more feedback I think will make for a cleaner and more compelling feature set. If we can similarly work better with other free software distributions, I would be very happy to do that also.

GNU Telephony IRC Meeting for 4/23

April 22nd, 2012

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)

GNU Telephony and cross platform development

March 31st, 2012

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.

GNU Telephony begins public meetings

March 27th, 2012

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.

Our goals and LibrePlanet 2012

March 26th, 2012

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

GNU Telephony plans for 2012

December 18th, 2011

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.

Automake and cmake revisited

July 3rd, 2011

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 \

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.

How GNU Free Call is different

June 7th, 2011

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.


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.