FreePBX attended transfer failures can occur even when the consultation call answers and both people hear each other. The failure happens at completion: the receptionist presses Transfer, but the caller stays on hold or disconnects. That pattern needs a focused check of signaling and call state, not another registration test.
This guide targets transfers that fail after a successful consultation. For problems before that stage, start with the general FreePBX transfer checklist. Here, the goal is to identify which system should join the calls and why that step fails.
Separate Transfer Behavior From SIP REFER
Blind and attended describe how people transfer calls. SIP REFER describes one signaling method that phones can use. These are not three separate, competing transfer types.
- Blind transfer: The user sends the caller to a destination without first speaking to its recipient.
- Attended transfer: The user calls the recipient, speaks with them, then completes the handoff.
- SIP REFER: A device asks another system to contact a specified destination. Either transfer style can use it.
SIP means Session Initiation Protocol, which controls call setup and related actions. Some phones send REFER through their transfer buttons. Other workflows use keypad feature codes that Asterisk handles inside the call.
Attended REFER commonly includes Replaces information identifying the consultation dialog. A dialog is the signaling relationship for one call leg. The receiving system must match that information to the correct existing call.
Therefore, a working blind transfer does not prove attended transfers will work. Attended completion adds an existing consultation call and its current state to the process.
Build a Controlled Attended Transfer Test
Use three participants: the original caller, the transferring user, and the recipient. Choose test extensions and an approved outside number. Avoid emergency numbers, premium destinations, and active customer calls.
Keep the original call connected while the transferring user places the consultation call. Confirm that the recipient answers and both users hear speech. Then press the completion control once and record each participant’s result.
- Record the exact time and time zone.
- Note extension numbers, phone models, firmware, and transfer-button steps.
- Identify whether the original caller and recipient are internal or external.
- Record whether the caller hears hold music, ringing, silence, or a disconnect.
- Repeat once with a blind transfer to the same destination.
Next, compare internal-to-internal completion with an inbound caller transferred externally. Keep the phone and button sequence unchanged. A failure limited to external destinations suggests a route, trunk, or provider boundary.
If another phone model succeeds, compare its signaling before changing PBX-wide settings. Button labels alone cannot establish which transfer method either phone uses.
Capture Signaling and Asterisk Call State Together
FreePBX manages configuration, while Asterisk runs the calls. Collect evidence from both signaling and Asterisk’s live channels. A channel represents one call leg; a bridge joins channels for conversation.
For an authorized administrator, these Asterisk console commands provide useful starting points:
core show channels verbose
bridge show all
pjsip show endpoint <endpoint-name>
dialplan show <extension>@<context>Replace placeholders with values from the test call. The PJSIP command applies only to endpoints using that SIP driver. Check command availability against the installed Asterisk release and its official documentation.
Take snapshots before consultation, after answer, and immediately after completion. Fast changes may require event logs rather than manual snapshots. Record channel names, bridge identifiers, dialplan locations, and hangup causes.
When necessary, pjsip set logger on enables SIP logging for PJSIP. This can generate heavy output and expose numbers, addresses, and authentication details. Limit collection to an approved test window, protect the files, and finish with pjsip set logger off.
Do not raise logging indefinitely or restart Asterisk just to clear the symptom. Either action can disrupt service or remove useful evidence.
Trace FreePBX Attended Transfer Failures Through REFER
First, establish whether the transferring phone sends REFER when the user completes the transfer. If it sends nothing, investigate its button workflow, provisioning, and endpoint capabilities. An Asterisk-managed feature-code transfer may not send REFER, so confirm the intended method.
When REFER appears, follow these checkpoints:
- Recipient: Determine whether the phone sends the request to Asterisk or another system.
- Target: Inspect
Refer-To, the header naming the requested destination. - Consultation identity: Check any
Replacesvalue against the consultation call’s identifiers and tags. - Acceptance: Read the response from the system receiving REFER.
- Outcome: Inspect subsequent NOTIFY messages and the resulting call activity.
Under the standard REFER subscription flow, NOTIFY reports progress and the final result of the referred action. A 202 Accepted response alone does not prove that the transfer completed. The SIP REFER specification explains that distinction.
A final failure report points to a different stage than an immediate REFER rejection. Likewise, a successful signaling result followed by silence calls for a media check. Do not treat every failure as a transfer-permission problem.
Inspect Dialog Matching and Bridge State
The recipient’s answer proves that the consultation leg connected. It does not prove that Asterisk can associate that leg with the original caller at completion.
Compare the consultation dialog’s Call-ID and its two tags with the transfer’s replacement information. These values distinguish one dialog from another. Check their orientation carefully rather than assuming that matching phone numbers establish a match.
Asterisk acts as separate SIP peers on different call legs. Consequently, dialog identifiers can differ across the PBX. Compare identifiers at the relevant receiving interface, not across unrelated legs.
Then inspect the bridge timeline. The transferring user may move between the original conversation and the consultation bridge. After completion, the original caller and recipient should have a valid conversation path without that user.
- Did the recipient hang up just before completion?
- Check whether the phone ended the consultation before sending its transfer request.
- Look for Asterisk reports of a missing dialog or channel.
- Determine whether the original caller left its bridge before the replacement path existed.
Custom call-control applications can also affect bridge ownership. Trace their events alongside SIP messages. Avoid prescribing one bridge layout as mandatory for every Asterisk deployment.
Check Transfer Context and Endpoint Permissions
The dialplan is Asterisk’s call-routing logic. A context is a named part of that logic with its own reachable destinations. The consultation call and transferred call may follow different contexts.
Locate the actual context and destination in the logs. Then inspect the matching dialplan. A recipient reachable during consultation may still fall outside the transferred caller’s permitted path.
For PJSIP, review the effective endpoint transfer permission, including allow_transfer where applicable. For keypad-driven transfers, inspect the feature configuration and relevant Dial options instead. These controls govern different mechanisms.
Also compare the phone’s transfer mode and support for attended REFER with replacement information. An advertised capability does not guarantee that every button sequence uses it correctly.
Make changes through supported FreePBX settings or documented custom configuration methods. Direct edits to generated files can disappear after a configuration rebuild. Do not solve a restricted transfer by granting callers broad access to internal or paid destinations.
Distinguish PBX-Routed Calls From Provider Transfers
An external transfer can create a new outbound call through Asterisk. Alternatively, a supported workflow may ask the provider to perform the transfer through REFER. Those paths have different requirements.
If Asterisk sends a new INVITE, inspect number formatting, route matching, outbound identity, and trunk capacity. INVITE is the SIP request that starts a call. Follow the outbound route audit for that new leg.
If Asterisk sends REFER to the provider, confirm that the provider supports that operation on your account. Ask about external targets, attended replacement support, and authorization rules. Do not assume trunk registration establishes transfer support.
A provider that never receives REFER cannot explain a local REFER rejection. Conversely, successful local dialog matching cannot override an upstream restriction. Use the trace to assign the failing step to the correct system.
Verify the Fix and Preserve Escalation Evidence
Change one setting at a time and retain its previous value. Retest consultation, completion, two-way audio, and hangup behavior. Confirm that abandoning the consultation still lets the user recover the original caller.
For FreePBX attended transfer failures, keep a short evidence package: timestamps, participant roles, sanitized SIP messages, channel identifiers, and bridge events. Include a successful comparison and the exact step where results diverge. Preserve consistent identifiers when sanitizing traces so an engineer can correlate events.
Professional remote assistance is appropriate when dialog matching, custom dialplan logic, or provider handoff remains unclear. Tech Rescue Ops LLC can help trace that boundary and plan a limited change without broadening calling permissions.