Proposed Antisipate UI Visual Introduction

September 15th, 2013

Antisipate, our first GNU Free Call client, is not like most other sip user agents. We have chosen to simply the operation of the agent, and make it more chat friendly, rather than trying to simulate a “telephone” ui, like many do. We are looking to support functionality for voice, video, chat, file, and screen sharing in a single client, and secure end-to-end media with GNU zrtp. This should give some idea of what this client may look like and where we are going with the ui design, as well as offer an opportunity for others to consider and offer improvements in what we are trying to do.

Antisipate Login

Login is very simple. If you have sipwitch on a local server, it is even almost automatic, as we use zeroconf. Otherwise, saying something@somewhere.somedomain for an identity will also work, especially if there is a srv record for the somewhere.somedomain, or that is a fqhd of a sip service. This was meant to truly simplify sip. I remember the first time I setup a sip account with Twinkle, there were more than a half-dozen options that had to be set, and most other sip ua’s have not improved much over that. All I believe that is needed is the identity and the secret, and the rest can be determined as needed.

While not shown here, there is also a tray icon. Antisipate is a tray application, and will minimize to it. Eventually tray icons will be used to convey current application state, and we will make use of osd notifications.

Antisipate Main Screen

The main UI would be an address book and a text bar to enter what you are dialing. It either defaults to dial or chat mode, depending on view. In chat mode, it creates an instant message session with an arbitrary uri. Antisipate would fill in sip:…@somewhere.somedomain if an incomplete uri is entered to reference other people on the same server as you. When we populate the address book, one will be able to also click on entries in that directly.

The address book itself is to be composed both of “bookmarks”, which are just stored uri’s with a speed dial they are mapped to, and sip “subscriptions”, which give live status. Ultimately both of these will also reside in sipwitch, so one can subscribe to a users own roster, and receive both through notify messages back from sipwitch. This will make the roster live with the user identity on the server, rather than stored locally with each client you have.

Antisipate Session

When a chat or call session is created, each instance will have it’s own active ui. For pure chat sessions, the voice related options will be hidden, expanding the text space. Pure chat sessions can be converted to sip call sessions through the call button. For incoming sessions, the “Call” button becomes “Answer”. For ZRTP there is space for presenting a sas. We also are going to try to have avatars within sip.

The lock icon will be used for setting otr sessions. Yes, I think otr, or at least some means of strong and effective cryptographic privacy, is a fundamental requirement for any Internet connected chat system these days, and systems that fail to provide for this completely fail for their users.

This should give some idea of what antisipate will be like, and how it’s ui will operate. Our goal was simplicity. We already have worked on packaging for Debian. One reason was to make sure that it is possible to get antisipate in before Jessie freeze. Similarly, we think Antisipate may be ready to introduce into Fedora in the time-frame of F21. If this appears to be the case, we will likely propose a changes for this for Fesco to consider along with by then sipwitch 2.0.

How to participate in GNU Telephony Development

September 12th, 2013

Sometimes people ask how they can participate in the development of our packages, such as sipwitch and antisipate. We have worked on making it very easy for people to participate directly on our code. One of the special things we have done is create a git repo that checks out and builds all our packages together in a single source tree. This can be accessed from anonymous git:

git clone git://
cd sources

This does an anonymous checkout and then sets up and builds an entire project tree of all my packages through a single top level make. Of course cmake means I can also use ctest, and we will eventually create a continuous build server in the future to make use of this. This is part of why we choose to maintain our own dev server for this project. As we use gitolite, people who actively participate in GNU Telephony can also be added for git write access. Otherwise, git makes it very easy for someone to produce a patch that can be submitted by email.

The README.DEPENDENCIES covers what system dependencies need to be installed for Debian. I also documented the dependencies we require for building on Fedora. Other GNU/Linux distros should be as easy to use to develop from also. Finally, we also have “git clone git://”, which has a that does an automake build tree for those packages we currently support automake for.

Antisipate and sipwitch progress update

September 7th, 2013

We have reached the point where Antisipate, our new secure VoIP client, is able to successfully maintain registration with a sip service, as well as handle the various registration failure cases. This is an important breaking off point, as it enables us to develop functional client services (calling, messaging, etc) on top of it now.

We of course will use our GNU libzrtpcpp library to support secure voice & video media. As we work in the free (as in freedom) world, we are able to of course work from other similarly free software implementations, including the excellent sfl phone, and the old code base from Twinkle, as reference models for connecting rtp to audio for the media sessions. I am also going to introduce otr for in-dialog sip chat messaging during active call sessions. Given the questions currently around standardized algorithms, I am also looking to see if we can make it easier for individuals and organizations to plug-in alternative ones of their choosing.

Similarly, there has been a lot of progress in sipwitch. In particular, we have started introducing the new eXosip2 4.x feature set, which includes maintaining multiple protocol contexts. The work of integrating contexts will be slow and happen over multiple releases before 2.0 is ready, but at this point the sipwitch registration cycle is now complete and context aware. This much likely will make for a new interim sipwitch release, 1.8.

We do not cooperate with, nor receive funds or grants from any U.S. government agency, any U.S. allied governments, or U.S. government related institutions, as it seems so many of those who operate in the commercial closed source proprietary world seem so eager to. To do so I think, especially given present circumstances, would compromise our ability to provide privacy enhancing secure communication solutions. We believe privacy is a fundamental right and necessary for basic human dignity, as outlined in the United Nation’s Universal Declaration of Human Rights (UDHR) article 12, among other places and documents, that the present U.S. government now so thoroughly repudiates for all mankind.

What is a distribution of GNU Telephony

September 5th, 2013

We have various packages for GNU Telephony in various GNU/Linux distributions and elsewhere, though not all are current. We do not however have something that is a “distribution” of GNU Telephony as a whole that would be maintained as a stable baseline.

A “distribution” of GNU Telephony would in my mind simply be a repository of packages, rather than some kind of new kind of GNU/Linux distribution. It would be a snapshot archive of our already existing wheezy repository, and the git source tree branched in our various package repositories so we can later do patches as needed against a stable release. Anyone with a debian 7 based GNU/Linux distro could then simply use the stable repository we provide to get a baseline of all our packages, and supporting libraries (like exosip2 4.0) that we have backported.

To me a stable baseline must provide working antisipate and sipwitch packages that can be used immediately. With current work in sipwitch, this means completing the exosip 4.0 api support. So far we now do have a new sipwitch build (in git for 1.8) that finally maintains multiple exosip context event threads, so we can support tcp and udp sip, and tls options all in one server instance. This functionality is spreading over the code base, and I think could be completed by this winter, and was the primary goal for sipwitch 2.0. I think we could also have a usable antisipate client by the end of the year, too.

If we can get sipwitch 2.0 and an initially usable antisipate client, say by this winter, that would be the right time to also try and do a project-wide “distribution” of GNU Telephony as a whole. I think doing so by providing a stable repository with source and binary packages for immediate use with Debian 7 would facilitate it’s actual use.

Of course we will continue to package and support packaging efforts of other distributions. We also may provide 32 and 64 bit mingw builds for those users who do find themselves trapped on Microsoft Windows, as we also have an excellent mingw cross-build environment hosted on Debian GNU/Linux. Other platforms may depend on where we get external help and testing.

GNU Telephony Packaging

August 30th, 2013

One of the things we have been doing in GNU Telephony that may be unique is that we have our own package build infrastructure. This allows us to rapidly produce and test installable packages for multiple distributions and architectures. In particular, we have tamed qemu user mode emulation to support arm (including raspberry pi) and mipsel packaging, as well as building the more common x86 targets natively.

To accomplish this we use a number of original tools nobody else has heard of before, but, of course we also do distribute all of our tools as free software licensed under the GNU GPL (cape-devtools). While other build systems work by providing clean environments to build any arbitrary package, we already have a known fixed set of packages we wish to rebuild, and hence ours uses dirty changeroots we pre-load with the dependencies we would normally expect to actually use. This saves a lot of excess time reloading the same dependencies over and over again each time.

Our model is I think most similar to how RedHat mock can be made to behave, though we primarily support Debian, we have expanded to supporting Fedora (and by extension Epel), and we expect to include support for arch build environments in the near future. We also make our changeroots operate as “normal” user mode accessible, so that root privileges are not needed to execute builds, or to run debugging & testing of packages built for foreign distros. This means our build & development environment can be entirely separate from our host distro, and in fact we can use any GNU/Linux distro we want to host our development.

Another thing we do is automatically generate references to local package repositories in the chroot environment, as well as automatically determining bind mounts and creating self managed mount sessions, through a tool called cape-chroot. This means we can easily build a core package, such as a library, that other packages we may depend on, and place the results in an archive where the chroot will then get updated automatically, using a repo management tool known as cape-archive. This too speeds packaging and distribution.

Another specialized tool we have is cape-changes. Somewhat like Debian dch, it maintains editing of package changelogs. However, it does so the same way for rpm’s with their %changelog entries, too. There is also cape-source, which converts a release tarball into a signed debian or rpm source package for use in our build system.

Currently we provide pre-made packages primarily for Debian Wheezy. Our archive includes some things that have not yet been backported (such as exosip2-4), as well as newer releases of things like ucommon (now 6.0.x). As I officially package ucommon & sipwitch for Fedora, and a number of our packages are maintained very current by others, we find no reason to do this separate from Fedora itself. However, there are some packages (like cape-devtools, coastal-qt, etc) that I wish to see added to Fedora, and may come to maintain those in Fedora also if that is what is required for it to happen. On the other hand, aur made it so very easy to provide and distribute PKGBUILD’s for all of our packages that everything we have produced is available in current releases in arch.

I was hoping to bring Jessie packaging up in our repository this weekend. Alas, ucommon in Jessie is still version 5, and other packages are obsolete. SID has current ucommon releases (6.0.7), and so I don’t wish to pre-make jessie ucommon packages since we do so with different options than the official debian packages will later use, or create strange conflicts between our repos and official Jessie later. On the other hand, Jessie retains much older ucommon (& zrtpcpp) packages with known security vulnerabilities, so I hope they update testing from sid soon, and certainly before freeze. Naturally this issue is also relevant to Trisquel and other Debian related pure GNU/Linux distributions.

Fund raising and Antisipate

August 28th, 2013

I have noted that people have been asking about what we are doing for fund raising. I actually have been reluctant to talk about our funding situation simply because it never has been successful. We our participating with the FSF in fundraising through the working together for free software fund and I think we have now for more than a year. The main reason I had been reluctant to do crowd funding, for example like mailpile did, rather honestly, is, based on all other funding experiences I have ever had, I feared it would be entirely unsuccessful as well, and that would be even more of a motivational set back than not doing so.

Our primary public resource is a development server hosted by a volunteer entirely for free, and we were very lucky to finally get that earlier in the year. Some have asked what funding we might need. I do think just to keep things going the way we do actually need to, we would need to find a minimum of 10k, and most ideally we would wish to secure 100K for the next year or two.

In regards to success and failure of other SIP based VoIP clients, which so often is discussed, one of the reasons I held back on doing one for so long is that I did not want to create yet another client that would also be too complex for normal people to setup and actually get working in real world environments. I feel we have finally come up with a design that offers the true simplicity needed for our goals, and have worked through enough of the other problems that I believe we can finally provide one that can finally just work out of the box when it is complete. Antisipate is not meant to address all the many complex enterprise integration needs and specialized features, or to support multiple protocols, that many other existing VoIP applications provide, but rather will provide a simple and reliable means to do secure communications that just works, while remaining faithfully standards compliant and fully inter-operable with other people who may be using such things.

Antisipate is also helping us address issues in sipwitch itself, particularly in that it has made completion of sipwitch media proxy integration, and other sipwitch features, much more urgent. I believe the sipwitch 2.0 feature set will be completed and delivered in conjunction with completion of the first widely usable antisipate client. Our goals do require delivering both together.

Fedora Flock

August 26th, 2013

Earlier this month I attended the first Fedora Flock, in Charleston, SC. This replaced the older Fedora Users and Developers conferences, none of which I had participated in prior. Other than certain difficulties with my return flight, this was a fun and interesting event, and I do hope Fedora has more of them going forward.

Fedora is a GNU/Linux distribution that has a genuine community that is also focused on questions of software ethics and freedom. The Fedora community actively supports efforts to eliminate software patents. Fedora policies are not all that different from those proposed by the FSF for model free software distributions, including excluding restricted applications and patent encumbered codecs from the main repositories.

One of the more interesting presentations at flock was the lulzbot 3d printer. 3d printing to me offers many of the possibilities for freedom and participation in mechanics and art that software freedom offers for software development.

I actively maintain two packages in Fedora; GNU uCommon and GNU SIP Witch. I offered to run a VoIP sprint for flock. This was an interesting choice, as I never ran a sprint before, and the few I had seen were multi-day events, rather than just a few hours. However, I think this was an effective sprint in that we had achieved some consensus on a number of issues with Fedora and VoIP within it.

One of these was to do something more in Fedora than simply having the current Fedora VoIP sig, which really is just a wiki page old VoIP specific package requests. In particular the people present wanted to make the Fedora VoIP sig something much more active and relevant to Fedora going forward.

In my mind Fedora VoIP should be about security and interoperability. Certainly given that Fedora offers a secure out of the box desktop configuration, this makes sense with the larger context. Actually Fedora already has libzrtpcpp enabled VoIP applications. Interoperability, to me, means use of standards compliant protocols and services.

One of the things people wanted to do was to package freepbx for Fedora and produce an Asterisk server spin. While I am doing something different, as is becoming clear with emerging work in both sipwitch and antisipate, I do also favor this idea as well. In some interesting ways this actually aligns well with some proposed ideas going forward for Fedora itself.

The broader context of this is a proposal, presented by Steve Gallaghar, about refocusing Fedora by producing a Desktop, Server, and Cloud Image, perhaps even on different release schedules, rather than the single do-everything okay but nothing spectacular Fedora distro we do have now. Part of this is also about defining clearer policies for what packages are core to delivery of Fedora releases. I will write about this more at a later time.

Updates and sipwitch 1.7.1

August 25th, 2013

I thought I would provide an update on where we are now with sipwitch 1.7. I just completed a new srv resolver plugin for sipwitch and a new resolver plugin api to support it. We used a plugin for this purpose because we are using libruli for srv lookups, and it has a lot of dependencies of it’s own, so I wished to make those all optional for sipwitch.

There are many deployment and use cases for sipwitch where it never needs to do an external srv or even dns lookup, and so there is no need to carry all that baggage to support srv in the default server. This is also true for sipwitch zeroconf support, which already is a plugin so that the default server image need not depend on avahi client libs when zeroconf is not being actively used.

The new sipwitch srv resolver plugin was released as part of sipwitch 1.7.1 on August 24th. In fact both antisipate and sipwitch both support srv lookup now, and both can already also successfully find each other with zeroconf on local subnets, which is a part of our goal for simple auto-configuration of sip services whenever possible.

In the case of antisipate, zeroconf and srv lookup are expected to be normal or default services, and anyway it is likely to be deployed on desktop machines rather than also supporting deeply embedded routers, so having them built-in to the client is not as big a deal. However, we may also look at going to plugins in the new client too in the future.

With the recent use of libruli, a fine GPLv3 licensed library, we have some challenges too. There are distributions that do not yet package it, though Debian does. In particular, there is Fedora. It is unfortunate in that I also maintain the sipwitch packaging in Fedora. However, srv support is actually optional at build time, though I do think it is desirable, especially for many client application use cases.

Antisipate development has also helped move sipwitch development forward. I look forward to (anticipate) providing many more updates in the months ahead. Our goal is to provide some kind of usable Antisipate client by the end of the year. Our other goal is to survive long enough to do so.

GNU SIP Witch and Antisipate

August 24th, 2013

Generally I avoid doing gui projects, simply because every gui I ever attempted ended up looking very ugly. Yet, a little over a month ago I decided we needed to develop a true GNU Free Call desktop & mobile client of our own to work with our SIP Witch servers, even with what limited resources we had. This package is now being called Antisipate.

Thanks to the widespread adoption of GNU ZRTP (libzrtpcpp), including it’s use in ortp, there is actually no shortage of ZRTP enabled clients in general, including linphone, sflphone, and even Kopete. The Java version of our library, as maintained by Werner Ditterman, ZRTP4J, became part of Jitsi. However, none of these offered a very simple to configure SIP client, which really is an essential part of our goal for replacing Skype with free software that is easy to use and operate by anyone, and that uses standard protocols. Hence, Antisipate.

Our overall goals also includes delivering VoIP socially, through integration with Friendica, as well as making it possible to use stand-alone SIP services and our new Antisipate client. For IVR support we will be introducing a new and more modern version of Bayonne.

Our greatest challenges remain not the technical, nor even with available volunteers, but rather with things like funding. Our development has become very resource bound. I am very grateful to Andrew Doughty for making available a publicly accessible development server for our use some months back. I plan to publish much more regular updates on our work going forward.

Be free by programming in freedom
David Sugar, Chief Facilitator, GNU Telephony

Openshift and Freedom in the cloud

February 5th, 2013

When we think of the cloud often we have to think of the negative consequences, of diminishing the rights of users and removing their control even over their own computing. When combined with an illegitimate surveillance state and abusive monopolies that believe they have the right to look at people’s private data and communications at whim, this puts basic liberty, and even the life, of people engaging in entirely legitimate activities in danger from that most basic human need, that of communicating and sharing with each other. However, not all ideas for cloud computing need be based on or potentially offer anti-social and otherwise destructive outcomes.

Much of cloud computing infrastructure of course also uses free software. True software freedom even includes the freedom of some to misuse. The GNU General Public License deals with a very specific form of misuse, where anti-social parasites could try to create proprietary versions of existing free software and thereby deny their own downstream users the same freedoms they themselves received. However, the potentially malicious aspects of cloud computing use is different, and, for example, like free software used in military systems, is one which to solve potentially has the unintended consequence of destroy freedom for many others. We simply cannot of course predefine for others what are legitimate uses for our software, we can only assure that people who receive it have the same freedoms we ourselves received, whether we feel they use it for what we may deem as good or bad purposes. If we act otherwise and define for others what we consider “permitted” uses we would in doing so destroy freedom 0.

However, it is worth noting that not all uses of cloud computing need have negative social consequences, and I wished to spotlight a specific example which I think shows a better way to go forward. This particular one is a service and software stack for cloud services offered by RedHat known as Openshift. I do not choose to endorse particular companies, products, or services, but I wished to highlight what RedHat is doing in the context of this discussion because they are doing something very relevant and interesting that may offer a means for addressing the anti-social and more destructive aspects of cloud computing.

Openshift itself was originally called Makara and part of a company that RedHat acquired in 2010. Having done so, they made the entire stack available on a free software license (Apache 2.0) last year. Of course as noted other cloud computing stacks are available on free software platforms, and at least some with liberal/free software licenses. This is not the problem. However, there are several essential things that RedHat is doing differently that are worth noting.

First, they make use of git and shell access to deploy applications. This solves one important issue; data migration. Often cloud computing providers lock your application services on their platform, and you cannot then easily get your computing back or otherwise migrate it, for example even to another provider, and even if they both use the same base software stack. This makes application migration as easy as setting a different remote git repository and pushing. However, the real problem in cloud computing is not in being able to migrate from one potentially abusive external entity to another all under the watchful eyes of a surveillance society, but also in being able to regain full control of your computing if you so choose or otherwise need to. It is in this I think Openshift offers an interesting solution that I think should be a default behavior for all legitimate cloud computing services.

Starting, I believe with Fedora 19, the entire Openshift stack is being included in the Fedora repository as a simple set of packages anyone can download and install. There is also online resources and documentation for building the infrastructure from source. This means if you do not wish your computing externally hosted, you could, with relatively modest resources, host your own cloud computing directly. And since simplicity of data and application migration is already part of that infrastructure, it also should be very easy to migrate services and applications back to your own facilities anytime you may wish. To me this helps to mitigate an essential risk in cloud computing.

The Openshift infrastructure of course itself somewhat complex to setup and configure, and this I do not see as avoidable. However, having the freedom to do so, and the means to find expertise to help as needed, as well as very simple application migration, are essential elements missing in many cloud computing services. Having the means to do so with pre-packaged components in a distribution repository and under a free software license also will make that freedom much more realizable than simply theoretical freedom.

I see much less risk in having the freedom and means to host with an external cloud computing provider, so long as one can reclaim control and local ownership of one’s hosted computing if so choosing, and can do so relatively easily. Nor do I see any problem with using cloud computing tools for local infrastructure so long as they are provided as free software that runs on free software platforms. There is certainly room for improvement, though. Elasticity should mean seamless migration from local facilities on demand and by desire entirely under the users control, rather than by first requiring external migration. That is, the cloud elasticity should be an adjunct resource for times and workloads when desired, rather than an either/or choice. Having matching infrastructure locally could help eventually make seamless operations possible, certainly it is the place to begin.

RedHat itself offers some infrastructure for the community to experiment with Openshift, and we have been using this for a few things. In particular we are using it to host a bug tracking system and a friendika instance. In some ways this is better than a some kinds of more traditional external hosting provider because we do have the means to easily maintain our applications, as well as having the freedom to easily migrate and have these things hosted elsewhere if we do so need. This I think is at least closer to how cloud computing services should be offered.