Back to Blog
AsteriskPJSIPchan_sipMigrationProductionSIP Configuration

Migrating from chan_sip to PJSIPAsterisk 20/21 Production Guide

Everything you need to migrate a live Asterisk deployment from the deprecated chan_sip driver to PJSIP — configuration mapping, endpoint objects, SIP trunk registration, parallel testing, and zero-downtime rollback strategy.

Asterisk 21

chan_sip removed

4 objects

PJSIP peer model

8 hrs

50-ext migration

Zero

downtime possible

By Kaushik Parmar · Founder & VoIP Architect, CelloIP Technologies · March 14, 2026 · 18 min read

How do I migrate from chan_sip to PJSIP in Asterisk?

Migrate by converting each chan_sip peer stanza into four PJSIP objects: transport, endpoint, auth, and aor. Run PJSIP in parallel with chan_sip on a different port, test all extensions for 48 hours, then cut over by disabling chan_sip.

Why You Must Migrate from chan_sip

chan_sip Status

Deprecated in Asterisk 17
Removed entirely in Asterisk 21
Known unpatched CVEs in Asterisk 16/18 LTS
No new features — security patches only
No WebRTC support possible

PJSIP Advantages

WebRTC via WebSocket + DTLS-SRTP
Multiple registrations per endpoint
Per-endpoint TLS/SRTP configuration
Modern RFC compliance
Active development + security fixes

If you're still on chan_sip: You're running unsupported code with known unpatched CVEs. This is a security liability. Migrate to PJSIP before your next compliance audit.

Understanding the PJSIP Object Model

PJSIP splits what chan_sip called a "peer" into four separate objects. This enables capabilities impossible in chan_sip — multiple registrations per endpoint, per-endpoint codec sets, and fine-grained TLS configuration.

[transport]

IP/port/TLS/SRTP settings. Defined once, shared by all endpoints.

[endpoint]

Codec preferences, DTMF mode, media encryption, context.

[auth]

Username & password credentials. Reusable across multiple endpoints.

[aor]

Address of Record — registration target. Supports multiple contacts.

chan_sip → PJSIP Configuration Mapping

chan_sip (sip.conf)PJSIP (pjsip.conf)Notes
[general] bindport[transport] bindSupports multiple transports (UDP, TCP, TLS)
[peer] secret[auth] passwordSeparate auth object — reusable across endpoints
[peer] host / contact[aor] contactSupports multiple contacts per AOR
[peer] codecs[endpoint] allowPer-endpoint codec ordering
[peer] dtmfmode[endpoint] dtmf_moderfc4733 replaces deprecated rfc2833 label
[peer] fromdomain[endpoint] from_domainDirect parameter rename
register =>[registration] typeDedicated registration object
[peer] nat=yes[endpoint] rtp_symmetricSplit into multiple fine-grained options

Migration Process Timeline

1

Audit sip.conf

30 min

Inventory all peers, trunks, and registrations

2

Write pjsip.conf

2–3 hrs

Convert each peer to 4-object PJSIP model

3

Migrate SIP trunks

1 hr

Add registration objects for each trunk

4

Load in parallel

30 min

Run chan_sip + PJSIP on different ports

5

Test every endpoint

48 hrs

48 hours parallel operation, zero issues

6

Cut over

30 min

Disable chan_sip, consolidate to port 5060

Step 1 — Audit Your Existing sip.conf

Before touching pjsip.conf, run these commands to list all active SIP peers and registrations. This gives you the full inventory to migrate.

bashDump all chan_sip peers for inventory
asterisk -rx "sip show peers" > /tmp/sip_peers.txt
asterisk -rx "sip show registry" > /tmp/sip_registry.txt
grep -c "^\[" /etc/asterisk/sip.conf   # count peer stanzas
wc -l /etc/asterisk/sip.conf            # total file lines

Step 2 — Write pjsip.conf (Extension Migration)

For each chan_sip peer, create the four PJSIP objects. A typical extension (phone) migration:

inipjsip.conf — migrating a single chan_sip peer
; Transport (define once, shared by all endpoints)
[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0:5061           ; Use 5061 during parallel migration

; Auth
[auth-1001]
type = auth
auth_type = userpass
username = 1001
password = s3cur3P@ss

; AOR (Address of Record)
[aor-1001]
type = aor
max_contacts = 1
remove_unavailable = yes

; Endpoint (codec, DTMF, context settings)
[1001]
type = endpoint
transport = transport-udp
auth = auth-1001
aors = aor-1001
context = internal
allow = !all,ulaw,alaw,g722
dtmf_mode = rfc4733
direct_media = no

Step 3 — Migrate SIP Trunk (Provider Registration)

SIP trunk migration requires a registration object in addition to the endpoint/auth/aor stack. This replaces the register => line in sip.conf.

inipjsip.conf — outbound SIP trunk with registration
[transport-udp-trunk]
type = transport
protocol = udp
bind = 0.0.0.0:5080

[auth-trunk]
type = auth
auth_type = userpass
username = your_did_number
password = trunk_password

[aor-trunk]
type = aor
contact = sip:sip.provider.com

[trunk]
type = endpoint
transport = transport-udp-trunk
auth = auth-trunk
aors = aor-trunk
context = from-trunk
allow = !all,ulaw,alaw
from_user = your_did_number
from_domain = sip.provider.com

[reg-trunk]
type = registration
transport = transport-udp-trunk
outbound_auth = auth-trunk
server_uri = sip:sip.provider.com
client_uri = sip:[email protected]
retry_interval = 60

Step 4 — Test Before Cutover

Load pjsip.conf without removing sip.conf. Test every trunk and extension in parallel for 48 hours. Only disable chan_sip after confirming zero issues.

bashVerify all PJSIP objects loaded correctly
# Check all objects loaded
asterisk -rx "pjsip show endpoints"
asterisk -rx "pjsip show auths"
asterisk -rx "pjsip show aors"
asterisk -rx "pjsip show registrations"

# Flag any UNAVAILABLE endpoints
asterisk -rx "pjsip show endpoints" | grep -i unavail

# Verify trunk registered
asterisk -rx "pjsip show registrations" | grep -i "registered"

Rollback Strategy

Rollback Steps

  1. 1Re-enable chan_sip.so in modules.conf
  2. 2Disable res_pjsip.so in modules.conf
  3. 3Revert port back to 5060 for chan_sip
  4. 4Reload Asterisk (core restart now)
  5. 5Verify with: asterisk -rx 'sip show peers'

Parallel Port Strategy

:5060chan_sip during migration
:5061PJSIP during testing
:5060PJSIP after full cutover
inimodules.conf — enable PJSIP, keep chan_sip available for rollback
[modules]
; Enable PJSIP (primary)
load => res_pjsip.so
load => res_pjsip_session.so
load => res_pjsip_authenticator_digest.so
load => res_pjsip_registrar.so

; Keep chan_sip available for emergency rollback (comment out post-migration)
; load => chan_sip.so

; Do NOT load both simultaneously on same port

Security Risks of Staying on chan_sip

HIGH

CVE-2023-37457

Heap buffer overflow in chan_sip SDP processing

HIGH

CVE-2022-26498

Remote crash via malformed SIP message

MEDIUM

Multiple 2024–2025

No patches issued — chan_sip is EOL

Frequently Asked Questions

QCan chan_sip and PJSIP run simultaneously?

Yes, but on different ports. During migration use chan_sip on 5060 and PJSIP on 5061. Once all extensions are migrated, consolidate to 5060 with PJSIP only.

QDoes PJSIP support WebRTC?

Yes. PJSIP with WebSocket transport and DTLS-SRTP configuration enables WebRTC endpoints. This was impossible with chan_sip.

QHow long does a migration take?

A 50-extension office PBX with two SIP trunks typically takes 4–8 hours. A 500-extension call centre with complex dial plans can take 2–4 days.

QWill my dialplan need changes?

Usually minimal changes. PJSIP uses PJSIP/ channel prefix instead of SIP/ in some places, but Asterisk handles this with a compatibility shim in most versions.

Need Help with Your PJSIP Migration?

CelloIP Technologies has migrated dozens of Asterisk deployments from chan_sip to PJSIP with zero downtime. Let us handle your migration safely and efficiently.