VoIP.infoThe independent guide to business communications.
VoIP.info Diagnostic

Asterisk PJSIPHangup returns the wrong response or 200 was already sent

Find the first final SIP response, prove the current channel and application availability, then correct one policy or timing owner without rewriting evidence after answer.

Reviewed 2026-10-14Current Asterisk branch 23 PJSIPHangup and Hangup application documentation, hangup-cause inspection and mapping guidance, and RFC 3261 reviewed October 14, 2026; PJSIPHangup is documented since Asterisk 18.21.0, 20.6.0 and 21.1.0, accepts a numeric 400 through 699 response or supported PJSIP response name, must run on an incoming PJSIP channel before any other final response, terminates dialplan execution and maps the selected SIP response into an Asterisk or ISDN cause, while installed release, loaded channel driver, channel direction, prior provisional or final responses, transaction state, mapping, upstream rewriting and caller behavior remain deployment specific; no PBX, module, dialplan, channel, request, response, cause, packet, endpoint, trunk or call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one INVITE transaction and its first final response

Record the timestamp, Call-ID, branch, incoming PJSIP channel, dialplan context and extension, matched condition, requested cause, every provisional response and the first final response. Classify the symptom as unavailable application, invalid cause, wrong channel, unexpected final code, 200 already sent, upstream rewrite or caller behavior different from policy.

Do not begin by changing cause mappings or adding repeated hangups. RFC 3261 transaction evidence and the first final response define the response boundary for the INVITE.

Verify the installed maintenance release and active path

Confirm that the running release meets 18.21.0, 20.6.0 or 21.1.0 as applicable and that the loaded dialplan contains the expected application call. Follow the actual executed priorities rather than the source file alone.

On a managed FreePBX system, identify the generated or custom owner before editing. A successful reload is not proof that the call entered the expected context, and an application documented online is not proof that an older package exposes it.

Prove that execution is on the incoming PJSIP channel

Capture the channel technology, name, unique ID and linked ID at the application boundary. PJSIPHangup() is documented for the incoming PJSIP channel. If execution has moved to a Local channel, outbound callee or another bridge leg, the requested final response may not own the original INVITE transaction.

Correlate channel identifiers without treating the linked ID as permission to substitute one leg for another. Fix the dialplan placement rather than reaching across unrelated channels.

Locate the action that sent 200 or another final response first

Walk backward from the first final response to the responsible application or module. Check explicit Answer(), Playback() without noanswer, queue or conference admission, voicemail, media applications and any helper that answers implicitly. A later PJSIPHangup() cannot replace that final result.

If only 1xx responses preceded the call, keep them distinct from the final response. If an intermediary rewrote the final code, retain the Asterisk-side and caller-side messages as separate observations.

Compare requested response, wire code and translated cause

Confirm that the requested numeric value is in the documented 400 through 699 range or that the symbolic name is supported by the installed PJSIP definitions. Compare that input with Asterisk logs, the captured final response and per-channel tech and ast causes.

The published mapping is many-to-one. A translated busy, rejected, unavailable or interworking cause is not sufficient to reconstruct the exact response or the leg that produced it. Preserve every called-channel result when Dial() created multiple legs.

Correct one owner and repeat negative and allowed controls

Correct only the demonstrated issue: version, loaded path, channel ownership, condition, cause value, implicit answer, upstream rewrite or caller policy. Keep the previous dialplan and a rollback. Avoid globally replacing Hangup() or remapping every cause to make one trace look uniform.

Repeat the rejected scenario and a permitted-call control. Acceptance requires the intended first final response on the original transaction, expected translated cause where relevant, correct caller behavior and no unintended answer. No PBX, module, dialplan, channel, response, cause, packet, endpoint, trunk or call was inspected or tested for this diagnostic.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Hub

VoIP troubleshooting

Use symptoms and evidence to isolate registration, routing, media and device faults.

Explore topic →
Guide · Current Asterisk branch 23 PJSIPHangup and Hangup application documentation, hangup-cause inspection and mapping guidance, and RFC 3261 reviewed October 14, 2026; PJSIPHangup is documented since Asterisk 18.21.0, 20.6.0 and 21.1.0, accepts a numeric 400 through 699 response or supported PJSIP response name, must run on an incoming PJSIP channel before any other final response, terminates dialplan execution and maps the selected SIP response into an Asterisk or ISDN cause, while installed release, loaded channel driver, channel direction, prior provisional or final responses, transaction state, mapping, upstream rewriting and caller behavior remain deployment specific; no PBX, module, dialplan, channel, request, response, cause, packet, endpoint, trunk or call was inspected or tested

Asterisk PJSIPHangup: return one final SIP response safely

Place one explicit 4xx, 5xx or 6xx final response on the incoming PJSIP transaction before answer, then keep SIP, translated cause and caller outcome separate.

Read guide →
Guide · Current Asterisk branch-23-generated HANGUPCAUSE, HANGUPCAUSE_KEYS, HangupCauseClear, Dial and CHANNEL references plus the project mapping table reviewed October 6, 2026; exact behavior still depends on the installed Asterisk branch, channel driver, dialplan and call path

Asterisk hangup causes: preserve each called-channel result

Interpret Dial status, per-channel technology causes, translated Asterisk causes and hangup source without collapsing parallel or sequential call attempts into one reason.

Read guide →
Guide · Asterisk hangup-handler, CHANNEL, AMI event, hangup-cause and Return documentation reviewed October 12, 2026; exact events and channel behavior remain dependent on the installed Asterisk branch, modules, dialplan, channel technology and observer permissions, and no PBX, dialplan, channel, handler stack, event, record, endpoint, call or teardown path was inspected or tested

Asterisk hangup handlers: channel stack, order and teardown evidence

Attach bounded hangup subroutines to the correct channel, preserve LIFO stack order and prove push, pop, run and final hangup separately.

Read guide →
Hub

SIP response codes

Interpret a SIP status in the context of its method, transaction and the system that sent it.

Explore topic →
Guide · Asterisk 22 LTS

Asterisk dialplan: contexts, patterns and loaded-call evidence

Build a restricted Asterisk 22 call path, then prove its context, match, priorities and runtime behavior separately.

Read guide →
Guide · Current Asterisk logging, runtime command, logger.conf, debug-collection, call-identifier and console-verbosity documentation reviewed September 30, 2026; no process, logger, trace, storage path or call tested

Asterisk logging without permanent debug overload

Map configured destinations, console levels, call identifiers and a bounded protocol trace without leaving sensitive debug collection active.

Read guide →
Guide · Wireshark 4.x / current upstream tool documentation; inspect installed versions

VoIP packet-capture methodology

Select interfaces, time windows and paired capture points that distinguish network loss from missing evidence.

Read guide →