Asterisk 12.0.0-alpha1 Now Available!

Home » Asterisk Users » Asterisk 12.0.0-alpha1 Now Available!
Asterisk Users 2 Comments

The Asterisk Development Team is pleased to announce the first alpha release of Asterisk 12.0.0. This release is available for immediate download at

All interested users of Asterisk are encouraged to participate in the Asterisk 12 testing process. Please report any issues found to the issue tracker, All Asterisk users are invited to participate in the #asterisk-bugs channel to help communicate issues found to the Asterisk developers. It is also very useful to see successful test reports. Please post those to the asterisk-dev mailing list (

The first preliminary test release of Asterisk 12 is an alpha release, not a beta release. Due to the size and scope of the changes in Asterisk 12, both an alpha test cycle and a beta test cycle will be performed. While users are encouraged to participate in both test cycles, users who choose to participate in the alpha release testing should understand that an alpha release has not undergone all of the community testing that a beta release goes through.

Asterisk 12 is the next major release series of Asterisk. It will be a Standard release, similar to Asterisk 10. For more information about support time lines for Asterisk releases, see the Asterisk versions page:

For important information regarding upgrading to Asterisk 12, please see the Asterisk wiki:

A short list of some of the new major features includes:

* A new SIP channel driver and accompanying SIP stack named chan_pjsip has been
added. This new channel driver is based on the PJSIP SIP stack by Teluu. It
includes support for the vast majority of features currently in chan_sip,
as well as numerous architectural improvements that alleviate pain points
present in the legacy SIP channel driver. Users who wish to use the new SIP
channel driver are encouraged to read the instructions on installing and
configuring PJSIP for Asterisk on the Asterisk wiki at Detailed instructions on configuring
the new SIP stack in Asterisk can be found on the Asterisk wiki as well, at Test reports of successful use of
chan_pjsip, with endpoint details, in addition to bug reports, are most

* The Asterisk RESTful Interface (ARI) has been added. This interface lets
external systems harness the telephony primitives within Asterisk to develop
their own communications applications. Communication with Asterisk is done
through a REST interface, while asynchronous events from Asterisk are
encoded in JSON and sent via a WebSocket. More information on ARI can be found

* Major standardization of the Asterisk Manager Interface and its events have
occurred within this version. In particular, the names of Asterisk channels
no longer change and are stable throughout the lifetime of the channel.
More information on the changes in AMI can be seen in the AMI 1.4
Specification at

* All bridging within Asterisk is now performed using the Asterisk Bridging API,
which previously was only used by the ConfBridge application. This affords
Asterisk users greater stability, and has resulted in the abstraction of
channel masquerades, renaming, and other internal implementation details. It
also allows for the seamless transition between two-party and multi-party
bridges using core features.

And much more!

More information about the new features can be found on the Asterisk wiki:

A full list of all new features can also be found in the CHANGES file.

For a full list of changes in the current release, please see the ChangeLog.

Thank you for your continued support of Asterisk!

2 thoughts on - Asterisk 12.0.0-alpha1 Now Available!

  • I’ve been looking occasionally at how 12 work was going and I’m curious about how AMI and ARI relate. Do they effectively expose the same functionality, just offering a different style of communication? Or is there be a reason to prefer one over the other beyond the protocols used?

  • The general use cases for each protocol are a bit different, although I
    think some people will find areas of overlap as well.

    The goal of ARI is to allow for externally controlled communications applications. Unlike AGI or AMI, you wouldn’t use ARI to execute dialplan logic or Asterisk applications; you would use ARI to replace a default Asterisk dialplan application with one that performs your own business logic and rules. That’s why ARI exposes a lot more of Asterisk’s communication primitives and lets you control them in a fine grained fashion – if you want to write your own complex IVR or Queue, you need access to asynchronous media operations, various types of bridges, and control over multiple channels at the same time.

    AMI, at its heart, is a call control protocol. While you can do some of what AMI does using only ARI, ARI requires handing all of the channels over to the external application through the Stasis dialplan application. If all you used was ARI, you’d lose some of the power of the dialplan. Likewise, while you can do some of what ARI does via a combination of AMI/some AGI
    variant, the result can be somewhat klunky and difficult to manage –
    particularly for complex bridging scenarios.

    Hope that helps!