Asterisk AMI transfer control: Redirect, BlindTransfer and Atxfer

Choose a control contract before sending an action

AMI exposes three different transfer contracts. Redirect sends a named channel to a dialplan context, extension and priority and can optionally redirect a second named leg to its own destination. BlindTransfer redirects all channels currently bridged to the specified channel to a context and extension. Atxfer starts an attended transfer from the specified transferer channel to a context and extension.

Do not substitute one action because another returned an error. Record the intended surviving parties, transferer, transferee, destination and desired dialplan entry before choosing the action.

Treat Redirect as explicit dialplan relocation

Redirect requires Channel, Exten, Context and Priority. Its optional ExtraChannel, ExtraExten, ExtraContext and ExtraPriority describe a second call leg and destination. Omission of the second-leg fields is a one-leg request, not an instruction to infer the peer automatically.

Resolve every supplied channel immediately before the request and retain stable IDs where available. Validate both dialplan destinations as one change when using the extra leg; a valid primary destination does not make an omitted or invalid extra destination safe.

Keep BlindTransfer bridge-relative

The documented BlindTransfer action takes Channel, Context and Exten and redirects the channels currently bridged to that channel. That bridge-relative scope is different from Redirect naming one or two channels explicitly.

Prove which live bridge contains the supplied channel and which party is the transferer before mutation. A stale or wrong channel can select the wrong bridge relationship even when the destination itself is valid.

Keep Atxfer transferer-relative

Atxfer takes the transferer channel plus destination context and extension. An attended transfer can create a second transferer channel and a second bridge before completion; those are not safely reconstructed from display names alone.

Retain original and second transferer identities, their bridge IDs and event chronology. The attended-transfer event can describe Bridge, App, Link, Threeway or Fail destination types, so completion is not one universal topology.

Use transfer events as outcome evidence

BlindTransfer and AttendedTransfer events report Result values including Fail, Invalid, Not Permitted and Success. The upstream note is explicit: Success means a party was placed into the dialplan at the expected location; it does not necessarily mean the target was contacted.

Correlate transferer and transferee stable IDs, bridge IDs, destination context and extension, and attended destination type. Keep action response, transfer event, dialplan entry, target answer, final bridge and media as separate evidence stages.

Separate internal transfer, native transfer and media

The blind-transfer event exposes IsExternal, distinguishing a transfer performed outside Asterisk, such as a channel-protocol native transfer, from an internal DTMF transfer. That event field does not turn AMI, SIP REFER, feature codes and dialplan transfer applications into the same mechanism.

After the intended call topology is proved, verify connected-line identity, recording continuity, negotiated streams, packet flow and audible media separately. No AMI session, user, permission, host, manager action, channel, bridge, dialplan destination, packet, media stream or live call was inspected or tested for this guide.

Cancel the active attended transfer through its own contract

The AMI cancel-and-recovery guide covers CancelAtxfer, atxferabort, re-bridging and failure callbacks.

Keep Local query modifiers distinct from transfer success

The AMI Local optimization guide explains /b without treating it as optimization or transfer proof.

Refresh channel and bridge identity before transfer control

The channel snapshot diagnostic bounds manager lists and re-resolves live targets.

Confirm transfer-event subscription independently

The AMI event diagnostic separates action acceptance from transfer-event delivery.