Asterisk 12 Part II: SIP and APIs

By Matt Jordan

In a previous blog post, we discussed the development goals for Asterisk 12 – namely a new SIP stack and improved APIs – and how the Asterisk community arrived at those goals. Today, we’ll provide an overview of the new SIP stack and API improvements, as well as what it all means for Asterisk users.

New SIP Stack

When we started down the path of rewriting Asterisk’s SIP channel driver, our first task was to decide whether to write a new SIP stack completely from scratch or start with a SIP stack provided by a third-party. As tempting as it was to write a brand new stack from the ground up, Asterisk is first and foremost a communications framework – not a SIP stack! Because there are many great open source SIP stacks to choose from, the community felt that it did not make sense for Asterisk to reinvent the wheel by writing our own. So, after much discussion on the asterisk-dev mailing list, the community decided that the new SIP functionality in Asterisk should be built on Teluu‘s PJSIP SIP stack. PJSIP is a fantastic open source SIP stack used in a variety of platforms and devices. At Digium, we had previously used it on the Asterisk SCF project – so using it in Asterisk seemed like a natural choice. It would also allow us to leverage the experience from the SCF project for Asterisk’s benefit.

In a departure from previous versions of Asterisk, the new SIP functionality in Asterisk 12 has been designed in a very modular fashion. Rather than writing a single channel driver, Asterisk 12 now provides a set of APIs in separate resource modules, all of which are built on top of the PJSIP SIP stack. While this includes a SIP channel driver – chan_pjsip – it also includes many other libraries that allow other functionality – such as device state, messaging, and MWI. These modules are all built independently of the media handling. The end result of this effort is SIP functionality in Asterisk 12 that can better scale when compared to previous versions; is more flexible in user deployments; and can be more easily extended to meet the future needs of the Asterisk community.


Our discussion at AstriDevCon resulted in two objectives  we wanted to meet for Asterisk’s APIs:

  1. We wanted to make it easier for consumers of the APIs to know what occurred during a call, regardless of the complexity of the scenario.
  2. We wanted to make it easier to write your own telephony applications using the APIs, such that users don’t have to rely solely on the application modules delivered with Asterisk for functionality.

These changes required major work not only in Asterisk’s APIs but also in the core of Asterisk. To support the APIs, Asterisk 12 features a brand new bridging framework that allows for safe and consistent manipulation of channels within bridges, as well as a new internal message bus that propagates state between the various interfaces.

For AMI, these core changes let us improve the semantics so that channel names remain the same throughout the lifetime of a call – regardless of what happens to the channel during the call. The standardization of what happens to a channel in Asterisk also allowed us to provide consistency in what AMI conveys in its events. This makes AMI a more robust and consistent call control protocol.

Historically, building your own application was usually done using a combination of the Asterisk Manager Interface (AMI) and one of the variants of the Asterisk Gateway Interface (AGI). Rather than re-purpose AMI or AGI, we decided we needed a new protocol that provided a way for people to write their own telephony applications in a language of their choosing that could make use of the primitives directly in Asterisk.

Asterisk 12 thus contains a brand new interface – the Asterisk REST Interface (ARI). ARI exposes the raw telephony primitives in Asterisk – channels, bridges, endpoints, and the like –  allowing a developer to control them directly through a RESTful interface. External applications can build what amounts to their own dialplan application, manipulating multiple channels, bridges, and other objects in Asterisk all through a single interface using a familiar protocol. Because the interface uses HTTP and WebSockets, any language can be used to develop the external application. This opens up the power previously reserved for Asterisk developers to all developers, regardless of the language they choose to develop in.

Even with all of these fundamental changes in Asterisk’s core, a new SIP channel driver, and all of the cool new capabilities being offered, Asterisk is still Asterisk  – and that’s a great thing! Asterisk 12 simply lets application developers and users make better use of the internal communications building blocks, making it easier for them to build the communications platform they need to power their business.

In the next blog post, we’ll look at the changes to release policies for Asterisk 12 and how it will improve deployments.

Related Posts

There Are 3 Comments

  • james.zhu says:

    keep moving up. very good!

  • Asterisk Applications says:

    Asterisk application can be configured as the core of an IP or hybrid PBX, switching calls, managing routes, enabling features, and connecting callers with the outside world over IP, analog (POTS), and digital (T1/E1) connections.

  • Anders Wallin says:

    Really excited to see the pjsip stack in action. Eagerly awaiting Asterisk 13. But how will pjsip perform? Will it do better than chan_sip when it comes to handle lots of registrations? Perhaps we will now see a day when we can just use Asterisk and don’t have a SIP Proxy in between?

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