Install Asterisk 22 LTS: a controlled source-build workflow

Choose a supported line and pin the artifact

This workflow is for a standalone source build, not a FreePBX upgrade. Asterisk 22 remains the current stable LTS line: the project lists full support through October 16, 2028 and security-fix maintenance through October 16, 2029. Asterisk 23 is a shorter-lived standard line, while Asterisk 24 was still a pre-release at this October 10 review. Do not turn a release candidate or the moving asterisk-22-current.tar.gz link into an unrecorded production input.

On October 10, 2026, 22.11.0 remained the latest final 22.x release listed by the project, while 22.12.0-rc2 was explicitly a release candidate. The project published parallel second candidates for 20.22.0, 23.6.0 and 24.0.0 on October 8; their existence did not promote any branch to a new final point release or move 24.x out of pre-release status. Record the exact filename, download URL, retrieval date and project-published checksum or signature that you verified. Recheck the release and security pages at deployment time: a dated editorial observation is not an update policy.

Isolate the host and inspect prerequisites

Use a disposable host on a currently supported Linux distribution and keep management access restricted to the lab. Record the OS release, architecture, repository state and intended Asterisk features. The project supports only a subset of the platforms on which Asterisk can compile, and warns that compiler changes can stop older releases from building.

The bundled contrib/scripts/install_prereq can report or install dependencies, but it is a package-changing script rather than a harmless Asterisk check. Update the host through its normal package manager, inspect the script, run its test mode first and preserve the result. The install mode can install dependencies for many capabilities; install-unpackaged adds source tarball dependencies. Use neither blindly on a shared host.

Configure, select and compile before installing

Run ./configure in the extracted, verified source tree and stop if it reports a required dependency failure. Re-run it after resolving the dependency. Use Menuselect to capture the intended modules, codecs, sounds and optional components; a successful configure does not mean every desired feature will be built. If cached configure evidence may be stale, the documented make distclean target clears it, but that is destructive to generated build state.

Compile before elevating privileges. make install writes binaries, modules and other system files and can build implicitly, but the project recommends running it after a successful compile. Do not install over a working PBX until the existing package owner, configuration backup, maintenance window and rollback path are known.

./configure
make menuselect
make
# Only after review and a successful lab build:
sudo make install

Keep configuration and startup separate

make samples overwrites configuration files under /etc/asterisk; it is not an upgrade helper. On an empty lab, decide whether samples provide useful study material or whether a minimal reviewed configuration is safer. Never use samples as proof of secure defaults. The documented make config target installs startup scripts, but service-manager integration, service identity, paths and permissions still require host-specific review.

Record the intended binary and module paths, configuration directory, runtime user and startup unit. Before enabling startup, confirm the service does not inherit an unintended root identity, public listener or stale configuration. Keep SIP and management interfaces inside the lab boundary until access controls and call permissions have their own acceptance record.

Prove installed, running and callable as separate states

A completed compile proves only that the selected source built. make install proves that files were written, not which binary a service manager will start. After an intentional start, use the running Asterisk CLI to record core show version, loaded PJSIP modules, active listeners, configuration errors and the service identity. Reconcile that output with the pinned artifact and startup unit before calling the version accepted.

Then create only restricted internal test identities. Exercise call setup, audio in both directions, DTMF if required, hangup, restart and a configuration rollback. A successful two-extension call does not establish trunk interoperability, emergency calling, capacity, security or production readiness. Preserve the checksum record, Menuselect choices, dependency manifest, configuration backup, service definition, acceptance results and rollback trigger. No installation or call was performed for this guide.

Recheck the lifecycle before selecting an artifact

The release-lifecycle guide records why Asterisk 22 remained the current stable LTS on October 10, 2026 while Asterisk 24 remained pre-release. Resolve the current final release, product or distribution support and exact point version before downloading; a future release date, branch or documentation tree is not an installable acceptance target.

Match installed modules to the running build

The module capability diagnostic begins with package ownership, module directory and exact build rather than assuming every shared object is interchangeable.

Record the exact AMI action inventory after installation

The AMI command-inventory guide keeps package, branch, module registration and user-visible actions as separate deployment evidence.

Keep lifecycle, artifact and built capability separate

Use the refreshed release lifecycle guide to record the displayed support label and scheduled dates separately, then trace each required module from branch documentation through dependencies, build selection, installation and runtime registration.