Russell Bryant November 10th, 2009

For the last three years, I have had the opportunity to give an Asterisk Project Update presentation at AstriCon. It really feels good to look back over what we have accomplished during the past year and share some of the highlights. This year, the Asterisk Project Update presentation was a joint presentation between myself and Kevin P. Fleming.

For those who were not able to attend the conference, I would like to share what Kevin and I had to say. There were three main topics that we covered:

1. Growth of the Asterisk developer community
2. Asterisk release process updates
3. New features and architectural improvements

Developer Community Growth

Asterisk trunk is the main development branch for Asterisk. This is where we are preparing the newest changes for the next major release. For example, new features that go into Asterisk trunk today will be first available in Asterisk 1.8 (wait, what?! 1.8?! Yeah, yeah. I’ll get back to that in a bit!) Asterisk trunk stays very busy. Here are some measurements regarding activity in trunk over the last year:

• 2320 commits
• 825 files changed
• 322148 Lines of code added
• 53251 Lines of code removed

While lines of code by itself is not a terribly meaningful measurement, it can be used along with other measurements to provide some insight. For example, if we look at the growth of lines of code over time in Asterisk trunk, we can see how the rate of growth in the size of the code base has continued to increase over the project’s lifetime.

This growth has not come from one single person. However, if someone can teach me how to exponentially increase my productivity over time, I would love to talk to you! A lot of people contribute to Asterisk. Among those writing code for Asterisk, there is a select group that has direct access to make changes to the source (committers). At the beginning of the project, there was effectively one committer, Mark Spencer. As the project has grown, we have worked very hard at scaling our development community such that we can process more code. The number of committers today is over 50 (with the number of contributors much higher than that). The following graph demonstrates lines of code over time by committer and helps demonstrate how this has changed over the life of the project.

There are a number of ways we can take a look at the size of the group of people contributing code to Asterisk. One such way is to look at how many people have signed the contributor license agreement over time. Previously, this was a written form handled via fax. As of a couple of years ago, we now track these license agreements electronically. From this data, we can see that over 800 people have signed up to contribute to Asterisk over the past couple of years.

Asterisk Release Policy Updates

Release policy is effectively the agreement between the developer and user communities on how and when updates will be delivered. There are needs to meet on both sides. The development community wants to continually improve the project while the user community needs stable software that continues to operate in a defined manner.

The history of Asterisk releases begins 10 years ago. Here are some dates on releases during the first half of the project’s lifetime:

• 0.1 – December 1999
• 0.2 – September 2002
• 0.3 – February 2003
• 0.4 – April 2003
• 0.5 – September 2003
• 0.7 – January 2004
• 0.9 – April 2004

If you’re reading this and have been using Asterisk long enough to remember these releases, cool! That means you were involved in the project longer than me. I got involved in the Asterisk project in the middle of 2004. By the first Astricon in the Fall of 2004, Mark Spencer decided to release Asterisk 1.0 and asked me to maintain it.

• Asterisk 1.0
  • Fall of 2004
  • Regular 1.0.X updates with bug fixes only
  • Eventually went into security only maintenance, and is no longer maintained today

Asterisk development continued and over the next couple of years and we released Asterisk 1.2 and Asterisk 1.4. We made some changes to development processes regarding how and when to port bug fixes and how they were merged between releases. However, the release policies regarding what went into updates and roughly how often they were released didn’t change.

• Asterisk 1.2
  • Released November of 2005
  • Still updated with security fixes only
• Asterisk 1.4
  • Released December of 2006
  • Still fully maintained

At this point in the project, we had identified some problems, and decided we’d like to try some changes to improve our releases. We decided to modify our approach with releases for the Asterisk 1.6.X series. Our goals were:

1. Release a feature update as 1.6.X every 3 months or so.
2. Deliver small feature increments
3. Maintain backwards compatibility.
4. Maintain each increment for at least one year with regular bug fix updates labeled as 1.6.X.Y.

The problems we had identified that we wanted to address were:

1. Asterisk 1.4 took off to a rough start. It took longer to stabilize this code than it really should have.
2. The way we were managing our releases meant that the time to market on new features was longer than we liked.
3. Some of our policies regarding how changes were implemented meant that upgrades between major versions were sometimes painful.

Some of these issues we worked on addressing with the 1.6.X release plans. Others we have worked in by improving development processes.

1. Release quality
   • We have improved our release candidate processes. We now do a much better job at ensuring that releases, including bug fix updates, get more testing before they are published.
   • We decided that we wanted to shorten our major release cycle so that when it was time to test a new feature set, the target was more manageable.
   • We have deployed tools and implemented processes for more strict code reviews on changes before they are merged.
   • We have worked to educate the development team on best practices and how to avoid common problems encountered in Asterisk.
2. Long time to market on features
   • By shortening the release cycle, we made it such that features would be available sooner than they would have been before.
3. Painful upgrades
   • We have come to embrace backwards compatibility much more aggressively than in the past. Even if there is a newer better way to do something, we keep the old way around if we can.
   • We document every single change that users upgrading between versions should be aware of in UPGRADE.txt.

In reality, Asterisk 1.6.X has not worked out exactly as we had envisioned it. While we had planned on doing updates every 3 months, it has been closer to every 6 months.

• Asterisk 1.6.0 – October 2008
• Asterisk 1.6.1 – April 2009
• Asterisk 1.6.2 – Q4 2009

Another interesting point is that we envisioned the changes between 1.6.X and 1.6.X+1 to be much smaller than it has been in reality. The longer release cycle and the growth in the development community has made it such that the changes in Asterisk between updates are very significant.

With all of that history out of the way, we are now up to present time. After reviewing how our Asterisk 1.6.X plans have worked out, we have decided to propose some new updates to our release policies. The first change is to introduce the concept of a release type for feature releases. The purpose of this is to give users a clear understanding up front how long a major release of Asterisk will be maintained. There are two release types: standard and LTS.

1. Standard
   • Fully maintained for 1 year
   • Security fixes only for 1 additional year
2. LTS
   • Fully maintained for 4 years
   • Security fixes only for 1 additional year

The other change to the release policies that we would like to make is to switch back to our original numbering scheme. We started giving feature updates 1.6.X labels since the changes between each were supposed to be much smaller than a jump between 1.0 and 1.2, or 1.2 to 1.4, etc. So, instead of the next release being called 1.6.3, we’ll just call it 1.8 to better reflect what it really is.

Here is the anatomy of an Asterisk version number:

<Concept>.<Feature>.<Minor>[.Patch]

• Concept – Something close to a complete rewrite would be required to change this
• Feature – An update to this number indicates a change to the feature set
• Minor – This number reflects an update with bug fixes only
• Patch – Trivial Changes (usually for a security release)

Here is a table of releases, their type, and associated dates:

Asterisk 1.8 is currently targeted for Q2 of 2010, so we still have time to make changes. Feel free to post your comments here or on the Asterisk-dev mailing list if you have feedback!

Asterisk Features

A whole lot of code has been written in the last year. Some of it is very visible to users, while other changes are architectural in nature and provide a boost under the hood. Here is a list of some cool things that have been worked on. For a full list of new features, see the CHANGES file in Asterisk trunk.

1. Fax Support Improvements (All versions)
   • T.38 negotiation support in Asterisk has been completely rewritten to work much better.
   • Full support for T.38 send/receive (gateway support in progress)
   • Configuration options added to improve interoperability with non-compliant T.38 implementations.
   • Many changes have been made to chan_dahdi and DAHDI to improve the stability of FAX over PSTN.
   • Hundreds of hours have been put in to rigorous testing of FAX support in Asterisk.
2. XMPP/Jabber Integration Improvements (1.8+)
   • The JABBER_RECEIVE() function has been added to allow you to receive XMPP messages in the Asterisk dialplan.
   • There is code in testing to use XMPP as a transport for distributed events. This will allow Asterisk servers peered via XMPP to share device state and MWI information.
3. Connected / Redirecting Party ID Support (1.8+)
   • Full control over connected party ID updates. Phone displays will now be correct after transfers!
   • Redirecting party ID support means you can see when your call has been forwarded, or when you receive a call that has been forwarded.
   • See Mark Michelson’s AstriCon presentation video for more information on this functionality.
4. Call Completion Supplementary Services (Hopefully 1.8+)
   • “Camp on extensions”
   • Support for both CCNR and CCBS
   • Generic support in Asterisk, as well as support for doing CCSS over SIP and ISDN
5. Calendar Integration (1.8+)
   • Support for iCal, CalDAV, Exchange 2003
   • Use calendar information as a device state provider
   • Access calendar state in the dialplan
   • Originate calls based on calendar entries.
   • See Terry Wilson’s AstriCon presentation video for more information on this feature.
6. Security Events Framework (1.8+)
   • This infrastructure allows Asterisk components to report events that are potentially related to attacks on the system.
   • This also includes a module that will write security events out to a log file in a defined format that can be used by outside applications.
7. SIP TCP/TLS Improvements (1.6.X+)
   • There has been a lot of additional testing on this functionality.
   • The related configuration options have been improved.
   • There have been successful reports of integration with Microsoft OCS.
   • There is continued work going on to make this functionality more robust under adverse network conditions.
8. Updated PSTN Support
   • There have been many improvements made to BRI support via mISDN in all supported versions of Asterisk.
   • Native BRI support in LibPRI and chan_dahdi has been added to Asterisk 1.6. Features are being actively worked on in this code.
   • MFC/R2 signaling support has been added to chan_dahdi by using libopenr2 in Asterisk version 1.6.2 and later.
   • SS7 support was added in Asterisk 1.6.0 and it continues to mature.
9. Core Bridging API (1.6.2+)
   • It is now much easier to write Asterisk modules that bridge channels.
   • This new bridging infrastructure can conference channels together without DAHDI installed on the system.
   • A new conferencing application (ConfBridge) has been provided that allows conferencing using this new infrastructure.
10. Core Timing API (1.6.1+)
    • Support for timing in Asterisk has been abstracted instead of relying on DAHDI timers directly. So, DAHDI is no longer required as a timing source for Asterisk.
11. Core Channel API Update (1.8+)
    • The management of the most widely used data structure in Asterisk, ast_channel, has been rewritten. It now uses the astobj2 object model. The result is that less locking is needed on this data, and code that does channel iterations or lookups is much more efficient.
12. Core Scheduler API Update (1.6.2+)
    • The scheduler API is used in Asterisk when components need to schedule some task to happen in the future. For example, this is used for message retransmissions and timer expirations. It is used very heavily in Asterisk channel drivers. The scheduler API went through two rounds of performance improvements in Asterisk 1.6 (1.6.1 and again in 1.6.2). While doing profiling, the results of this work show the scheduler going from near the top of the CPU consumers down to completely off of the radar.

Summary

A lot has happened in the last year. Our development community continues to grow at a healthy rate. Our release processes are changing to better suit the needs of both users and developers. A lot of really good code is being written.

I am really looking forward to the next year. I can promise you now that it is going to be even more exciting than this one.

Thanks for reading.

• News
• Comments(11)