FreePBX transfer fails, returns the caller or reaches the wrong destination

Capture the exact user action and symptom

Record the transferring extension and phone model, the original caller and called extension, the intended destination, whether the user selected blind or attended transfer, every key pressed or digit sent, and the observed result. Distinguish immediate release, consultation then completion, transfer cancel, caller returned, caller disconnected, wrong destination, voicemail, busy, silence and one-way audio.

Sangoma documents separate phone Transfer-key behavior, in-call Asterisk blind and attended feature codes, and BLF-button transfer modes. A BLF key may default to blind transfer on some managed Sangoma phone configurations while attended mode creates a second consultation call. Do not assume a label on the key proves the emitted SIP or DTMF action.

Separate phone-native and Asterisk-core paths

Capture the signaling and Asterisk events for one bounded test. If the phone sends REFER, follow the SIP REFER diagnostic and retain the Refer-To target, response and resulting subscription or NOTIFY evidence. If it sends an in-call digit sequence, prove the active feature map and Dial or Queue permission on the original bridge. If the PBX dialplan invokes BlindTransfer() or AttendedTransfer(), preserve its context and status variable.

A phone-side success message, SIP 202 response, detected feature code or application SUCCESS can each stop before the final destination answers. Keep selection, authorization, new channel creation, destination result, final bridge and usable media as separate checkpoints.

Verify party direction and transfer context

For an Asterisk core feature, identify whether the caller or called party initiated the transfer and whether the bridge allowed that direction. Lowercase and uppercase transfer options apply to different parties. Then record the effective transfer context and target extension. The same digits in an internal, restricted, tenant, inbound or outbound context can intentionally select different destinations or no destination.

Do not solve a permission or context mismatch by enabling universal transfers or exposing external routes. Preserve extension class of service, emergency restrictions, toll controls, recording obligations and caller identity. Test an explicitly denied destination to verify the policy boundary as well as one approved destination.

Trace the attended consultation state

When attended transfer fails, preserve the held caller, consultation channel and destination disposition. Determine whether the user completed, aborted, swapped, made a three-way bridge or hung up under a configured completion rule. A no-answer timeout or invalid destination can trigger callback or return behavior; that may be correct policy rather than a random reconnection.

Correlate unique and linked IDs across the original call and consultation leg. If the consultation works but the parties do not join, inspect the completion action and final bridge. If the destination never rings, stay with digits, context, permission and channel creation. If the final bridge forms but audio or recording is wrong, move to the dedicated media or recording diagnostic while retaining the transfer timeline.

Correct one owner and retest every branch

Correct only the demonstrated owner through supported FreePBX or managed phone controls: key mode, feature code, generated Dial or Queue permission, transfer context, route policy, destination or attended-transfer behavior. Apply configuration and confirm the loaded Asterisk state on a fresh call. Avoid direct generated-file edits that the GUI can overwrite.

Retest blind and attended paths, cancel, busy, no-answer, invalid and denied destinations, transferrer hangup, destination hangup, the relevant BLF shortcut, caller and connected identity, recording continuity and both audio directions. Preserve transfer and bridge events for the tested interval, then remove temporary logs. No FreePBX host, module, phone, endpoint, feature code, key, SIP exchange, channel, bridge, route, recording, identity, audio path, compatibility, availability, price or call was inspected or tested for this diagnostic.

Separate GUI policy from AMI bridge-relative transfer

For a manager-driven symptom, use the AMI transfer diagnostic.

Trace an attended-transfer abort below the GUI

For manager-driven cancellation, use the CancelAtxfer diagnostic.