Migrating from chan_sip to PJSIP — what changes, what breaks, what improves

Asterisk® ships two SIP channel drivers: chan_sip (legacy, deprecated, removed in Asterisk 21+) and chan_pjsip (modern, the default since Asterisk 12). Most production deployments have already migrated; if you haven't, this article explains what changes and how to do it without breaking active service.

Why migrate

• chan_sip is gone in Asterisk 21. You'll eventually be forced to migrate; doing it on your schedule is easier.
• PJSIP handles modern SIP scenarios better: better TLS support, multiple registrations per AOR (e.g. desk phone + softphone for same extension), better NAT traversal, more reliable WebSocket transport for WebRTC.
• Per-endpoint configuration in PJSIP is cleaner than chan_sip's flat "peer" model.

What changes structurally

Migrating on FreePBX

FreePBX has dual-driver support: extensions and trunks can be either chan_sip or chan_pjsip. The migration is largely a per-extension settings change.

1. Backup first. Take a FreePBX backup module snapshot + a full disk snapshot via the LYLIX portal.
2. Move SIP listening ports. chan_pjsip defaults to 5060 too — you can't have both on the same port. Either:
   • Move chan_sip to 5160, leave chan_pjsip on 5060.
   • OR move chan_pjsip to 5160, leave chan_sip on 5060.
   Settings → Asterisk SIP Settings has both knobs. Move whichever one your existing endpoints are configured for.
3. Per extension, set Tech = PJSIP (was: SIP) under Applications → Extensions → [ext] → Advanced.
4. Reconfigure the phone to use the PJSIP port + the same extension/password. The phone re-registers via PJSIP; chan_sip extension is now obsolete.
5. Per trunk, change driver from SIP to PJSIP. Carrier configuration typically unchanged — same hostname, same auth.

Migrate one extension/trunk at a time. Validate calls work end-to-end after each before moving the next.

What breaks (and how to fix)

• Custom dialplan referencing SIP/<peer>. Update to PJSIP/<endpoint> after migration. Grep for SIP/ in /etc/asterisk/extensions_custom.conf.
• chan_sip nat=force_rport handling differs from chan_pjsip's rewrite_contact + force_rport. NAT-traversal config doesn't always translate 1:1. Test from a NAT'd phone (mobile softphone over cellular) early.
• AMI events have slightly different field names. Anything that consumes AMI (Vicidial®, monitoring scripts, CRM integrations) may need updates.
• chan_sip's "type=friend" combines peer+user. PJSIP separates these as endpoint + identify. Extensions registering FROM the same network as the PBX may have unexpected identify-matching that lets calls in without auth. Audit your endpoints' identify sections.

The friction of running both

You can keep both drivers loaded indefinitely. Some operators do this for years as they slowly migrate. Costs:

• Two SIP listeners — twice the surface area for attackers.
• Two sets of CLI commands to remember.
• Debugging gets harder — you have to check which driver a given call is using.

Recommended: pick a migration window, do all the moves over a weekend, decommission chan_sip once everything's confirmed working. Lingering chan_sip is technical debt.

Validation after migration

pjsip show endpoints              # all endpoints listed?
pjsip show registrations          # trunks registered?
core show channels                # test calls coming through PJSIP?

# Watch a registration attempt in detail
pjsip set logger on
# (have the phone re-register)
pjsip set logger off

Once you're satisfied no chan_sip endpoints remain in active use, comment out the chan_sip module load in modules.conf and restart Asterisk. If something breaks, uncomment and restart — easy revert.

For new deployments

Don't even start with chan_sip. New FreePBX installs default to PJSIP for everything; new bare-Asterisk installs should configure pjsip.conf from day one. chan_sip exists only for legacy migration.