FreePBX call transfer not working troubleshooting starts with one question: what happens after the user presses Transfer? The call may disconnect, return to the original caller, reach the wrong destination, or remain connected without completing the handoff. Each result points to a different part of the call path.
A transfer involves more than the handset. The phone sends signaling to FreePBX, the PBX checks the extension and dialplan, and the endpoint handles the user interface. A careful test can separate those layers without changing production settings blindly.
For FreePBX call transfer not working troubleshooting, begin with a controlled test rather than a global configuration change. Capture the exact call result before adjusting settings.
First, define the transfer failure
Ask the user to describe the exact sequence. Record the phone model, extension, destination, and whether the transfer was attended or blind. Also note whether the problem affects every call or only external calls.
- Attended transfer: the user calls the destination first, speaks with the recipient, then completes the handoff.
- Blind transfer: the user sends the caller to the destination without speaking to the recipient first.
- Failed transfer: the caller returns to the original user, hears an error, disconnects, or reaches voicemail unexpectedly.
Test one internal destination and one external destination if policy permits. An internal transfer tests the PBX and endpoint with fewer dependencies. An external transfer may also involve outbound routes, trunk permissions, caller identity rules, and provider restrictions.
Use a working extension as a comparison. Make the same transfer from both phones, using the same destination. This comparison often identifies whether the issue follows the user, phone, extension, or destination.
Check feature codes and transfer controls
FreePBX can use feature codes for call actions. A feature code is a dialing sequence that tells the PBX to perform an operation, such as transferring or parking a call. However, the phone may use its own Transfer button and send a different signaling sequence.
Review the relevant feature-code settings in the FreePBX administration interface. Confirm that the expected transfer features remain enabled and that a custom code does not conflict with another function. Do not change codes during business hours unless you have a test extension and a rollback plan.
Next, check how the phone behaves when the user presses Transfer. Some phones place the caller on hold, open a new dialing field, or require a second button press. Others send a transfer request only after the destination answers. The phone’s display and button behavior can therefore matter as much as the PBX setting.
Compare attended and blind behavior
Start with an attended transfer. Place the caller on hold, dial an internal extension, wait for an answer, and use the phone’s completion control. If this works, test a blind transfer separately.
For blind transfers, watch for a completion step. Some endpoints require the user to press Transfer again after dialing. If the user hangs up too early, the PBX may interpret the action as a call release rather than a completed transfer.
Feature codes and phone buttons should produce a consistent result. If a code works but the button fails, focus on provisioning, firmware behavior, or the endpoint’s transfer mode. The official Asterisk documentation provides useful background on endpoints and dialplan behavior.
That comparison is central to FreePBX call transfer not working troubleshooting because it separates a PBX feature problem from a handset control problem.
Review extension permissions and destinations
A transfer can fail because the transferring extension lacks permission to call the destination. FreePBX permissions may differ between internal extensions, outbound routes, queues, ring groups, and special destinations.
Check the extension’s class of service, outbound route access, and any time condition that affects the destination. A user may transfer to another local extension but fail when sending a caller to an external number. That result points away from the basic transfer button and toward route or trunk authorization.
Verify the destination number as dialed. A user may need a prefix for an outside line, a specific area-code format, or a different route pattern. Avoid assuming that a number works simply because the user can call it directly. The transfer leg may apply a different context or permission set.
Also inspect the destination itself. A disabled extension, unavailable device, call-forwarding rule, do-not-disturb state, or follow-me setting can make a successful transfer appear broken. Check whether the destination rings, answers, forwards, or rejects the call.
If one extension has the problem, compare its settings with a known-good extension. Review permissions, assigned device, caller-ID policy, and any custom configuration. This approach is safer than changing global settings for a local problem. For related endpoint checks, see how to compare a failing VoIP extension with a working one.
Trace the dialplan flow safely
The dialplan is the set of instructions that determines how FreePBX handles a call. During a transfer, it may send the call into an extension context, ring group, queue, follow-me rule, voicemail box, or outbound route.
Use a test call and collect evidence at each stage. Record the time, source extension, destination, transfer type, and result. Then review the PBX call log and, where appropriate, an Asterisk console trace performed by someone familiar with the system.
- Confirm that the transfer request reaches the PBX.
- Identify the context and destination selected after transfer.
- Check whether FreePBX applies a permission or route restriction.
- Look for an unavailable, rejected, or invalid destination response.
- Confirm whether the original call remains held while the transfer leg proceeds.
Do not treat every console message as the root cause. A later failure may be a consequence of an earlier rejected request. Compare a successful transfer with a failed transfer and focus on the first meaningful difference.
Transfers can also interact with queues, ring groups, and call recording. For example, the destination may answer while the recording policy changes, or the transfer may enter a queue with its own permissions. If recording is part of the symptom, review the separate FreePBX recording troubleshooting guide rather than altering transfer settings first.
In FreePBX call transfer not working troubleshooting, the first meaningful dialplan difference matters more than a long list of later console messages.
Inspect endpoint behavior and provisioning
Provisioning is the process of delivering a phone’s configuration from a central system. A phone can register successfully while still having an incorrect transfer key, stale line assignment, or incompatible transfer mode.
Compare the affected phone’s configuration with a working phone of the same model. Check the line identity, transfer method, key assignment, hold behavior, and dial-plan settings. Vendor terminology varies, so verify the model-specific meaning before changing a value.
A stale configuration can survive a reboot. If the phone uses centralized provisioning, confirm that the server holds the intended settings and that the device downloaded them. Check the last provisioning time when the platform exposes it. Avoid factory-resetting a phone until you know its provisioning credentials and recovery process.
Firmware can also affect button behavior. If the problem began after a firmware or template change, compare the timing with configuration history. Test one device first. A broad phone update can turn a single endpoint problem into a wider service interruption.
For a phone that registers but does not behave correctly, review its local call controls as well as PBX settings. A registered endpoint proves network reachability and authentication. It does not prove that every feature is configured correctly.
Separate transfer problems from network symptoms
Most transfer failures are signaling or configuration problems, but network conditions can confuse the diagnosis. NAT, or network address translation, changes how private device addresses reach other networks. Firewall rules can also affect SIP signaling or the media path.
Look for patterns. If the transfer completes but one party cannot hear audio, investigate RTP media, NAT, and firewall handling. If the caller disconnects before the destination answers, inspect signaling and the transfer sequence first. Do not open broad firewall ports as a first response.
Use packet captures only with a defined test and proper privacy controls. Call traces may contain phone numbers, extensions, and audio-related metadata. Limit access, retain evidence only as long as needed, and follow the organization’s recording and privacy policies.
When the issue affects remote phones, compare an affected device on its usual network with a test device on a trusted local network. A difference may indicate NAT or firewall handling. For background, Cloudflare’s overview of NAT explains why address translation can change traffic behavior.
A practical test sequence
Run these checks in order and stop when the evidence identifies the failing layer:
- Test an attended internal transfer from the affected extension.
- Repeat the same test from a working extension.
- Test blind transfer and confirm the required completion step.
- Check whether the destination rings and answers normally.
- Compare extension permissions and route access.
- Review phone button assignments and provisioning status.
- Compare successful and failed call logs or traces.
- Test an external destination only after internal transfer works.
- Investigate NAT, firewall, or RTP symptoms if audio fails after handoff.
Write down each result. A short test record prevents repeated experiments and helps another technician continue the work. Structured evidence collection also makes it easier to distinguish a configuration fault from a provider or endpoint issue.
When to escalate the issue
Escalate when a change affects multiple extensions, when dialplan customization is involved, or when traces show unexpected contexts or applications. Extra care is also warranted for call centers, emergency calling, recording compliance, and transfers to external destinations.
Before changing production configuration, save the current settings and define a rollback. Schedule testing with a user who can confirm both attended and blind behavior. If the issue crosses phone provisioning, FreePBX, firewall, and carrier systems, a coordinated review is usually faster than isolated changes.
Tech Rescue Ops LLC can help examine endpoint settings, feature codes, permissions, dialplan traces, and provisioning without guessing at the cause. Professional remote assistance is appropriate when transfers affect many users, require controlled PBX changes, or involve call-flow and compliance risks.