Asterisk CancelAtxfer fails or the wrong call resumes

Freeze one cancellation chronology

Record installed branch, timestamp, manager identity, request ActionID, supplied channel, stable channel IDs, original and second bridge IDs, transferee, target, action response, transfer events, bridge events, callback attempts, final topology and caller-visible result.

Classify the first symptom: action unavailable, permission failure, abort option unavailable, stale or wrong transferer, accepted request with no re-bridge, wrong parties resumed, callback loop, premature teardown, identity change, recording discontinuity or one-way audio.

Verify action and abort-option availability

Check local manager action help, loaded module state and the manager account permissions on the running branch. Then inspect the effective atxferabort configuration. The upstream action documentation says cancellation uses that option and fails if it is unavailable.

Do not infer loaded behavior from a generated latest-branch page or from a default shown in a reference table. Separate transport, authentication, authorization, parsing, missing action and unavailable abort-feature failures.

Resolve the transferer and phase again

CancelAtxfer expects the transferer channel. Correlate that channel with its stable identity and the active attended-transfer operation immediately before the request. Preserve the original and second transferer plus both bridges when they exist.

A request issued after completion, failure, hangup or channel replacement is not the same failure as a valid request during consultation. Do not retry against the transferee, target or a display-name match.

Prove re-bridging instead of assuming it

The feature documentation defines abort as cancelling the transfer and re-bridging the original parties. Verify that outcome with bridge membership and channel identities. An accepted manager response alone does not prove the bridge transition, connected identity, recording continuity or media.

Keep atxfercomplete, atxferswap and atxferthreeway evidence separate. If the resulting party set differs, first determine whether a different control was invoked or the transfer had already changed phase.

Trace failure callbacks and timing literally

For target failure or an early transferer hangup, capture effective atxferdropcall, atxfernoanswertimeout, atxfercallbackretries and atxferloopdelay, then label each recall and target attempt. With drop-call disabled, callback recovery can create several distinct legs; with it enabled, teardown behavior is intentionally different.

The current generated features page conflicts internally on whether loop delay is seconds or milliseconds. Establish the installed behavior before attributing a retry storm or long delay to the configured number.

Follow the surviving call into media

After the expected parties resume, verify connected-line state, recording segments, hangup causes, negotiated streams, packet flow and audible media in both directions. A correct re-bridge can still expose a separate signaling or media fault.

Do not repair wrong-channel selection or missing abort configuration by changing codecs, NAT or registration. 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 diagnostic.

Rebuild transfer topology after Local optimization

The Local optimization diagnostic follows stable identities through channel removal, movement or bridge merging.