Asterisk call transfers: blind, attended and bridge evidence

Identify which transfer engine owns the action

Asterisk documents core blind and attended transfers activated through DTMF feature codes during an answered bridge. It separately notes that channel drivers such as PJSIP can provide native transfer capabilities. A phone's Transfer or BLF key can therefore invoke local phone logic, send a SIP REFER, generate digits for the Asterisk core feature, or use a managed vendor workflow. BlindTransfer() and AttendedTransfer() add dialplan-application paths. These are not interchangeable implementations.

Capture the initiating phone action, any digits, SIP methods, bridge feature, dialplan application and management surface before changing configuration. A SIP REFER accepted by one hop, an Asterisk feature entered, a transfer application returning success and a final destination answering are different states. Use the existing SIP REFER guide for protocol-level acceptance and this guide for Asterisk bridge ownership.

Grant the correct party permission

Core feature-code transfer requires an answered, bridged call, a configured blindxfer or atxfer sequence and permission for the initiating channel. Asterisk's Dial and Queue options use lowercase t to allow the called party to transfer the calling party and uppercase T to allow the calling party to transfer the called party. Those flags authorize the core DTMF feature; they do not enforce policy for every native phone, SIP REFER, AMI, ARI or dialplan-application path.

Record which party is the caller and called party on the original bridge and which one initiated transfer. Avoid enabling both directions broadly merely to make one phone work. Transfer can redirect an authenticated caller to a different destination, recording scope or toll route, so destination context, class of service, caller identity and recording policy need explicit ownership.

Preserve attended-transfer phases

An attended transfer creates a consultation phase: the transferee is held while the transferrer calls the destination, then the transferrer can complete, abort, swap between parties or form a three-way bridge according to configured controls. Asterisk documents separate atxferabort, atxfercomplete, atxferthreeway and atxferswap actions plus callback behavior when the destination cannot be reached. A hangup is therefore not automatically abandonment; it can be the configured completion signal.

Keep the original bridge, held transferee, consultation channel, destination result and final bridge separate by unique ID and linked ID. Busy, no answer, invalid destination, transferrer hangup and transfer-target hangup can take different branches. A successful consultation call does not prove the transferee was connected, and a completed transfer does not prove two-way audio or the expected identity and recording state.

Keep contexts and application results bounded

BlindTransfer(extension,context) redirects channels bridged to its caller and reports SUCCESS, FAILURE, INVALID or NOTPERMITTED. If context is omitted it uses the caller channel context. AttendedTransfer(extension) uses TRANSFER_CONTEXT and reports whether the operation was successfully queued, failed or was not permitted. A queued status is not the final destination outcome.

Preserve entered digits, selected context, matched extension, generated channels and downstream disposition. Duplicate extensions in different contexts are different targets. FEATUREMAP() can override a feature sequence per channel, so the value loaded on the active channel can differ from the global file. Do not diagnose a context or permission failure by changing codecs, NAT or registration.

Correlate transfer events with final service

Asterisk's AMI specification exposes distinct BlindTransfer and AttendedTransfer events. CEL can record BLINDTRANSFER and ATTENDEDTRANSFER events and retains linked identifiers for cross-channel reconstruction. These events are stronger evidence of the selected transfer mechanism than a user hearing a beep, but they still do not prove destination answer, final bridge stability, identity, recording continuity or media quality.

In an authorized test, exercise blind completion, attended completion, abort, busy, no-answer, invalid and denied-destination branches from each approved phone workflow. Correlate channel and bridge events, final dialplan destination, connected-line identity, recording segments and both audio directions. Remove temporary debug logging and protect call metadata. No PBX, endpoint, phone, channel, bridge, dialplan destination, feature code, DTMF sequence, native SIP transfer, recording, identity, media path or call was inspected or tested for this guide.

Trace identity after the bridge changes

A completed transfer can change the connected party without changing the original caller. Use the connected-line and redirecting guide to preserve channel state, loaded PJSIP send and trust controls, SIP updates and endpoint display separately.

Separate bridge exit from party transfer

The after-bridge guide distinguishes a channel-owned exit target from Dial() and Bridge() options that move one party when the other answers or hangs up.

Remap interception after a transfer changes channel ownership

The HOLD_INTERCEPT guide keeps former and replacement channels separate; a linked ID or earlier set operation does not prove the new device leg is intercepted.

Delegate incoming REFER handling to ARI deliberately

The PJSIP transfer-handling guide adds endpoint permission, channel timing, ChannelTransfer events, application actions and NOTIFY progression to the transfer evidence model.

Bridge feature options are party-specific

The Bridge guide keeps lowercase and uppercase DTMF feature ownership attached to the target and executing parties.

Add the manager-action transfer surface

The AMI transfer-control guide covers Redirect, BlindTransfer and Atxfer without merging them with feature codes, applications or native SIP transfer.

Add attended-transfer cancellation and recovery

The AMI cancel-and-recovery guide distinguishes abort, complete, swap, three-way and callback behavior.

Expect channel and bridge identity to change during transfer

Use the channel identity guide to correlate the intended leg before and after transfer rather than targeting an old name.

Re-evaluate feature roles after a bridge change

The dynamic-feature diagnostic resolves self and peer from the channel that supplied digits rather than stale caller and callee labels.