Summary:
Many IT teams treat an Asterisk upgrade like a standard Linux package update. They run the script, restart the service, and wake up to a silent phone system. The reality is that moving from Asterisk 16/18 to 20/21 involves fundamental architectural shifts (specifically the removal of chan_sip and app_macro).
This blog details the technical pitfalls of in-house upgrades, including ‘can't connect to Asterisk after upgrade’ errors, PJSIP thread pool misconfigurations, and the hidden ROI of hiring Asterisk consulting services versus risking downtime.
If you are running Asterisk 13, 16, or 18, you are likely sitting on a ticking time bomb. Asterisk 18 reached End of Life (EOL) in October 2025, leaving your system vulnerable to security exploits.
Naturally, the solution seems simple: Upgrade to Asterisk 20 (LTS) or 21.
But for many organizations, this upgrade fails. It doesn’t fail because the software is bad; it fails because the architecture has changed underneath your feet. The dialplans you wrote in 2018 are no longer valid syntax in 2026. The SIP driver you relied on (chan_sip) effectively no longer exists.
When generalist IT teams attempt this upgrade, they often encounter the “Zombie PBX” scenario: The service starts, the dashboard is green, but no calls can connect. Here is why this happens and why emergency Asterisk support calls are skyrocketing.
Why is Asterisk Failing to Start After Upgrading to 21?
For over a decade, app_macro was the standard way to write reusable logic in Asterisk dialplans (e.g., “Macro-Voicemail”).
- The Change: In Asterisk 21, app_macro has been completely removed. It was deprecated in 16, but it still worked. Now, it is gone.
- The Failure: If your extensions.conf or AGI scripts contain a single Macro() call, the dialplan parser will fail, or the call will silently hang up when it hits that line.
The Fix: Migration to GoSub
You cannot just find-and-replace. You must rewrite your entire logic stack to use GoSub().
- Old: exten => 100,1,Macro(stdexten,SIP/100)
- New: exten => 100,1,GoSub(stdexten,start,1(PJSIP/100))
A generalist engineer won’t catch this until the first user tries to check their voicemail and gets dead air.
Database Schema and Alembic Failures
Modern Asterisk (especially when used with FreePBX or custom frontends) relies heavily on database schema management.
- The Issue: Asterisk 16 to 20 introduces significant changes to the CDR (Call Detail Records) and CEL (Channel Event Logging) tables.
- The Failure: The migration tool (Alembic) attempts to alter a table that has millions of rows. The operation times out or locks the table. Asterisk starts, but it cannot write CDRs. Your billing system stops tracking calls, but nobody notices for three days.
The Fix
A specialist will perform a “Dry Run” migration on a staging database, prune the CDR history before the upgrade, and manually apply schema patches to ensure the live migration completes in seconds, not hours.
💡 Our Expert Tip
One of the most frustrating ‘can't connect to Asterisk after upgrade’ issues is caused by modules.conf. In older versions, Asterisk was forgiving about load order. In version 20+, if res_pjsip tries to load before res_sorcery, the service will crash on boot.
So, you need to explicitly define preload => res_odr.so and ensure your autoload settings are clean. Don't carry over the 10-year-old modules.conf file to a new install.
Why Does Call Quality Decrease After Upgrading the Asterisk Version?
You upgraded to Asterisk 21 to get “better performance,” but now your users are complaining about robotic audio and jitter. Why?
It’s the threading model mismatch.
- Legacy (chan_sip): Was monolithic. It handled calls in a way that was inefficient but predictable on older hardware.
- Modern (PJSIP): Uses a highly efficient thread pool architecture. However, it requires tuning.
If you migrate to PJSIP using default settings on a high-core server, you might encounter “Thread Starvation.” PJSIP might be waiting for a worker thread to free up just to process a simple “BYE” packet, causing the RTP stream to jitter while the system waits.
The Fix: Tuning pjsip.conf
You must manually calculate and configure the threadpool parameters based on your CPU cores and call volume.
Without experienced Asterisk consulting services to profile your traffic and tune these values, your “optimized” upgrade may perform worse than your decade-old server.
Did You Know?
Running Asterisk 18 or older past its End of Life (October 2025) means operating without security patches.
Hackers actively use automated scanners to find unpatched chan_sip vulnerabilities, launching toll fraud attacks that can cost businesses thousands of dollars in a single weekend.
In-House Asterisk Upgrade vs. Hiring a Specialist
Many CTOs hesitate to hire a specialist because “we have smart Linux guys.” But Linux skills are not VoIP skills.
- In-House Scenario: Your lead engineer spends 40 hours researching PJSIP migration. They attempt the upgrade on Friday night. It fails. They spend Saturday and Sunday debugging res_pjsip errors.
- Cost: 40 hours prep + 20 hours OT + potential Monday downtime.
- Specialist Scenario: An Asterisk architect has a pre-built automation script that converts sip.conf to pjsip.conf and detects app_macro usage instantly.
- Cost: Fixed project fee (usually a fraction of the potential downtime cost).
In-House vs. Specialist Asterisk Upgrade Risk Profile
Why You Need Asterisk 21 for AI Integration
Beyond security and stability, the biggest reason to upgrade is AI readiness.
Legacy versions of Asterisk were built for simple voice bridging. Modern versions are built to be the “Voice Gateway” for AI engines.
- Real-Time Transcription: New modules allow you to fork audio streams directly to AI Speech-to-Text engines via WebSockets, enabling live agent assist.
- VoiceBots: If you plan to deploy a conversational AI bot, Asterisk 21’s ExternalMedia allows for seamless, low-latency audio exchange that older versions simply cannot handle without crashing.
Sticking with older Asterisk versions doesn’t just risk security; it locks your business out of the AI revolution.
Upgrading Asterisk is no longer a task for a generalist sysadmin. The move to PJSIP, the removal of legacy macros, and the strict threading requirements of modern VoIP engines make it a specialized engineering project.
If your current system is stable, you might be tempted to stay on version 16. But stability without security is a fallacy. The cost of a toll-fraud attack on an unpatched system will always exceed the cost of a professional upgrade.
Is your Asterisk upgrade stalled? Contact our Asterisk architects!