Asterisk hangup handler is missing, duplicated, out of order or slow

Freeze one channel and classify the first symptom

Record one authorized occurrence with timestamp and timezone, Asterisk branch, channel name, uniqueid, linkedid, hangup initiator, expected handler target and expected durable effect. Classify the first symptom: no stored handler, no run event, duplicate run, wrong order, missing return, slow teardown, wrong cause or a downstream record that never committed.

Preserve the dialplan and event interval before reloading, pushing another handler or wiping the stack. A missing external record is not proof that Asterisk skipped the handler, and a final Hangup event is not proof that every handler returned.

Prove which channel received each stack operation

Find the exact CHANNEL(hangup_handler_push), pop or wipe operation and correlate it to the current channel at that priority. Record the fully resolved target and arguments. If the call contains caller, callee, Local-channel, queue or transfer legs, inventory each separately.

Do not infer stack inheritance from linkedid, bridge membership or a shared business call. If cleanup belongs to an outbound leg, prove the operation executed on that leg rather than copying the handler to every channel.

Reconstruct last-in, first-out order before changing it

Use the handler-stack CLI output and AMI push or pop events to reconstruct the stack just before hangup. The most recently pushed target should run first. Mark every conditional push, replacement pop and full wipe; a later branch may have changed the stack after the initial log line.

When one effect appears twice, distinguish two stored copies, two channel owners, a handler plus h-extension implementation, an external retry and duplicate downstream consumption. Do not remove one execution path until its owner is established.

Follow each run event to an explicit Return

Correlate HangupHandlerRun with the handler string, channel identifiers and the first loaded priority. Trace all branches to Return() and record exceptions, blocking applications, invalid targets and fall-through. A run event means Asterisk is about to invoke the handler; it is not a completion receipt.

Do not push another handler from the running handler or the h extension. Asterisk documents that behavior as undefined. Keep handler and h-extension side effects independent because their relative execution order is also undefined.

Measure teardown duration and separate remote delivery

Measure from the first handler run through each return and the final hangup event. Identify DNS, HTTP, database, file, lock or command delays. Keep the hangup path bounded; move nonessential remote work out of teardown and give the asynchronous handoff its own queue and acknowledgement evidence.

A fast return does not prove remote persistence, while a slow SIP dialog close does not by itself prove the handler caused the delay. Correlate channel and protocol timing before assigning cause.

Correct the first divergence and retest records and cause

Correct only the demonstrated boundary: wrong channel owner, absent push, unintended pop or wipe, duplicate owner, invalid target, missing return, blocking work or downstream idempotency. Preserve the original hangup cause rather than replacing it merely to make a report look consistent.

Retest representative answer, rejection, timeout, cancellation and transfer paths in scope. Confirm the intended LIFO order, bounded execution, one durable effect, final Hangup event, per-channel cause and expected CDR or CEL result. This workflow is documentation-derived and was not reproduced on an installed or laboratory Asterisk system.

Distinguish asynchronous periodic work from hangup-stack work

Use the periodic-hook diagnostic when recurring audio or an async hook channel is mistaken for a duplicated or late hangup handler.