When FreePBX internal extension calls fail, the phone may still appear registered. That fact narrows the problem, but it does not prove that the dialplan can route the call. Internal calling depends on several linked settings: extension status, dial patterns, permissions, contexts, endpoint details, and generated Asterisk configuration.
Work through those layers in order. Start with evidence from one working extension and one failing extension. Avoid changing multiple settings at once. A controlled comparison usually finds the difference faster than rebuilding phones or restarting the PBX without a clear reason.
Confirm the failure and establish a comparison
First, record the exact call attempt. Note the calling extension, called extension, time, phone model, displayed error, and whether the destination phone rings. Also record whether the caller hears reorder tones, a busy signal, silence, or an announcement.
Test both directions. Have extension 201 call 202, then have 202 call 201. If only one direction fails, compare the two extensions rather than treating the PBX as a single broken system. A single extension problem may involve its permissions, endpoint, or device configuration.
- Can the caller dial another internal extension?
- Can another phone call the same destination?
- Does the destination phone ring, show a missed call, or remain idle?
- Does the problem affect desk phones, softphones, or both?
- Did the issue begin after an extension, route, or provisioning change?
For a broader comparison method, see this guide to troubleshooting calls from one extension. It covers useful checks for registration, permissions, device settings, and call traces.
Check extension status before reviewing the dialplan
In FreePBX, open the extension list and confirm that both extensions exist. Check the extension numbers carefully. A caller may be dialing a stale number, a duplicate record, or a number that belongs to a different device.
Next, review the device status under the relevant endpoint or Asterisk status view. A registered phone proves that signaling reached the PBX. It does not prove that the phone can use the intended internal route.
Look for these differences:
- One extension uses a different technology or endpoint driver.
- A device registers to an unexpected IP address.
- The phone has an old account, line key, or extension assignment.
- The extension was disabled or removed from the generated configuration.
- A softphone uses a different identity than the user expects.
Do not reset passwords or recreate extensions yet. Capture the current settings first. If the phone is not registered, solve that separate endpoint problem before interpreting an internal call trace. When FreePBX internal extension calls fail, registration status is useful evidence, but it is only the first layer.
Review dial patterns and internal number handling
Dial patterns tell FreePBX how to interpret digits. Internal extension calls normally use a local extension pattern, but the exact pattern depends on the numbering plan. A three-digit system may not handle a four-digit destination correctly. Prefixes, feature codes, and overlapping ranges can also create ambiguity.
Review the extension range and outbound route patterns together. An outbound route should not accidentally capture an internal number. Route priority matters because FreePBX evaluates matching routes in order. A broad pattern can take precedence over a more specific internal path.
Compare the digits sent by the phone
Some phones send digits immediately. Others wait for a timeout, require a send key, or apply a dial-plan rule locally. That local rule may remove digits, add a prefix, or reject a number before the PBX receives it.
Check the phone or softphone configuration for:
- Dial plan templates and interdigit timeouts.
- Automatic prefixes or access codes.
- Digit maps that treat an extension as incomplete.
- Line keys assigned to the wrong account.
- Provisioning values that differ from the FreePBX extension record.
Use a known-good phone to dial the same destination. If the known-good phone works, focus on the failing endpoint. If every phone fails, continue toward permissions, contexts, and the generated dialplan. This comparison is especially helpful when FreePBX internal extension calls fail for only one device.
Inspect permissions, classes, and contexts
FreePBX uses settings that control what an extension may dial. Depending on the installation, these settings may include user or device mode, class of service, route permissions, and custom context modules. A restriction can block internal dialing even when the extension appears healthy.
Compare the caller with a working extension. Pay particular attention to any field that assigns a calling class, restricts destinations, or places the extension in a custom context. Also check whether a recent policy change affected a group of users.
A context is a dialplan scope. It determines which destinations a channel can access. In Asterisk, an extension can exist in one context while the caller searches another. The number may look valid, yet the caller never reaches the expected internal target.
Do not copy a permissive context from another system without understanding its purpose. A broad context can expose trunks, feature codes, or administrative destinations. Review the vendor or administrator documentation for the installed modules and preserve a rollback path.
The official Asterisk documentation explains core concepts such as channels, endpoints, contexts, and dialplan behavior. Use it to interpret the trace rather than guessing from a single error message.
Validate endpoint configuration and phone provisioning
Endpoint configuration connects a device to an extension. In current FreePBX deployments, many systems use PJSIP, while older systems may use a different channel technology. The important question is whether the phone presents the identity and capabilities that FreePBX expects.
Compare the failing endpoint with a working one. Check the endpoint name, authentication identity, assigned extension, transport, codecs, and contact address. Avoid changing transport or codec settings simply because they look different. Internal call setup usually fails because of identity, routing, or permission mismatches, not because every setting must match.
Provisioning can also reintroduce a bad value. If a phone downloads its configuration from a provisioning server, a manual correction may disappear after reboot. Confirm the source of the setting and the last provisioning time.
- Confirm that the line key uses the intended extension.
- Check whether the endpoint has multiple accounts or stale contacts.
- Compare registration address and user agent with the expected device.
- Review recent provisioning changes before reprovisioning.
- Save a configuration backup before making PBX changes.
If the phone registers but has no usable dial behavior, compare it with this guide to a registered phone with no dial tone. The symptoms overlap, but the diagnostic evidence differs.
Trace the call through the generated dialplan
When configuration comparisons do not explain the failure, capture a call trace. Make one test call while watching the Asterisk console or the supported FreePBX troubleshooting tools. Record the exact digits, channel, context, selected application, and final result.
The trace should answer a few specific questions:
- Did Asterisk receive the digits?
- Which context handled the call?
- Was the number matched to an internal extension?
- Was a permission check rejecting the destination?
- Could the PBX create a channel to the target endpoint?
- Did the destination answer, reject, or time out?
A trace with no matching extension calls for a review of the number format, context, and generated configuration. For a match that rejects the call, examine permissions and endpoint availability. When the PBX attempts the destination but receives no response, focus on the endpoint, contact address, or device state.
Use trace output as evidence, not as a reason to edit files directly. FreePBX generates much of the Asterisk configuration. Manual edits can be overwritten and may leave the web interface out of sync.
Apply one controlled correction and retest
Once you identify the layer, change one related setting. For example, correct the caller’s context, repair a dial pattern, or assign the endpoint to the intended extension. Document the original value before saving.
Apply the configuration through FreePBX where possible. Then place the same test call in both directions. Test a second pair of extensions as well. Confirm that the repair did not grant unexpected external dialing or disrupt voicemail, transfers, queues, or emergency calling.
Use the same evidence trail to confirm whether FreePBX internal extension calls fail only under one context or across the system.
Restarting a phone may be appropriate after provisioning changes. Reloading or applying PBX configuration may be necessary after FreePBX changes. However, the correct action depends on the installation and change. Avoid an unplanned reboot during active business hours.
When to escalate the investigation
Escalate when traces contradict the web interface, custom contexts are involved, or several extensions fail after one change. Also pause before editing generated files, changing authentication settings, or modifying routes that affect emergency and external calls.
Keep the call times, extension numbers, trace excerpts, configuration differences, and test results together. That record lets an administrator reproduce the problem without repeating risky experiments.
When FreePBX internal extension calls fail after a controlled comparison, the fastest next step is often an experienced review of the generated dialplan and endpoint state. Tech Rescue Ops LLC can help collect traces, verify the call path, and make a documented correction with a rollback plan.