FreePBX trunk registration failures need a different investigation from calls that fail through an already registered trunk. Start by proving whether your provider expects registration at all. Then check DNS, transport, authentication, and source IP restrictions in order. Use registration state and SIP responses to confirm where the exchange stops.
This guide focuses on a new or changed trunk that never reaches a registered state. It does not cover phones losing registration or call routing after successful registration. Avoid repeated restarts and password changes until you have evidence.
Confirm That the Trunk Should Register
A trunk connects your phone system to a calling provider. SIP, the Session Initiation Protocol, carries call control messages. A SIP REGISTER request tells a registrar where an account can receive requests.
Some providers authenticate trunks by public IP address instead. Those trunks may work without any outbound registration. An empty registration list does not prove failure in that setup.
Obtain the provider’s current trunk instructions and confirm:
- Whether the account uses registration, IP authentication, or both.
- The registrar hostname and any required outbound proxy.
- Required transport protocol and destination port.
- The SIP username, authentication username, and secret.
- Any approved source IP addresses or activation requirements.
Check the actual trunk driver before choosing diagnostic commands. This guide uses PJSIP, Asterisk’s modern SIP stack. Older installations may use a different driver. Consult the FreePBX documentation for settings that match your installation.
Preserve Evidence Before Changing Trunk Settings
Record the failure time, time zone, trunk name, and last known working state. Note recent changes to the provider account, internet connection, router, credentials, or PBX configuration.
Save the current settings securely and confirm that you have a usable backup. Trunk settings contain secrets, so avoid placing screenshots in public tickets. Schedule changes if the trunk carries active business calls.
Use the following checks as a sequence, not a collection of fixes. Change one setting at a time. After each change, observe a fresh registration attempt and record the result.
Do not edit FreePBX-generated configuration files directly. FreePBX can overwrite those edits, making the displayed settings differ from your assumptions. Review pending changes before applying configuration; unrelated edits may affect other services.
Check DNS From the PBX Itself
DNS translates the provider’s hostname into network destinations. A successful lookup from your laptop does not prove that the PBX can resolve it.
From an authorized PBX shell, use an available lookup tool against the exact configured registrar. For example, replace the placeholder below with the provider’s hostname:
getent ahosts REGISTRAR_HOSTNAMEThis read-only check shows host address results through the system resolver. It does not reproduce every detail of SIP service discovery. Depending on configuration, SIP clients may also use DNS service records to select destinations and ports.
- Confirm the hostname matches the provider’s instructions.
- Look for lookup failures, unexpected addresses, or long delays.
- Check whether the selected IPv4 or IPv6 destination has a working route.
- Compare the lookup with the destination in Asterisk’s actual registration attempt.
Avoid permanently replacing the hostname with one resolved IP address. Providers may rotate addresses for resilience. A fixed address can also break certificate name checks when the trunk uses encrypted signaling.
Verify the SIP Transport and Network Path
Match the provider’s transport exactly: UDP, TCP, or TLS. UDP sends independent datagrams; TCP establishes a connection. TLS encrypts signaling over a connection and adds certificate checks.
Do not assume a familiar SIP port applies to this account. Verify the registrar port and any separate proxy destination. An outbound proxy forwards SIP requests and may differ from the registrar hostname.
Review firewall logs for traffic from the PBX to the actual destination. For TCP, look for connection establishment or rejection. For TLS, inspect handshake errors, certificate trust, hostname checks, and the PBX clock.
A ping reply proves neither SIP reachability nor account access. Likewise, a TCP port test says nothing about a UDP registration path.
Do not disable the firewall or expose every SIP port as a test. Outbound registration commonly uses stateful return traffic. Any inbound rule should follow verified provider requirements and your network design.
A SIP ALG is a router feature that rewrites SIP traffic. Investigate it only when captures suggest altered messages or addresses. Make controlled changes with a rollback plan.
Check Authentication Without Guessing Credentials
Providers often assign several identifiers to one account. The portal login, telephone number, SIP username, and authentication username may all differ.
Compare each field with the provider’s account-specific instructions. Check capitalization, copied spaces, and the account’s current secret. Confirm any required domain or authentication realm, which identifies the scope of a credential challenge.
A first 401 Unauthorized response often represents normal SIP authentication. The provider challenges the request, and Asterisk should send another REGISTER with an authentication response.
Repeated challenges without eventual success deserve investigation. Possible causes include incorrect credentials, mismatched identifiers, or incompatible authentication requirements. A challenge alone does not prove the password is wrong.
Stop repeated guessing. Providers may enforce lockouts or request limits. If you must reset a secret, coordinate the change and identify every system using that account first.
Verify the Public Source IP and Provider Restrictions
NAT, or network address translation, replaces private addresses as traffic leaves the network. The provider usually sees the firewall’s public address, not the PBX’s private address.
Ask which source IP the provider sees for the failed attempt. Compare it with the account’s approved address list and your firewall’s connection records.
A browser-based IP check from another computer may mislead you. Multiple internet connections, policy routing, or a VPN can send PBX traffic through a different exit.
- Check whether internet failover changed the public address.
- Confirm whether the provider approves individual addresses or defined ranges.
- Ask whether the account requires both credentials and source IP approval.
- Identify any second PBX still registering with the same account.
Some providers restrict simultaneous registrations or replace an older contact with a newer one. Confirm their policy rather than assuming two systems can share credentials.
Inspect FreePBX Trunk Registration State
Once you have checked the prerequisites, inspect Asterisk’s loaded registration objects. On an authorized system using PJSIP, this read-only command lists outbound registrations:
asterisk -rx "pjsip show registrations"An absent entry suggests a local configuration or loading issue, assuming the trunk should register. Confirm that the trunk is enabled and that its registration direction matches the provider’s requirements.
A rejected or unregistered entry requires the latest transaction evidence. State labels alone do not identify the cause. An endpoint marked reachable through SIP OPTIONS checks also does not prove successful registration.
For a short diagnostic window, an administrator can enable SIP logging in the Asterisk console:
pjsip set logger on
pjsip set logger offThese are separate commands: enable logging, observe one attempt, then disable it. Logging can expose phone numbers, addresses, and authentication material. It can also increase log volume. Restrict access and redact exports carefully.
Use the official Asterisk documentation to verify command availability for your installed release.
Read the REGISTER Exchange, Not Just the Error Label
Match each response to the REGISTER request. Responses to OPTIONS or call attempts describe different transactions.
- No response: Check destination selection, transport, filtering, and whether the provider received the request.
- 401 or 407: Usually an authentication challenge. Look for the authenticated retry and its result.
- 403 Forbidden: Ask about credentials, account status, source IP policy, and provider restrictions.
- 404 Not Found: Verify the registration identity and domain with the provider.
- 423 Interval Too Brief: Inspect the minimum expiry requirement and the next registration attempt.
- 503 Service Unavailable: Check provider availability and any retry guidance before generating more attempts.
- 200 OK: Confirm that the response accepts the intended contact with a nonzero expiry.
The SIP specification defines core response behavior. Provider policy still determines many account-level failures. For persistent availability errors, use this SIP 503 diagnostic guide.
Confirm Provider Requirements and Validate Recovery
Escalate with a concise evidence package: timestamp, public source IP, destination, transport, registration identity, and redacted response sequence. Include the SIP Call-ID, which helps the provider locate the transaction. Never include the account secret.
Ask the provider to confirm activation, registrar assignment, expiry limits, contact restrictions, and authentication policy. Request their observed rejection reason rather than another generic setup checklist.
After a correction, confirm successful registration and a later renewal. Then test an ordinary inbound and outbound call. Registration success does not prove routing or audio delivery. If calls connect without sound, move to media path troubleshooting instead.
Professional remote assistance may help when evidence spans FreePBX, the firewall, and provider logs. Tech Rescue Ops LLC can help correlate those records and plan targeted changes without broadening network exposure.