chan_sip vs PJSIP for Outbound Call Centers: Which Driver Fits Your Workload

1. The Short Answer

PJSIP (chan_pjsip) is the correct choice for new deployments and for any existing chan_sip deployment handling more than 20–30 simultaneous outbound channels. Asterisk's own development team deprecated chan_sip in Asterisk 19 and removed it in Asterisk 21. If you are running FreePBX 15 or 16 with Asterisk 18 or 20, chan_sip still works, but migration to PJSIP now avoids a forced migration later under deadline pressure.

If you have a legacy FreePBX system on Asterisk 16 with heavily customized sip.conf peers, chan_sip may be the pragmatic near-term choice while you plan migration. This article covers the differences so you can make a documented decision.

2. Architecture Differences That Matter for Outbound

Connection model:

chan_sip uses a single UDP socket for all SIP signaling. Every call goes through one file descriptor. Under heavy outbound load (100+ concurrent calls), you hit kernel UDP buffer limits and experience random register failures, delayed OPTIONS responses, and intermittent call drops — particularly on Linux kernels before tuning net.core.rmem_max and net.core.wmem_max.

PJSIP uses separate transport objects (one per UDP/TCP/TLS listener) and handles each SIP dialog in its own object model. Concurrency scales with thread count, not file descriptor limits. At 200 concurrent channels, PJSIP on a 4-core VM is measurably more stable than chan_sip on the same hardware.

Multiple registrations:

chan_sip supports one registration per peer. If your SIP provider requires registration (vs. IP auth), you get one registration per trunk definition. PJSIP supports multiple simultaneous registrations per endpoint and can register to multiple SIP proxies simultaneously — useful for geographic redundancy.

UnlimCall supports IP authentication as the default for trunk accounts, which sidesteps the registration limitation entirely. See FreePBX PJSIP trunk setup for IP auth configuration.

TLS and SRTP:

chan_sip TLS requires a separate sip.conf listen directive and SRV record manipulation. PJSIP handles TLS as a first-class transport; you define a [transport-tls] section and reference it per endpoint. For outbound call centers processing recordings or handling compliance-sensitive data, TLS signaling + SRTP media is significantly easier to configure correctly under PJSIP.

3. Codec Negotiation Differences

Both drivers support G.711 ulaw/alaw, G.729, and OPUS. The difference is in offer/answer handling.

chan_sip sends a fixed codec list in the SDP offer based on your allow= lines in sip.conf, ordered by the sequence in that file. Re-INVITE for codec changes mid-call requires explicit support in the peer configuration (reinvite=yes).

PJSIP builds codec offers dynamically per endpoint, respecting the allow list in the endpoint configuration and the global codec preferences in pjsip.conf. Re-INVITE handling is more reliable, which matters for outbound calls that start with ringback and transition to voice — some dialer configurations send a codec re-INVITE when an agent picks up.

For most US/CA outbound traffic on UnlimCall, you will negotiate G.711 ulaw (PCMU). OPUS is available and reduces bandwidth by roughly 60% at the cost of a transcoding step on the Asterisk server. At 200 concurrent calls, transcoding adds measurable CPU — benchmark before enabling OPUS in production if you are on shared hardware.

4. Migrating from chan_sip to PJSIP

FreePBX provides a migration tool: Admin > SIP Channel Driver in the GUI, or via the CLI:

`` fwconsole setting SIPSETTINGS_GEN_CHAN_SIP 0 fwconsole setting SIPSETTINGS_GEN_PJSIP 1 fwconsole reload ``

After switching the driver, existing sip.conf-based trunks will not automatically migrate. You must recreate each trunk as a PJSIP trunk in the GUI. Plan for a maintenance window of 30–60 minutes per 10 trunks, plus testing time.

Back up /etc/asterisk/sip.conf, /etc/asterisk/sip_additional.conf, and your full FreePBX database before starting. The GUI migration does not always capture custom sip.conf directives.

5. When chan_sip Is Acceptable

chan_sip is acceptable if:

• You are running Asterisk 16 or 18 with fewer than 20 concurrent outbound channels and no near-term plans to scale
• You have complex chan_sip customizations (qualify, directmedia, nat settings) that would require significant re-testing under PJSIP
• Your FreePBX upgrade path includes a full OS rebuild and you prefer to migrate both simultaneously

It is not acceptable for new deployments. Asterisk 21+ does not include chan_sip. Starting on PJSIP today means your configuration is forward-compatible with the next two major Asterisk versions.