FreePBX trunk online but outbound calls fail is a confusing symptom. The dashboard may show a healthy trunk, yet users hear a fast busy signal, an announcement, or silence after dialing. That status usually confirms only part of the connection. It does not prove that FreePBX selected the correct route, sent the right number format, passed authentication, or received an acceptable response.
This guide follows the call path in a safe order. You will check trunk status, outbound routes, dial patterns, permissions, credentials, codecs, and Asterisk logs. Avoid changing several settings at once. A controlled test gives you better evidence and makes rollback easier.
What “online” actually proves
FreePBX can display a trunk as online when its registration or qualify check succeeds. Registration means the PBX has authenticated to a provider and created a reachable SIP relationship. Qualify checks usually test whether the provider responds to a SIP request. Neither test represents a complete outbound call.
An outbound call adds several other decisions. FreePBX must identify the caller’s extension, match an outbound route, transform the dialed number, select the trunk, authenticate the call, negotiate a codec, and receive a usable provider response. A failure at any stage can look like a trunk problem. That is why FreePBX trunk online but outbound calls fail requires a call-path review rather than a status check alone.
Before editing anything, record:
- Record the exact time of one failed test.
- Note the extension and number format used.
- Capture the error heard by the caller.
- Whether all extensions fail or only one.
- Whether local, national, international, and emergency numbers behave differently.
Start with trunk status and provider scope
Open the FreePBX trunk configuration and confirm the status shown for the relevant trunk. Then identify what that status measures. A registration-based trunk may report online because inbound registration works. A peer-based trunk may show reachable because SIP responses arrive. The provider may still reject outbound traffic from the wrong source address or account.
Review the provider’s service scope before changing credentials. Some providers require a registered account. Others authorize a fixed public IP address, a specific username, or a separate outbound caller ID. Some also require a particular transport or port. These details belong to the provider’s current documentation, not a generic FreePBX template.
Do not assume a successful inbound call proves outbound service. Providers can apply separate permissions, rate limits, destinations, or caller-ID rules. Test one ordinary destination first. Avoid repeated calls to emergency services or premium destinations during troubleshooting.
Check outbound routes and dial patterns
The outbound route decides which calls may leave the PBX. If no route matches the digits, FreePBX never reaches the trunk. This is one reason FreePBX trunk online but outbound calls fail can mislead administrators.
In Connectivity > Outbound Routes, inspect the routes from top to bottom. Route order matters because the first matching route can capture the call. Confirm that the correct trunk appears in the route’s trunk sequence. A route with an unavailable or incorrect trunk may produce a rejection even when another trunk works.
Read the dial pattern as a rule
A dial pattern is a matching rule, not a description of what users intend to dial. Review each field carefully:
- Prepend: digits added after the pattern matches.
- Prefix: digits removed before the call leaves the PBX.
- Match pattern: the digits that must match.
- CallerID: an optional restriction on which extensions may use the pattern.
For example, a route might let users dial a leading nine for an outside line, remove that nine, and send the remaining number. A different route might expect numbers in international format. Write down the digits entered, the digits after route processing, and the digits the provider expects.
Test a known allowed format from an extension that should have permission. Then compare it with a number that uses a different prefix. If one format works, focus on route matching and digit manipulation instead of trunk connectivity. In that situation, FreePBX trunk online but outbound calls fail points more strongly to dialplan logic than to registration.
Verify extension permissions and calling privileges
FreePBX can block an outbound call before it selects the trunk. The extension’s outbound route permissions may exclude the route, or a class-of-service design may limit certain destinations. Check the extension’s assigned route permissions and any custom context or permission settings.
Look for differences between a working and failing extension. Compare their route access, caller ID, device assignment, and dialed number. If one extension succeeds while another fails, the trunk is less likely to be the primary cause.
Also review time conditions, holiday rules, and custom destinations. A time condition can send a call to a different destination outside business hours. A custom dialplan change can bypass the expected outbound route. Keep a copy of the current configuration before making adjustments, and apply changes only after you understand their scope.
Recheck authentication and SIP identity
When the provider receives a call, it may validate more than the registration username. It can check the authentication username, account realm, source IP, From header, contact information, and caller ID. A trunk may remain registered while outbound INVITEs receive a challenge or rejection.
Review the trunk’s username and secret against the provider record. Check for copied spaces, outdated credentials, and an incorrect authentication field. If the provider uses IP authentication, confirm that the public address is still the authorized one. A changed WAN address, new firewall, or upstream NAT device can affect this relationship.
Authentication errors often appear in the Asterisk console or log. Common response categories include an authentication challenge, forbidden request, or unavailable destination. The exact meaning depends on the provider and the SIP exchange, so do not treat one response code as universal proof.
Check codecs, transport, and network translation
Codecs describe how voice is encoded. The trunk and provider need at least one compatible codec for the call to carry audio. Codec mismatch more often causes a call to connect without usable audio, but some providers reject incompatible offers before connection.
Compare the trunk’s allowed codecs with the provider’s current requirements. Keep the list intentional rather than enabling every available option. Confirm the selected transport as well. UDP, TCP, and TLS settings must match the provider’s instructions, and encryption settings can affect both signaling and media.
Network address translation, or NAT, changes private addresses into a public address as traffic crosses a router. Incorrect NAT settings can affect SIP headers and RTP, the media stream that carries audio. A call may therefore ring while audio fails, or the provider may reject signaling that contains an unreachable address. The Cloudflare NAT overview provides useful background on address translation.
Check the PBX’s external address, local networks, firewall zones, and RTP port policy. Do not open broad port ranges without understanding the PBX and firewall design. If a VPN carries the signaling or media, verify routes and interface selection. Our guide to VPN-related VoIP audio problems covers that separate path in more detail.
Use Asterisk logs to locate the failure
Logs turn a vague symptom into a call-path question. Start a controlled test while watching the Asterisk console or the relevant log files. Redact phone numbers, usernames, IP addresses, and authentication material before sharing output outside the organization.
Depending on the Asterisk channel driver and release, useful console commands may include:
asterisk -rvvv
pjsip set logger on
sip set debug onUse only the commands that match the system’s channel driver. pjsip set logger on helps inspect PJSIP signaling. sip set debug on applies to the older chan_sip driver. Debug output can expose credentials or personal data, so disable it after the test.
Look for these points in sequence:
- First, check whether the extension sent an outbound request.
- Next, confirm that the dialplan selected the expected outbound route.
- Then, verify that the PBX sent the request to the intended trunk.
- Afterward, check whether the provider challenged, accepted, or rejected authentication.
- Review whether the provider returned a destination or policy error.
- Finally, determine whether the call reached a connected state and then failed during media negotiation.
Asterisk’s official documentation explains SIP, endpoints, RTP, codecs, and dialplan concepts. Use it alongside the provider’s documentation because FreePBX templates and provider requirements vary.
Match the error to the next action
If the log shows no outbound request, investigate extension permissions, route order, dial patterns, time conditions, and dialplan context. The trunk cannot be the first failure if the PBX never attempts it.
If the provider rejects the request, inspect credentials, source IP authorization, caller ID, number formatting, and destination permissions. Ask the provider for the precise rejection reason and the timestamp. Their SIP trace may show a policy decision that the local dashboard cannot explain.
If the call connects but audio fails, focus on NAT, RTP paths, codecs, firewall policy, and VPN routing. Compare the local and public addresses in the signaling exchange. Test from a controlled network, not by making broad firewall changes during business hours.
For a broader checklist, you can also review the guidance on VoIP troubleshooting for small businesses. Keep the scope narrow: prove one failure, make one reversible change, and repeat the same test.
When to involve a specialist
Professional help makes sense when the issue affects multiple routes, involves custom dialplan code, or requires provider and firewall coordination. It also helps when logs contain sensitive data or when production calls cannot be interrupted safely.
Tech Rescue Ops LLC can help trace the call from extension permissions through FreePBX routes, SIP signaling, provider authentication, and media handling. Preserve timestamps and recent configuration changes first. Good evidence shortens the path to a safe fix.