PBX inbound call failures can leave customers unable to reach your business while staff place outbound calls normally. That contrast often sends troubleshooting in the wrong direction. A successful outgoing call proves only that its particular path worked. Incoming calls may use different provider servers, firewall rules, number matching, and destinations.
A PBX is the phone system that manages your business calls. Start with one controlled incoming call and follow it from the provider to the intended phone. The goal is to find the first point where delivery stops, not change every trunk setting.
Why Outbound Success Does Not Prove Inbound Delivery
A SIP trunk connects your PBX to a telephone provider. SIP, or Session Initiation Protocol, carries call setup messages. Outgoing calls usually begin with your PBX contacting a provider server. Incoming calls require the provider to locate your system and deliver a new call request.
Some trunks use registration, where the PBX tells the provider its contact address. Others rely on an agreed public IP address. Registration success does not confirm that the provider assigned your business number to that trunk.
A DID, or direct inward dialing number, is a public telephone number that reaches your system. Its incoming path usually looks like this:
- The caller’s carrier routes the dialed number to your provider.
- Your provider selects the DID’s delivery destination.
- The call crosses your network edge and reaches the PBX.
- An inbound route matches the number and selects a destination.
- The PBX contacts the phone or another call-handling service.
Treat each step as a separate checkpoint. A green trunk indicator cannot verify this entire chain.
Capture One Repeatable Inbound Failure
Before making changes, record a test call with an exact timestamp and time zone. Use an external phone rather than dialing the public number from an internal extension. Internal dialing may bypass the provider entirely.
- Record the calling number and the complete number dialed.
- Note whether the caller hears ringing, silence, busy tone, or an announcement.
- Check whether all DIDs fail or only one number.
- Repeat from a second carrier when practical.
- Record recent number ports, internet changes, and PBX updates.
Ringing at the caller’s phone does not prove a desk phone rang. A carrier or intermediate system can generate that sound.
Save current routing and firewall settings before any edit. Arrange a test window if the change could affect other calls. Avoid broad restarts until you collect evidence; they may erase useful state or temporarily hide the fault.
Locate PBX Inbound Call Failures at the Delivery Boundary
Look for the test call in PBX signaling logs. An INVITE is the SIP request that starts a call. Ordinary call history may omit attempts that fail before normal call processing begins.
If no INVITE appears, compare a short network capture at the internet edge with one at the PBX. Restrict captures to the relevant hosts and test period. Encrypted SIP requires application logs to inspect message contents.
- Nothing reaches the edge: investigate provider delivery and upstream routing.
- Traffic reaches the edge but not the PBX: inspect forwarding, filtering, and the selected destination.
- The PBX receives the request and rejects it: inspect trunk identification and routing.
- The PBX calls a destination: continue to endpoint reachability checks.
Check capture interfaces and filters before concluding that traffic never arrived. A missing packet in one capture is not conclusive proof.
Where available, preserve the SIP Call-ID, a message field that helps correlate a call. Captures and logs can expose phone numbers, credentials, and call content. Share them only through approved secure channels.
Verify Provider DID Assignment and Delivery
In the provider portal, confirm that the failing DID belongs to the expected account and trunk. Check its incoming delivery target, not just the account’s outbound permissions.
Compare the configured public address with your current internet address. After an internet service change, the provider may still target the old connection. For hostname-based delivery, ask which address the provider resolved during the test.
On registration-based services, verify the active contact and whether another device has replaced it. Provider rules for multiple registrations vary. Never assume a registered backup PBX leaves the primary contact unchanged.
Ask provider support for specific evidence:
- Did their network receive the incoming call?
- Which destination IP address, port, and transport did they try?
- Which source server sent the request?
- What response or timeout did they observe?
- Did a forwarding rule or failover target take over?
If only callers from one carrier fail, supply paired examples from working and failing carriers. That pattern may indicate an upstream number-routing issue rather than a PBX fault.
Check Firewall and NAT Without Opening Everything
NAT, or network address translation, maps addresses between networks. An outgoing call can create temporary firewall state that does not cover a separate incoming request. Providers may also send incoming calls from different servers than those handling outbound traffic.
Compare the provider’s documented signaling sources against your allow rules and PBX trust settings. Verify the actual destination port and transport. Do not assume every trunk uses the same SIP port.
Check that any required forwarding rule targets the PBX’s current private address. Also inspect host firewalls and automatic blocking tools. An edge firewall permit does not guarantee that the PBX accepts the request.
For multiple internet connections, confirm that replies leave through the expected connection. Our guide to stateful return-traffic failures explains why mismatched paths can break sessions.
A SIP ALG is a firewall feature that rewrites SIP traffic. Compare evidence before changing it; avoid treating its removal as a universal fix. Never disable the firewall or enable unrestricted anonymous calls as a diagnostic shortcut.
Match the Delivered Number to an Inbound Route
Once the PBX receives the INVITE, identify the called number it actually uses for routing. The provider may deliver a local number, a country-code format, or a leading plus sign.
The Request-URI identifies the SIP request’s target. Providers may also place called-number information in other headers. Your trunk configuration determines which field the PBX uses. Do not assume the visible To header always controls route matching.
Compare the extracted DID with the inbound route character for character. Check country codes, prefixes, and any caller-ID restrictions. A caller-ID condition can prevent a DID route from matching otherwise valid calls.
Confirm that the request maps to the correct trusted trunk and incoming call-processing context. A context is a set of routing rules. Do not move provider calls into an internal dialing context merely to make them connect.
Use the official FreePBX documentation for controls relevant to your installation. Back up settings before edits and apply approved changes. Avoid a broad catch-all route that masks number-format errors or sends unrelated DIDs to one destination.
Test Endpoint Reachability After Route Matching
When logs show the expected route, check the destination next. Call that extension internally. This separates endpoint problems from provider delivery problems, though internal success does not prove the external path works.
Inspect the phone’s current contact address and reachability status. A registration record may remain visible after a phone loses connectivity. Remote phones can also have stale NAT mappings that block new requests.
Trace whether the PBX sends an INVITE to the phone and whether the phone responds. Then inspect schedules, unavailable destinations, and call-handling rules.
If calls reach voicemail, use the focused guide to voicemail routing and endpoint availability. If calls connect but lack sound, move to media-path troubleshooting. Neither symptom requires starting the provider-delivery investigation again.
Validate Failover and Confirm Recovery
Provider failover redirects calls when the primary target meets a defined failure condition. A PBX unavailable destination handles calls only after they reach the system. These mechanisms protect different parts of the path.
Confirm which events trigger provider failover. A timeout, busy response, and answered voicemail may produce different results. Check that backup forwarding does not loop back to the same failed DID.
Test failover during an approved window, with a rollback plan. Verify that the alternate number reaches a staffed destination. After restoring the primary path, repeat calls from two external networks and check affected DIDs.
Close PBX inbound call failures with evidence: provider delivery, successful route matching, endpoint ringing, two-way audio, and normal hangup. Document the change and the confirmed backup behavior.
Professional remote assistance may help when provider traces, firewall captures, and PBX logs need coordinated review. Tech Rescue Ops LLC can help isolate the failing boundary and plan controlled changes without weakening inbound-call security.