Locate the response family
- 1xx ProvisionalRequest is progressing
- 2xx SuccessRequest succeeded
- 3xx RedirectionAnother destination
- 4xx Request failureInterpret this request
- 5xx Server failureServer could not fulfil
- 6xx Global failureFailure across destinations600 belongs here
Read the status with its request method and call leg. For example, 200 after REGISTER confirms a binding; it does not prove an INVITE succeeded.
Read 600 as a global busy result
RFC 3261 defines 600 as a global failure: the callee's end system was contacted, the callee is busy and does not wish to take the call, and the responder knows that no other endpoint will answer. That last condition separates 600 from 486 Busy Here, which leaves open the possibility of another contact or voicemail answering.
The response may carry Retry-After, but the header is optional. Preserve it when present and do not invent a retry time when it is absent. A 603 Decline hides the specific busy reason and remains a distinct result.
Bind the result to one request and responder
Record the request method, Request-URI, Call-ID, CSeq, tags, Via branch, response source and exact call leg. A PBX, proxy, endpoint, SBC or provider can be the system asserting global knowledge, and a back-to-back user agent may translate the response before sending a result on another leg.
On a stateful proxy, RFC 3261 says a received 6xx response stops new branches and causes pending client transactions to be cancelled before the 6xx is forwarded. Preserve those CANCEL and 487 branch outcomes without mislabelling them as separate user refusals.
Do not reconstruct 600 from a busy label
Asterisk maps both SIP 486 and 600 to AST_CAUSE_USER_BUSY, Q.850 cause 17. Its Dial() application can therefore report DIALSTATUS=BUSY for a called party that indicated busy, but neither the translated cause nor the application result retains whether the wire response was 486 or 600.
Keep the original SIP message and responder beside the per-channel hangup cause. A busy announcement, CDR disposition or dashboard label is supporting evidence, not proof that the network received 600.
Verify policy without defeating it
For an owned destination, compare current calls, call waiting, do-not-disturb, simultaneous-call limits, forking, voicemail and overflow policy with the captured transaction. For an upstream response, ask the provider or policy owner to trace the same identifier and timestamp.
Correct only a demonstrated policy error. Do not increase concurrency, disable do-not-disturb, bypass a recipient's refusal or add uncontrolled retries merely to remove the visible code. Verify an intended busy path, one permitted call and the expected voicemail or overflow behavior after any approved change. For Asterisk PJSIP, use the focused 600 investigation.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: global failures and 600 Busy Everywhere ↗
- Asterisk hangup-cause mappings ↗
- Asterisk Dial application and DIALSTATUS ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.