When FreePBX inbound caller ID missing problems appear, the visible symptom can be misleading. The provider may send no caller number, FreePBX may receive it in an unexpected SIP header, or a privacy flag may intentionally hide it. A careful trace separates those possibilities before anyone changes the trunk.
Start by defining the caller ID problem
First, record what the recipient sees. Is the display blank, showing “Unknown,” showing the main business number, or showing a malformed value? Also note whether the issue affects every inbound call or only certain callers.
Test several call types without exposing private information unnecessarily:
- Test a call from a known mobile number.
- Place a call from another business line.
- Include a call with caller ID intentionally blocked.
- Use each affected trunk or DID for a separate test.
Write down the date, time, dialed number, receiving extension, and displayed result. Exact timestamps let you match the call with FreePBX and provider records. They also prevent a later test from being confused with the original failure.
Do not begin by changing the caller ID name or number fields. Those settings often affect outbound identity, while the inbound value comes from the carrier’s signaling. That distinction matters in any FreePBX inbound caller ID missing investigation.
Trace the inbound SIP signaling
Caller ID travels through signaling, the messages that establish and manage a call. In SIP, the number may appear in the From, P-Asserted-Identity, or Remote-Party-ID header. Providers do not all use the same format.
Asterisk can display SIP messages for a controlled test. The exact command depends on whether the trunk uses chan_pjsip or the older chan_sip channel driver. Use the appropriate console trace only during a short test window, because SIP messages can contain phone numbers and other sensitive details.
- For PJSIP, an administrator may use the PJSIP logger from the Asterisk console.
- For chan_sip, SIP debug commands provide a similar view.
- Turn debugging off immediately after capturing the test call.
Review the initial INVITE that enters the PBX. Look for the caller number and its surrounding headers. Compare the raw value with what the extension displays. If the number is absent in the incoming message, the provider or upstream network is the primary suspect.
This trace is the fastest way to confirm whether FreePBX inbound caller ID missing symptoms begin at the carrier boundary or inside the PBX.
The official Asterisk documentation provides reference material for SIP signaling and channel behavior. Use it alongside your provider’s trunk guide, not as a replacement for provider-specific requirements.
Check provider formats and privacy behavior
Some carriers send caller information in the standard From header. Others place trusted identity in P-Asserted-Identity or use a provider-specific variation. A provider may also send a private presentation value when the caller blocks their number.
Privacy behavior is not always a fault. SIP can indicate that the caller does not want the number presented. In that case, the PBX may correctly show “Private,” “Anonymous,” or no number. Ask the carrier how it represents blocked caller ID before attempting to override the result.
Compare a working call and a failing call from the same trunk. Check these fields:
- The user and host portions of the
Fromheader. - The presence and value of
P-Asserted-Identity. - Any
Privacyheader or anonymous display name. - Whether the number contains a country code, area code, or leading trunk prefix.
- Whether the provider sends a name separately from the number.
If the provider confirms that it sends caller ID, provide the trace timestamp and call reference. Ask whether the carrier expects a specific identity header, trusted signaling path, or trunk option. Do not add arbitrary headers based on a forum example. A change that helps one carrier can create incorrect identity or authentication behavior with another.
Review FreePBX trunk and caller-ID settings
FreePBX translates incoming signaling into channel and call variables. The result can change when the trunk uses PJSIP instead of chan_sip, when a provider template changes, or when custom dialplan code rewrites values.
Review the affected trunk without modifying it first. Confirm the transport, endpoint association, context, and provider-recommended options. A trunk that routes calls correctly can still pass caller information differently after a technology or template change.
Next, inspect custom settings and outbound identity fields. Common areas include the trunk’s outbound caller ID, route-level caller ID, extension caller ID, and any custom dialplan or subroutine that handles inbound calls. These fields do not all control the same direction of traffic.
For a FreePBX inbound caller ID missing case, focus on the value immediately after the inbound call enters the PBX. If the trace contains a number but the destination sees a blank value, investigate processing inside FreePBX or Asterisk. If the trace has no number, focus on the carrier exchange instead.
Keep a backup of the current configuration before testing. Record each change, its reason, and the exact test result. Avoid restarting the entire PBX during business hours unless the change requires it and a rollback plan exists.
Check normalization before blaming the display
Normalization means converting phone numbers into a consistent format. For example, one source may send a ten-digit national number while another sends an international form with a country code. Normalization helps routing, matching, contact lookups, and consistent display.
A formatting difference does not always mean caller ID is missing. An extension may show a number with an unexpected prefix, or a contact directory may fail to match it. Compare the raw signaling value, the Asterisk value, and the final phone display.
Check for these possible transformations:
- Removal or addition of a leading access digit.
- Conversion between national and international formats.
- Stripping punctuation, spaces, or a plus sign.
- Replacement with a main business number by a route or application.
- Truncation caused by an incorrect field or custom script.
Apply normalization only where the requirement is clear. A rule that assumes every call has the same country code can damage calls from neighboring regions or international callers. Test local, national, blocked, and international examples when those call types matter to the business.
If callers need consistent contact matching, document the chosen format. The documentation should identify the source format, the target format, and the FreePBX component that performs the conversion.
Separate caller number from caller name
Caller ID number and caller ID name are related but separate values. A carrier may provide the number while omitting the name. In other cases, the carrier sends a name that the phone does not display because the device or endpoint ignores it.
Test the same inbound call at different destinations. Compare a desk phone, softphone, queue, and mobile forwarding destination if the business uses them. This helps identify whether the problem begins at the trunk or at one endpoint.
Queue and ring-group behavior can also change what a device displays. Check whether the destination rewrites the caller value, uses a queue label, or presents a transfer party instead. If only one destination behaves differently, inspect that application and its endpoint settings.
Do not assume that a name lookup failure proves a SIP problem. Local directories, handset contacts, carrier CNAM services, and mobile networks can each affect the displayed name. Confirm the number first, then investigate name presentation separately.
Use a safe diagnostic sequence
A repeatable sequence reduces guesswork and protects live phone service:
- Choose one test caller and record the exact call time.
- Confirm the expected result using another phone or carrier when possible.
- Capture one inbound SIP trace during the test.
- Check whether the number exists in the incoming identity headers.
- Compare the raw number with the Asterisk and endpoint values.
- Review privacy indicators and provider documentation.
- Inspect normalization and custom dialplan logic.
- Make one controlled change, then repeat the same test.
- Disable debugging and retain only the evidence needed for support.
Do not capture unrestricted traffic for longer than necessary. A SIP trace may include phone numbers, account identifiers, and call details. Store it securely and redact it before sending it outside the organization.
When a provider needs evidence, send timestamps, the called DID, the originating number if available, and a short description of the displayed result. Avoid sending full traces through an unsecured channel unless the provider specifically supports a protected upload method.
When the trace points outside FreePBX
If the incoming INVITE lacks caller information, FreePBX cannot reliably invent the original number. The carrier must confirm whether the upstream network supplied it and whether the account permits presentation.
If the provider sends the number but FreePBX loses it, review the trunk technology, endpoint association, context, and custom dialplan. If FreePBX retains it but the phone displays the wrong value, inspect endpoint firmware, provisioning, application behavior, and handset settings.
Network address translation, or NAT, can affect SIP traffic paths, although NAT alone does not explain every caller ID problem. The Cloudflare overview of NAT offers useful background when tracing how a PBX and provider exchange traffic.
For broader inbound routing questions, see how to trace FreePBX inbound calls that reach the wrong destination. The routing path and caller identity are separate checks, but the same timestamps and traces can help with both.
If the call reaches an IVR, compare the identity trace before reviewing destination logic. This related guide explains how to trace a FreePBX IVR call safely when application handling may affect what the caller sees.
Prevent recurring caller ID confusion
Document the carrier’s expected identity headers and number format. Keep a known-good trace from a normal inbound call, with private values redacted. Record whether blocked callers should appear as anonymous and which destinations must show the number.
After provider or trunk changes, test caller ID as part of acceptance checks. Include a normal caller, a blocked caller, and at least one number from a different network. Test both the displayed number and the displayed name.
Finally, keep custom dialplan changes small and documented. When practical, use provider-supported trunk settings instead of unexplained header manipulation. Tech Rescue Ops LLC can help review traces, FreePBX settings, and provider requirements when a FreePBX inbound caller ID missing issue spans multiple systems.