I’ve noticed a trend of people and companies looking at moving away from other projects towards Asterisk. For those returning to Asterisk after some time, many have this vision in their mind of Asterisk from many years ago, so I thought I’d put together a blog post going through some items to show how the Asterisk of today isn’t like it was.
Predictable Release Schedule
Asterisk has an incredibly predictable, reliable, and documented release schedule. Every 4-6 weeks we do release candidates of all currently supported branches. If, after testing, no issues are encountered — prompting more release candidates a week later — we do the full releases.
Yearly, in October, we do a new major release with the release candidate having occurred the month prior. This predictability is great for planning for users of Asterisk, as you can work it in to your own scheduling. (At the end of the post is the current timeline for Asterisk version 20 LTS.)
LTS Releases and Standard Releases
There are both long term supported and standard releases of Asterisk.
A long term supported release provides four (4) years of bug fixes with one (1) year afterwards of security fixes. Combined, that’s five (5) years of security support for each new LTS release.
A standard release provides one (1) year of bug fixes and one (1) year of security releases. A standard release allows us to have more time for testing of major changes that we don’t feel comfortable immediately placing in a long term supported release. In practice, they are still extremely stable and many people try them out and use them in production.
Security Releases
We do security releases as needed based on the security reports we receive. Sometimes these releases may include just a single fix, or potentially multiple. Security releases are based on the last release and only include changes to resolve the security issues. They do not include any other changes, making them safer to update to.
Stability
A huge focus over numerous years has been on the stability of Asterisk. In prior times people would avoid upgrading, be it between minor or major versions, due to issues encountered. This is no longer the case for the vast majority of users. Many upgrade without a second thought. Stability has become the norm for Asterisk. This includes at both low and high usage – such as with thousands of endpoints and concurrent channels.
Performance
Performance has also been a focus of Asterisk. Asterisk can now scale beyond what it could before, to thousands of endpoints and concurrent channels as mentioned before. As always, you need to do proper testing for your usage as there are numerous variables that can change performance characteristics. This continues to be a focus.
New Features and Functionality in Current Branches
Previously — for many years — Asterisk would not allow new features or functionality in current branches. This meant that people had to wait for the next major release in order to get new things.
This is no longer the case.
We now accept new features and functionality in current branches, as long as they do not break existing functionality and are backwards compatible. This gets the functionality to users fairly quickly — within 4-6 weeks, according to our release process.
One recent example of new functionality in current branches is our highly sought after Media Over Websockets implementation for easier AI integrations with Asterisk. The MOW work was officially included on October 15th, 2025, for releases 23.0.0, 22.6.0, 21.11.0 and 20.16.0.
Certified Branches
Certified Branches (CBs) are for users who desire stability with only security updates and limited bug fixes, with no new features or functionality. These CBs start as mature, well-tested branches of the current LTS Release. Many household name, large commercial enterprises choose CBs for their in-house deployments.
Community Support
The Asterisk community forum located at https://community.asterisk.org/ is a vibrant and active place with both contributors and users alike. You can post a question or comment and usually there will be a response, perhaps even from myself. š¤
Testing 1-2-3
The Asterisk testsuite is a project that has over one thousand (1,000+) tests covering various parts of Asterisk. From simple things, like registering a phone, to more complex scenarios like attended transfers, there is test coverage that is run on pull requests to ensure that things don’t break. We continue to add to and extend the testsuite as changes occur. This bolsters our confidence in the merging of changes and is another way we reduce issues experienced by users.
Code Review in Groups of Two
All contributions, including from myself, undergo code review. Before being merged they generally need to have at least two (2) people who have reviewed the contribution and approved it. This can slow down how fast contributions are merged and included but we have a strong focus on quality and stability. We do not want to release code that has issues or cause failures for our users. We strive to minimize issues.
ARI
We’ve talked about ARI a lot in previous blog posts, but it stands for Asterisk REST Interface. It is a method by which telephony applications can be written in any language supporting HTTP and Websockets. It provides fundamental building blocks (such as bridging and channel control) that can be used to implement such things as call queues or even Voice AI functionality. If you’re wanting more control over Asterisk to build your own applications or integrate in one, check out ARI.
Continued Development to Meet Industry Needs
Development of Asterisk is not stagnate. It is driven based on the needs of the community, what contributors contribute, what Sangoma needs, and also the industry as a whole. These culminate in the changes we release every 4-6 weeks and our yearly major release.
From an industry perspective, a great example of such a change would be our Geolocation E911 support. We perceived this as an upcoming fundamental requirement several years ago for some users and implemented it. We continue to do this as things evolve and change, ensuring that users have access to the functionality when they need it.
Library Usage
As a project, we take a balanced approach to the usage of outside libraries:
- We use outside libraries where it makes sense, but we don’t fork them.
- We try to keep our required dependencies to a reasonable level.
- We support linking against system libraries but provide a bundled mechanism that downloads and builds the upstream releases with our own patches applied (only if needed).
- We contribute these patches where they make sense and work with upstream to get them included.
An example of this is the PJSIP library. We don’t have our own fork but instead download their releases and apply our patches. This ensures that we don’t diverge from upstream libraries, which eliminates the maintenance overhead and ensures that any patches we do make are shared with the wider upstream library users.
Asterisk 20 Timeline
Asterisk 20 is a Long Term Supported (LTS) release. This timeline shows what happened until now (October 2025) and what the future should hold.
