FreePBX outbound caller ID incorrect troubleshooting starts with one important idea: the displayed number can pass through several systems before it reaches the recipient. An extension may set one value, an outbound route may select a trunk, and the provider may accept, rewrite, or reject the identity.
That path makes caller ID problems easy to misdiagnose. A user might report that calls show the main business number, a personal number, “Private,” or an unrelated value. The PBX may look correctly configured while the carrier applies its own policy. Use the sequence below to separate those possibilities.
First, define what “incorrect” means
Collect evidence before changing a setting. Ask which number the caller expected, which number appeared, and whether the problem affects every destination. Test a mobile phone and a fixed-line number if practical. Some receiving networks display names and numbers differently.
- Record the calling extension and its configured outbound number.
- Capture the date, time, dialed number, and time zone.
- Note the number shown on the receiving device.
- Compare a working extension with the affected extension.
- Test more than one outbound route or destination only if your call plan permits it.
Do not assume the displayed name proves that the number was wrong. CNAM, or caller ID name, often comes from a separate database. This article focuses mainly on the outbound calling number, sometimes called CLI or presentation number.
A controlled test also matters. Avoid repeated calls to emergency services or destinations with special billing rules. If the issue affects all users, schedule testing with the carrier and keep the test window short.
Map the outbound caller ID path
Think of caller ID as a value moving through a chain. The extension supplies a starting identity. FreePBX chooses an outbound route and trunk. Asterisk builds SIP signaling for the call. The provider then validates the identity and sends it toward the public telephone network.
Each stage can produce a different result. For example, a route may override the extension. A trunk may have a fixed caller ID. The provider may allow only numbers assigned to the account. A downstream carrier may format the number for the recipient.
Extension settings
Open the affected extension and inspect its outbound caller ID field. In many FreePBX installations, this setting controls the identity used when the extension places a call. Check for extra spaces, unexpected punctuation, a short extension number, or a number that no longer belongs to the business.
Compare the field with a known working extension. Do not copy a value blindly. The provider may permit a main number but reject an individual direct number. Also check whether the extension has a privacy or anonymous-calling option enabled.
After a change, apply the configuration and place one controlled test call. Keep a note of the old value so you can roll back if the result changes in an unexpected way.
Outbound route and dial pattern
Next, identify the outbound route that handles the test number. Dial patterns decide which route matches. A more specific pattern should normally take precedence over a broad pattern, but the exact behavior depends on the configured routes and dialed digits.
Review the route’s caller ID or route-level override fields. An override can replace the extension’s identity for calls using that route. This setting may be intentional for a shared business line, a department, or a regulated calling workflow.
Check the route’s trunk sequence as well. The first available trunk may not be the trunk you expected. Different carriers can have different approved numbers and caller ID rules. A call that succeeds through a backup trunk may show a different identity.
If route behavior remains unclear, compare the result with the guidance in this FreePBX trunk diagnostic guide. It covers route selection, authentication, and call evidence without treating an online trunk as proof that every call setting is correct.
Inspect the trunk’s identity settings
Trunk configuration often contains the most confusing part of FreePBX outbound caller ID incorrect troubleshooting. Look for a trunk-level caller ID value, a “send caller ID” option, and settings that control whether the extension identity is preserved.
The exact field names vary by FreePBX version and by chan_pjsip or chan_sip configuration. Avoid assuming that two trunks with similar labels behave the same way. Record the current settings before editing them.
For a PJSIP trunk, inspect the identity-related fields in the trunk and any associated endpoint or identify sections. For a legacy SIP trunk, review the corresponding peer and outbound settings. If the graphical interface does not make the final behavior clear, an administrator may need to review the generated Asterisk configuration and a call trace.
Look for these common conflicts:
- An extension sends a direct number, but the trunk forces the main number.
- A route replaces the extension value before the trunk sees it.
- The trunk sends a number in a format the provider does not accept.
- A privacy setting removes or obscures the identity.
- A second trunk handles the call and applies different rules.
Do not edit generated files as a first choice. FreePBX may overwrite manual changes when you apply configuration or update a module. Use the supported interface, then verify the resulting call behavior.
Verify the SIP signaling, not just the form fields
FreePBX outbound caller ID incorrect troubleshooting should include the signaling sent by the PBX, not only the values shown in the web interface. The receiving carrier acts on signaling sent by the PBX. Depending on the trunk technology and provider, caller identity may appear in a From header, P-Asserted-Identity, Remote-Party-ID, or another provider-specific field.
A qualified administrator can capture a sanitized SIP trace for one test call. Compare the intended number with the identity fields actually sent. Remove account credentials, authentication data, phone numbers, and other sensitive information before sharing logs.
Read the trace alongside the provider’s documentation. Asterisk’s official documentation explains SIP and dialplan concepts, but it cannot establish the rules of your particular carrier. The provider may require a specific header, number format, or account-level permission.
Do not infer the caller ID from the audio recording or from the phone’s local display. Those sources do not show what the carrier received. The signaling trace and the carrier’s call records provide stronger evidence.
Check provider requirements and number ownership
Many providers restrict outbound caller ID to numbers associated with the customer account. Some support verified numbers, main business numbers, direct inward dial numbers, or specific geographic formats. Others may rewrite unapproved values instead of rejecting the call.
Ask the provider precise questions:
- Which caller ID numbers are approved for this trunk?
- Must the number use a country code, national format, or another format?
- Which SIP header does the service honor?
- Does the account need verification before a number can appear?
- Does the carrier rewrite numbers on calls to particular destinations?
- Can support confirm the caller ID received for a test call?
Provider behavior can also vary by destination. A domestic mobile network, international carrier, or business phone system may present the number differently. Therefore, test results from one recipient do not prove that every recipient sees the same identity.
Keep written confirmation of approved numbers and formats. That record helps prevent a later configuration change from reintroducing the problem.
Use a safe comparison and rollback method
Change one layer at a time. Start with the extension, then the route, then the trunk. Apply the configuration after each planned change and place one controlled test call. If you change three fields together, you may fix the symptom without learning the cause.
Before editing, export or document the relevant configuration. Include the extension number, route name, trunk name, original caller ID values, and test results. Never include trunk passwords in a ticket or shared screenshot.
If a change makes calls fail, restore the previous value and retest. A caller ID correction should not silently break route selection, emergency calling, international dialing, or calls through a backup provider.
Use a maintenance window when many extensions share the same trunk. A trunk-level change can affect every outbound call. Also confirm that emergency-service caller ID remains compliant with the provider’s requirements.
What not to assume
Several assumptions lead technicians toward the wrong fix. A registered trunk proves that signaling authentication works; it does not prove that caller ID is authorized. A successful call proves that routing works; it does not prove that the displayed number is correct.
Likewise, changing the phone’s display name will not necessarily change the public caller ID. The handset may show a local label while the network receives a different identity. NAT, or network address translation, can affect traffic paths, but it is not automatically the cause of a caller ID mismatch.
Finally, do not copy configuration from an unrelated provider. Carrier requirements differ. Use evidence from your own trunk, one controlled call, and the provider’s support response.
When to escalate the investigation
Escalate when the PBX sends the expected identity but the provider rewrites it, when only one trunk behaves differently, or when a change affects emergency or international calling. This FreePBX outbound caller ID incorrect troubleshooting process may require comparing Asterisk logs, SIP traces, route matches, and carrier call records.
For related inbound identity issues, see the guide to missing or incorrect inbound caller ID. If one extension behaves differently from the rest, compare that extension with a working phone before changing shared trunk settings.
Tech Rescue Ops LLC can help when the caller ID path crosses FreePBX, Asterisk, multiple trunks, and provider rules. Professional remote assistance is appropriate when you need a controlled trace, configuration backup, carrier coordination, or safe rollback.