jkroon

It is with a heavy heart that I start writing this entry. I’ve always enjoyed working with asterisk after overcoming an initial (unfounded) fear of it, in part due to the words from a relatively brilliant ex-coleage of mine from my days working at Techteam (CS dept at the University of Pretoria). It’s a mind-bending experience, to say the least, fun and requires a decent amount of intuition. However, recently I’ve been realizing that the current state of affairs is oh so very far from ideal.

In principle I have no problem with what Digium is doing with asterisk itself, I grant any company that maintains a piece of software the rights to make money off of that software, however, their patch licensing agreements are in dispute (amongst other problems). Even without this, I believe it’s time for a community driven derivative.

I can promise you, this decision hasn’t come easy and whilst the idea has struck my fancy once or twice before (in part due to extreme rudeness from certain elements in #asterisk – which I can also understand – you merely need to ask some of the students and even staff from my days at Techteam and any of them will easily tell you that I can pass as a BOFH any day), it has recently become much more serious and has been quite heavily discussed with some others on IRC.

My primary concerns regarding the current state of affairs is as follows:

• Digium refuses to merge patches onto (presumably amongst others) DAHDI that would be advantages to asterisk as a whole but detrimental to them as a company. I’ve got complete understanding for this, I too would be hesitant, but they are essentially (and rather effectively) blocking technological progress. I am, for example, in posession of a patch for DAHDI that adds support for pretty much every obnoxious ISDN card I’ve run into over the last two years (mISDN and CAPI, very effectively negating the need for chan_capi and chan_misdn to even exist – and these two modules have been the bane of my existance on a couple of occations). This is known as vendor lock-in and I’m sure Richard M. Stallman would have a few things to say about this that are much more rude than anything I dare utter. This patch comes from within Digium itself.
• Often patches for bugs are sitting on the issue tracker but doesn’t get merged due to whatever reason. I refer you to a bug where you can’t initiate calls on a DAHDI channel until that channel has received an inbound call, as one example. Chainsaw (lead asterisk maintainer for Gentoo) can give you a significantly longer list.
• Purposeful (in my opinion) crappy oslec support. Oslec is by far the best software echo canceller known to man kind, with the exception possibly of HPEC which I haven’t tested due to licensing concerns. In my not quite so humble opinion it even kicks the living daylights out of Digium’s hardware echo canceller – any variant, any day. I refer you once more to the previous point, and then pose the question – why doesn’t it get it’s rightful place?
• In order for any developer to commit a patch to this “GPL” (and yes, the quotes are on purpose) (s)he has to sign a Digium agreement that they can do with that code whatever they want, including issues regarding patents etc … obviously a fork would need some guarantees regarding patents too, however, the Digium agreement goes much, much further than this.
• Many of the bug-fix releases (I’ve tracked the 1.6.1 branch closer than other branches) includes functionality (and even non-backwards compatible) changes. This is in my opinion not acceptable. I want to know that if I upgrade with a bug-fix release that only bugs are being fixed. In fact, the numbering scheme seems to follow that of the kernel, but often functionality would change with no good reason. For example, I would expect that a change to the IAX/2 protocol remain backwards compatible at least within a single branch (eg, 1.6.1 or 1.6.0, and if it does indeed change, there aught to be good reason for it, and the changelog summary should state it clearly as part of the upgrade procedures).

Well, so that explains my position to an extent. Ultimate Linux Solutions (in collaboration with Chainsaw) maintains a set of patches with which we patch asterisk before we can roll out a new install. Fortunately the ebuild system makes this easy, but it shouldn’t be required to begin with. This implies double work as it means that every distribution is probably maintaining a similar set of patches because upstream is refusing to merge clearly working patches, often without good reason.

For me (personally, and for ULS) there would be a couple of advantages to an asterisk fork. In particular:

• I’m fed up with the politics game (see above), this may or may not get rid of it.
• asterisk in it’s current form isn’t (imho) GPL, it’s GPL with a very nasty twist.
• We need something that is vendor neutral (ULS doesn’t produce hardware, so even though we mostly – probably about 95 % of installations – use Digium’s hardware we wouldn’t care to merge patches for another vendor – permitting it doesn’t affect the existing codebase negatively). Obviously this doesn’t eliminate possible conflict of interests from a software-only perspective.
• No need to maintain separate patch sets.

There are some obvious disadvantages, some of which may (for me at least) turn out to be show stoppers. The most notable of these are the additional work this will put on an already stretched ULS team. At least until we can bring on external developers to assist and to take lead on various aspects (none of the ULS staff for example has sufficient knowledge of the SIP protocol to be able to maintain chan_sip, or any of the other aspects, the patches we have submitted was mostly bugfixes where we track down a specific issue, often based on hints we scavanged from other bugs and even suggestions from IRC). Additionally, we’re quite happy with the existing functionality and isn’t neccessarily looking for new functionality, merely a stable codebase into which bugfixes can be incorporated. Possibly the odd alteration to existing functionality and on the outside chance we might do something new.

From a technical perspective, a lot of users (ULS included) relies on Digium’s G.729 codec (for which Digium holds a patent license), which implies that at least a certain level of binary compatibility will need to be maintained. There exists open-source implementations of this codec, however, they do not enforce the channel licenses (which leaves the consumer open to legal battles with Digium). Which begs another issue, Digium’s support on these licenses are so horrendous it’s not even funny. I’ve had cases where during boot a license would claim to be “invalid” but upon restarting asterisk, it suddenly becomes valid. Response from Digium? None. Or by simply adding or even changing the settings of a PPPoE connection the license would be invalidated. All in all this particular problem has probably cost me in excess of $1000 to date.

There are also a bunch of logistical problems which will need to be overcome. Nobody in ULS has experience maintaining a bug tracker (we do make use of RT as an issue tracker, but this serves a different purpose). Setting up a couple of mailing lists with archives is dead simple as we already maintain such a service for other reasons. A new fad seems to be creating an IRC channel – something for which I (and certainly most of my staff) don’t have an abundance of time. The version control system will need to be properly designed and maintained (here I will most definitely look at git).

And only then do we get to other problems, like compatibility with asterisk (because let’s face it – asterisk is pretty much the de-facto standard). This move will also alienate Digium in all probability, I do not see any way around this unfortunately.

On the upside, and this plays to my advantage, there is nothing stopping me (or anybody else) from tracking their GPL released code and porting patches from asterisk to the fork. This holds for libpri, dahdi and asterisk itself. In order to stop this they will pretty much need to stop accepting patches from the public and not release any further internal code under GPL. This would from their side alienate the entire asterisk community.

What we have currently is a declaration that this needs to happen. You’re reading it. We have a couple of servers available for hosting, including one of the larger software mirrors in ZA who is willing to host ftp for us. We also have a ULS server available in Texas and Chainsaw has mentioned he’d be willing to provide some hosting and bandwidth in the UK. We have some C knowledge. We have the asterisk issue tracker to crawl. We have access to asterisk’s anonymous svn. What we don’t have is the manpower. It is our opinion that this will come if (when) everything else is in place.

The questions that remain is how long it will take to set up the infrastructure, and what to call it. Ostrich has been suggested.

This entry was posted on Wednesday, January 27th, 2010 at 10:52 pm and is filed under Scripting/Programming, VoIP. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.