Prove where 600 entered the call
Capture one authorized failed attempt with pjsip set logger on for the shortest useful window. Identify the INVITE Request-URI, Call-ID, CSeq, tags, Via branch, PJSIP channel and source address of the 600 response. If Asterisk is between an endpoint and a provider, correlate both legs without assuming the same Call-ID or final code crosses the back-to-back user-agent boundary.
RFC 3261 reserves 600 for a callee that is busy and does not wish to take the call when the responder knows that no other endpoint will answer. That is stronger than observing one occupied phone. Record who had enough routing knowledge to make that assertion before changing endpoint or trunk configuration.
Preserve fork scope and cancellation evidence
A stateful proxy that receives a 6xx response stops creating new branches and should cancel pending client transactions. Those branches commonly complete with 487 after CANCEL. Keep the 600, each CANCEL and each branch's final response in one timeline; do not count the resulting 487 responses as independent destination failures.
Asterisk dialplan can also fan out or sequence channels without acting as a transparent proxy. Use channel names and linked call identifiers to show which endpoint, trunk or application branch ended first. Then inspect whether voicemail, queue, ring-group or overflow logic was still eligible under the loaded route.
Keep the wire response ahead of translated busy state
Asterisk's documented mapping converts both SIP 486 and 600 to AST_CAUSE_USER_BUSY, Q.850 cause 17. Dial() may report DIALSTATUS=BUSY, but that application result also does not identify which SIP busy code was received. A cause-17 CDR, AMI event or dashboard label therefore cannot reconstruct global 600 semantics.
Use HANGUPCAUSE_KEYS() and the technology-specific and Asterisk cause values for each called channel after Dial(), while retaining the original SIP response. Parallel and sequential attempts need per-channel evidence; the calling channel's final value can hide the branch and responder that supplied the decisive result.
Trace the busy policy without broadening access
For an owned PJSIP endpoint, compare current channels, device state, call waiting, do-not-disturb and simultaneous-call policy at the captured time. The device_state_busy_at endpoint option changes when Asterisk reports its own device state as busy; it does not prove why a remote system sent 600. For a provider or SBC response, use the same transaction identifier and timestamp in the escalation.
Preserve any Retry-After value, but do not create an aggressive retry loop when it is absent. Do not raise channel limits, disable recipient policy, rotate caller identity or force an alternate route until evidence shows an unintended configuration and the policy owner authorizes the change.
Treat a local 600 as explicit, version-sensitive behavior
Current Asterisk documentation provides PJSIPHangup() to send a selected 400–699 final response on an incoming PJSIP channel. It must run before another final response is sent, and its documented availability begins with maintenance releases in the Asterisk 18, 20 and 21 families. Confirm the installed branch and loaded application before attributing a locally generated 600 to this path.
In FreePBX, inspect the generated route and supported custom extension points, but make durable changes through supported controls. Do not edit generated dialplan solely to substitute 486 for 600; first decide whether other contacts, voicemail or overflow should actually remain eligible.
Verify busy, answer and fallback outcomes
After correcting one demonstrated policy or routing boundary, repeat the same authorized attempt. Confirm the expected final response on every leg and verify one permitted call, one intentional busy case and the approved voicemail or overflow path. A successful registration or a changed announcement is not sufficient.
Disable temporary PJSIP logging, redact credentials and personal identifiers in shared traces, and retain only the evidence needed for review. No PBX, endpoint, provider, proxy, policy, fork, dialplan, voicemail path, concurrency limit or live call was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: 600 Busy Everywhere and 6xx proxy handling ↗
- Asterisk hangup-cause mappings ↗
- Asterisk Dial application and DIALSTATUS ↗
- Asterisk PJSIPHangup application ↗
- Asterisk HANGUPCAUSE architecture and use ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk res_pjsip endpoint configuration ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.