Asterisk AMI PJSIPHangup uses the wrong channel or response, or no final event appears

Freeze the intended leg and symptom before retrying

Record node, installed release, module inventory, manager identity, unique ActionID, exact channel name, Uniqueid, Linkedid, state, bridge membership, requested response and symptom time. Preserve the initial AMI response and all matching lifecycle events.

Classify the first divergence: action missing or denied; target absent; wrong leg selected; channel already answered; cause rejected; action accepted without expected events; expected events filtered; terminal cause differs; or the peer received another response.

Resolve release and authorization failures first

Verify that the installed maintenance branch includes PJSIPHangup—18.21.0, 20.6.0, 21.1.0 or later in their respective lines—and that the installed action inventory exposes it. Then confirm the manager account can issue the action and receive the required call-class events.

Do not substitute the generic Hangup action merely to silence an unknown-action error. Generic Hangup accepts a numeric channel cause; PJSIPHangup accepts a SIP response code or name for an incoming PJSIP channel before another final response.

Prove the exact channel is still the intended incoming leg

Refresh the channel snapshot immediately before the action and match both name and Uniqueid. A stale channel name, another fork, a Local channel, the opposite bridge leg or a later call sharing the same endpoint label can make a syntactically valid action target the wrong object.

Avoid a regular-expression target while investigating. Use Linkedid to collect related evidence, not as permission to terminate every related leg.

Check whether a final response already committed the outcome

Inspect the SIP and channel chronology. If the channel was answered or another final non-1xx response was sent, the requested rejection cannot retroactively replace it. A 200 followed by BYE is not the same result as rejecting the initial INVITE with a 4xx, 5xx or 6xx response.

Correct the first application or dialplan step that committed the response rather than repeatedly issuing PJSIPHangup later in the lifecycle.

Reconcile requested response, translated cause and event visibility

Preserve the exact requested code or name and compare it with the on-wire final response, terminal Cause, Cause-txt and any off-nominal TechCause. Cause mapping can collapse multiple SIP codes into one standard channel cause, so a differing numeric field is not automatically proof that the wrong SIP response was sent.

If HangupRequest, SoftHangupRequest, BridgeLeave or Hangup is absent, review read permissions, advanced event filters, connection continuity and observation start time. An accepted action response is not a substitute for a terminal event.

Correct one layer and verify one bounded outcome

Correct only the demonstrated layer: maintenance release, loaded capability, manager authorization, filter, exact channel selection, timing before final response, cause value or upstream signaling path. Re-run with one exact leg and a new action ID.

Require the intended SIP response at the peer and a terminal event for the same Uniqueid; keep media, routing and user experience as separate checks. No PBX, manager action, channel, bridge, SIP response, packet, endpoint, media stream or live call was inspected or tested.

Check whether a lifetime timer ended the selected PJSIP leg

The AbsoluteTimeout diagnostic correlates the exact Uniqueid, request events and final Hangup before changing response handling.

Confirm which hangup action owned the termination

The generic Hangup diagnostic separates exact-channel disposal from PJSIP response selection.