Asterisk 12 Part I: In The Beginning…

By Matt Jordan

Asterisk 12 is just around the corner, and over the next few months we’ll have a series of blog posts covering the major new features and changes in this upcoming release of Asterisk. To get started, we’d like to review the beginnings of Asterisk 12 and explain how the Asterisk developer community planned what would go into this new release.

Every year, developers from the open source community meet just before AstriCon (we call it AstriDevCon) to plan the major goals for the next version of Asterisk. Last year was no exception, and on October 22, 2012, approximately 40 developers sat down to discuss the goals for Asterisk 12. The assumption going into the meeting was that while Asterisk 11 was a Long Term Support (LTS) release, Asterisk 12 would be a standard release, and thus allow more flexibility in what we could accomplish.

Over the course of a day, everyone in the room discussed the major areas ripe for improvement in Asterisk. We discussed what features the community needed; what use cases Asterisk could better handle with different capabilities; and what parts of Asterisk we felt needed to be worked on to make it an even better communications framework. It was clear early on that the community felt that development efforts should focus on two keys areas in Asterisk – the SIP channel driver and Asterisk’s APIs.

The SIP channel driver in Asterisk has grown organically over the years, which has resulted in a lot of great features and capabilities. However, after nearly a decade of organic growth, it has become not only difficult to maintain but also difficult to safely extend. Our discussion around the SIP capabilities in Asterisk got ambitious rather quickly – we weren’t fifteen minutes into AstriDevCon before Jared Smith of BlueHost asked, “I think the biggest question that no one else dares ask is thisIs it time to write a new SIP channel driver?” After some significant discussion, developers decided that yes, Asterisk 12 is the right time to provide a new SIP stack in Asterisk!

The way in which Asterisk’s APIs have grown is similar to the SIP channel driver. While many new features have been added over time that make Asterisk a powerful engine for communication, Asterisk isn’t always consistent in how it represents its channels to the outside world. This can force external systems to do extra work when handling various edge cases. As Max Schroeder of STARFACE GmbH said, “API syntax doesn’t worry me; the real problem is figuring out the state of the channels.” In order for external systems to use Asterisk to its full capabilities, the developers committed to making sure that external systems have a clear, consistent model of how Asterisk behaves.

Thus, at the end of the day, after much discussion, we as a group set two major goals for Asterisk 12:

  • Provide a better SIP stack in Asterisk – one that is more maintainable and extensible than the existing SIP stack.
  • Provide consistency and flexibility in Asterisk APIs, so that it is easier to use Asterisk as the engine to power your communications system.


As a developer community, we have worked hard over the past year to meet those two goals, and over the next few months we’ll explore just how we did it in Asterisk 12.

To learn more about what exactly has been improved in the APIs and SIP stack, and what that means for users of Asterisk, continue reading Asterisk 12: Part II.

Related Posts

There Are 4 Comments

Add to the Discussion

Your email address will not be published. Required fields are marked *

About the Author

Matt Jordan

Matt Jordan joined Digium in July of 2011. Since joining Digium, he has served as lead on the Asterisk open source project, as an Engineering Manager, and as Director of Technology. In June 2016, Jordan was named CTO of Digium. In this role, Jordan is responsible for technology and architectural decisions used in the Company’s product and service offerings.Jordan holds a Bachelor of Science degree in Computer Engineering from Michigan Technological University, and a Master of Science degree in Electrical Engineering from Louisiana State University and multiple patents.

See All of Matt's Articles