Asterisk AMI Hangup: target, cause and final-event evidence

Resolve one disposable channel before control

Record the Asterisk node, installed release, manager identity, unique ActionID, exact Channel, Uniqueid, Linkedid, bridge membership, channel creation time, current application, intended policy owner and synchronized time. Resolve the live channel immediately before the action.

The Hangup action targets a channel, not a caller, endpoint, bridge or whole linked call. Caller ID, connected-line values and Linkedid can be shared or changed; none safely replaces the current Channel and Uniqueid pair.

Treat regular-expression targeting as a separate hazard

Current, Asterisk 22 and Certified 22.8 action references accept either an exact Channel or a slash-delimited regular expression. A regular expression can match more than one live channel, including channels created after an earlier inventory.

Do not turn a display prefix into a production bulk-hangup selector. Prefer one exact resolved channel. If an approved maintenance workflow truly requires a pattern, preserve the literal expression, dry inventory, matched Uniqueids, authorization, change window and stop condition before sending it.

Keep the numeric cause at the Asterisk boundary

The generic Hangup action documents a numeric Cause. Asterisk publishes mappings between internal causes, Q.850 or Q.931 values and several channel technologies, but those mappings are not one universal signaling result.

Record the requested numeric cause, the target technology, call phase and later event fields separately. Do not substitute a SIP status phrase, assume a one-to-one downstream response or infer what a remote endpoint displayed without protocol evidence.

Separate action response, request and final disposal

AMI is asynchronous: an action response and later events are not one synchronized transaction. Preserve the raw action response with its ActionID, then correlate HangupRequest or SoftHangupRequest and the final Hangup event by exact Uniqueid and time.

SoftHangupRequest reports a soft request with a cause. The final Hangup event reports the disposed channel with Cause, Cause-txt and, for off-nominal technology detail, TechCause. Acceptance or a request event is not proof that the channel has reached final disposal.

Inspect linked legs and cleanup independently

Linkedid identifies the oldest channel associated with a channel; it is not a whole-call completion event. Transfers, Local channels, queues, bridges and masquerade or replacement behavior can leave another related channel alive after the selected Uniqueid ends.

Hangup handlers and h-extension cleanup belong to the owning channel and dialplan. Prove their ordered events, duration and effects separately. A delayed final Hangup can be cleanup work, event filtering or an identity mismatch rather than failure to accept the action.

Validate a bounded policy path, not a live customer call

Use a dedicated least-privilege manager identity and one disposable nonproduction call. Prove fresh identity, exact target, accepted request, request-event sequence, final event, cause fields, bridge-peer outcomes, handler completion and endpoint result. Include a negative case that must not be terminated.

Keep generic Hangup distinct from PJSIPHangup, which has an incoming-PJSIP final-response purpose and different cause input. Documentation does not establish signaling, compatibility, timing precision or user-visible result, and no live system was tested for this guide.

Do not infer AOC-E from the final Hangup event

The AMI AOCMessage diagnostic requires its own phase-specific event evidence.