Configure and verify a FreePBX 17 PJSIP trunk

Define the carrier contract before opening the form

Confirm that the account is a SIP trunk intended for a customer PBX, not a hosted-user credential. Record whether the carrier expects outbound registration, source-IP identification, digest authentication or a combination; its signaling hosts and ports; inbound source ranges; media ranges; codecs; DTMF; number formats; caller-identity policy; capacity and emergency procedure. A provider example can illustrate fields but cannot define another carrier's contract.

Use PJSIP as the normal FreePBX 17 trunk path. Sangoma documents that FreePBX 17 defaults to Asterisk 22, where chan_sip is unavailable, and strongly discourages the legacy driver even when an older Asterisk version is selected. Preserve any migration reason and do not downgrade the engine merely to copy an obsolete trunk recipe.

Inbound and outbound routing are separate

Map GUI fields to separate PJSIP responsibilities

In Connectivity → Trunks, create a descriptive PJSIP trunk and map only the carrier's current values. Authentication and registration are separate choices. The SIP server or outbound proxy selects a signaling target; an AoR gives Asterisk a contact to call; outbound auth answers a challenge; a registration creates a provider-side binding; Match Permit or another identify rule can associate inbound requests with the endpoint. Do not use a broad permit range or anonymous acceptance to conceal a missing identify rule.

Asterisk documents endpoint, AoR, auth, identify, transport and registration as distinct objects. FreePBX generates those objects and owns their durable configuration. Use GUI fields or supported custom include boundaries rather than hand-editing generated files. Protect secrets in screenshots, backups, console output and tickets.

Keep the trunk, inbound route and outbound route separate

Sangoma's module documentation separates the Trunks module from inbound and outbound routes. A trunk defines the remote connection. An outbound route decides which dialed numbers and callers may use which trunk sequence. An inbound route matches the delivered number and chooses the local destination. Until an outbound route selects the trunk, an available endpoint does not place outside calls.

Capture the carrier's actual called-number format before adding the inbound route. For outbound service, state permitted users, prefixes, normalized digits, trunk order and the terminal outcome when every trunk fails. Keep ordinary, international, premium and emergency permissions explicit. A catch-all can make one test pass while silently authorizing unrelated calls.

Submit, apply and prove the running objects

Submit saves module data; Apply Config generates and loads Asterisk configuration. Preserve both outcomes, then inspect the running PJSIP endpoint, AoR, contacts, auth references, identify match and outbound registration that the installed module generated. A successful reload does not prove the intended trunk object loaded, and a registration indicator proves only the registration transaction.

For one authorized call in each direction, correlate route selection, PJSIP endpoint, Request-URI, final response, negotiated SDP and both media directions. Diagnose endpoint identification, digest authentication, registration, dialplan routing and media as different stages. Return temporary protocol logging to its normal level after the bounded capture.

Verify identity, capacity and failure behavior

Test caller identity against the carrier's authorized-number policy without forcing an arbitrary value just to complete a call. Keep asserted identity, displayed caller ID, privacy and emergency callback identity separate. Confirm active-call capacity and call-start limits independently; a registered trunk name, Maximum Channels field or green dashboard state does not prove the account entitlement.

Exercise the intended new-call failure path with a noncritical number. Outbound trunk sequence cannot protect inbound delivery unless the carrier separately routes the number to another reachable destination. Record the first failing SIP response or timeout, the component that chose the next path and the rollback trigger. Do not test by weakening the firewall or accepting arbitrary internet sources.

Complete acceptance without overclaiming

Verify inbound and outbound calls, expected busy or rejection behavior, two-way audio, DTMF, hold, transfer, forwarding, ordinary hangup and call records. Qualify fax, recording, encryption and number porting only when they are required and separately documented. Confirm emergency service through the carrier's current approved non-live process; never infer it from an ordinary call or place an uncoordinated live emergency test.

Record installed FreePBX, framework, core, trunk-module and Asterisk versions with the carrier document date, applied configuration and rollback. Sangoma's generic module documentation can establish responsibility boundaries without proving an exact current field order. No FreePBX host, module, account, credential, trunk, route, registration, number, identity, call, media path, failover, capacity, emergency workflow or compatibility was tested for this guide.

Migrate a legacy trunk by responsibility, not by field name

For an existing chan_sip trunk, use the migration guide to preserve the provider contract, route dependencies and rollback boundary. A converter or Registered label does not prove endpoint identification, route selection, media or emergency behavior.

Keep SIPStation module state and loaded PJSIP objects distinct

The SIPStation inbound diagnostic correlates the module account and DID state with the running registration, endpoint, AoR, packet and first dialplan match.

Start a Voximplant trunk with the chosen trust model

The Voximplant provider record distinguishes IP allowlisting, endpoint-style registration and scenario-originated authenticated SIP. Match the selected model to the generated FreePBX objects instead of adding every possible field.

Use VoIP Much account-issued values, then inspect the loaded object

VoIP Much’s FreePBX guide supplies placeholders for its account-issued host, username and password. The provider profile keeps that example distinct from the selected FreePBX release, driver, route and observed registration and call state.

Bind a VoIPline trunk to the issued order

The VoIPline profile keeps the loaded FreePBX trunk, selected operation mode, ordered channels, numbers and observed calls separate.

Bind a Voip Unlimited trunk to the issued registration and numbers

The Voip Unlimited guide keeps credentials, Contact, headline number, DDI aliases, channels and loaded FreePBX routing as separate evidence.

Bind SignalWire FreePBX routing to the assigned resource

The SignalWire diagnostic verifies number assignment, from-signalwire, DID extraction, from-pstn routing and media after registration.

Prove Telnyx delivery before changing a FreePBX route

The Telnyx inbound-route diagnostic preserves the provider attempt, delivered Request-URI, first FreePBX object or context, normalized DID and first matching destination.

Prove Bandwidth delivery before changing a FreePBX route

The Bandwidth inbound-route diagnostic retains the provider attempt, delivered Request-URI, normalized DID and first matching FreePBX destination.

Inspect the delivered Voipfone identity before changing FreePBX

The Voipfone inbound-number diagnostic compares the portal route, delivered Request-URI, normalized DID and first matching FreePBX route.

Inspect the delivered VoIP.ms number form before changing FreePBX

The VoIP.ms DID diagnostic compares POP, Request-URI, NANPA or E.164 form, normalization and first matching FreePBX route.

Match a Twilio origination attempt before changing FreePBX

The Twilio origination diagnostic follows URL selection, edge source, Request-URI, FreePBX endpoint identification and the first matching inbound route.

Match the Plivo attempt before changing FreePBX

The Plivo inbound diagnostic aligns trunk ID, primary or fallback URI, SIP Call-ID, endpoint identification and the first matching inbound route.

Prove the Vonage attempt before changing FreePBX

The Vonage inbound diagnostic aligns number link, URI priority, SIP Call-ID, PJSIP identification and the first matching inbound route.

Prove Voxtelesys delivery before changing a FreePBX route

The Voxtelesys diagnostic follows DID assignment, provider destination, delivered Request-URI, normalization and first matching FreePBX destination.

Prove didlogic delivery before changing FreePBX routing

Start with the purchased DID destination and customer-edge INVITE, then record the identified trunk and delivered number form. The didlogic diagnostic avoids using outbound success as inbound proof.

A Callcentric direct forward can bypass FreePBX entirely

Before changing a FreePBX inbound route, use the Callcentric diagnostic to prove whether the provider attempted the PBX or applied a higher-priority DID Forward.

Trace Anveo Direct before broadening FreePBX matches

The Anveo Direct diagnostic proves whether the provider attempted the configured URI and which signaling and media addresses arrived before a FreePBX trunk or route is widened.

Keep CarrierX provider selection apart from FreePBX routing

The CarrierX diagnostic separates DID assignment and trunk-group decisions from customer-edge receipt, FreePBX trunk matching and the inbound route.

Keep AVOXI target selection apart from FreePBX routing

The AVOXI diagnostic separates the provider’s number rule and SIP URI from FreePBX trunk matching and the inbound route.

Keep Easybell target selection apart from FreePBX routing

The Easybell diagnostic separates the provider identity mode and attempt from FreePBX trunk matching and the inbound route.

Separate SIP.US provider routing from FreePBX matching

The SIP.US diagnostic keeps Forward, Backup, trunk identity and capacity distinct from FreePBX trunk matching and the inbound route.

Keep Flowroute route evidence separate from FreePBX media evidence

After the correct number route reaches FreePBX, preserve SDP, NAT settings and observed RTP with the Flowroute audio diagnostic.

Do not copy the Bulk Solutions FreePBX 14 chan_sip template into FreePBX 17

Map the provider requirements to current PJSIP owners, then use the inbound diagnostic to compare generated and loaded state.

Do not copy the Yay.com chan_sip-style example into FreePBX 17

Map current provider requirements to supported PJSIP owners, then use the paired diagnostic to compare generated and loaded state.

Treat the ClearlyIP module as a generated configuration owner

The ClearlyIP guide requires installed-version evidence and review of generated trunks, outbound routes and inbound destinations.

Do not paste the Simwood Asterisk 16 sample into FreePBX

The Simwood diagnostic compares GUI ownership, generated files and loaded PJSIP objects.

Keep Sinch application ownership outside the FreePBX template

The Sinch diagnostic joins portal state to generated and loaded FreePBX PJSIP objects.

Match the SIPTRUNK inbound To value in loaded FreePBX state

Use the SIPTRUNK diagnostic before changing a GUI route or broadening trunk identification.