Asterisk AMI attended-transfer cancel and recovery

Treat CancelAtxfer as an abort-feature invocation

The documented AMI CancelAtxfer action takes a transaction ActionID and the active transferer Channel. It cancels by using the configured atxferabort attended-transfer feature; the action fails when that option is unavailable. This is not a generic bridge rollback or a request against the transferee or transfer target.

Resolve the transferer at action time, retain its stable channel identity and correlate the exact response. A manager acknowledgement is not proof that the original parties are re-bridged or that media resumed.

Separate abort, completion, swap and three-way behavior

atxferabort cancels the attempt and the feature documentation says the original parties are re-bridged. atxfercomplete completes the transfer and bridges the target with the transferees. atxferswap changes which party the transferer is bridged with during consultation, while atxferthreeway puts the transferer, transferees and target in one bridge.

Record which operation was requested and which bridge relationship existed first. Do not interpret an abort as completion, a swap as recovery or a three-way bridge as a two-party transfer.

Prove the active attended-transfer state

An attended transfer can involve an original transferer channel and bridge, a second transferer channel and bridge, the transferee and the transfer target. Names can change and a leg can hang up or be replaced while an operator is deciding what to cancel.

Capture both transferer identities, their stable IDs, both bridge IDs and the transferee and target before mutation. If the request arrives after the transfer has already completed, failed or left its abortable phase, treat that chronology as evidence rather than retrying against a guessed channel.

Keep explicit abort separate from failure recovery

Explicit cancellation and post-failure callback behavior are different state paths. With atxferdropcall set to no, the current feature reference describes attempts to recall the transferer after target failure and further target attempts governed by atxfercallbackretries and atxferloopdelay. With it set to yes, the same reference describes no recall and all transfer channels hanging up.

Preserve the effective setting, no-answer timeout, retry count and observed call sequence. Do not represent the documented defaults as the loaded configuration.

Preserve the loop-delay documentation discrepancy

The current generated option table labels atxferloopdelay as seconds, while the prose description on the same page says milliseconds. The feature-code overview also describes seconds. This guide does not silently choose a unit.

Use local configuration help, the installed branch source or a controlled deployment-specific check to establish the effective unit before changing timing. Record the source and branch with the value so an apparent rapid retry or long pause is not diagnosed from an unresolved documentation conflict.

Verify topology, continuity and media after recovery

After an abort response, prove the expected original parties joined the surviving bridge and trace connected-line identity, recording ownership, hangup causes and both media directions. After callback recovery, identify each recall and target attempt instead of collapsing them into one call.

The attended-transfer event can report Bridge, App, Link, Threeway or Fail completion methods; it is not a universal abort receipt. No PBX, AMI session, manager user, permission, configuration file, feature code, channel, bridge, callback, packet, media stream or live call was inspected or tested for this guide.

Re-resolve transfer legs after Local optimization

The Local optimization diagnostic follows stable identity and surviving bridge membership.