Prove which system declined which request
Capture one authorized failed attempt and identify the request method, Call-ID, CSeq, From and To tags, PJSIP channel and the address that sent 603. A final response received by Asterisk from a phone, SBC or provider has a different owner from a response Asterisk generated on its inbound leg. Preserve both SIP legs when Asterisk is between systems.
RFC 3261 defines 603 as a global failure: the called party was successfully contacted but does not want or cannot participate. The response does not by itself prove spam classification, invalid credentials, do-not-disturb or a particular application button. Treat those as hypotheses owned by the responding system.
Keep 603 distinct from busy and authorization results
A 486 response reports that the specific endpoint is busy, while 603 carries broader decline semantics. Asterisk's hangup mapping is intentionally coarser: 603, 401, 403 and 407 all map to AST_CAUSE_CALL_REJECTED and Q.850 cause 21. A cause-21 report therefore cannot reconstruct the original SIP response or its policy owner.
Read the technology-specific HANGUPCAUSE value for the exact outbound channel together with its translated Asterisk cause. Record DIALSTATUS as an application result, not as a replacement for the wire response. Parallel or sequential dial attempts require per-channel evidence so one rejection is not assigned to every branch.
Trace the refusing policy without bypassing it
On an owned endpoint, compare the timestamp with user decline, do-not-disturb, screening, simultaneous-call, privacy and call-permission state. On an SBC or provider, request the decision and trace identifier for the same transaction. On Asterisk, follow the loaded inbound context, route and application sequence that handled the request.
Do not evade an intentional refusal by rotating caller identity, forcing uncontrolled retries or adding alternate destinations without authorization. If the response includes Retry-After, preserve it as response evidence; do not invent a retry interval when it is absent. Keep authentication failures and registration state in their own investigations.
Treat an intentional local 603 as version-sensitive dialplan behavior
Current Asterisk documentation provides PJSIPHangup() to return a selected 400–699 final response on an incoming PJSIP channel. The application is documented from Asterisk 18.21.0, 20.6.0 and 21.1.0, and it must run before any other final response such as a 200 from Answer() or an answering Playback(). Confirm the installed branch and loaded application before attributing a local 603 to it.
On FreePBX, inspect the generated route but make durable changes only through supported GUI controls or documented extension points. Do not edit generated dialplan merely to change the visible SIP code. Asterisk is a back-to-back user agent, so a received response and the final response sent on another leg need not remain identical.
Verify the intended outcome and adjacent routes
Correct one demonstrated policy or dialplan boundary, then repeat an authorized test with the same identities and direction. Confirm that an intended refusal still returns the documented treatment, or that an unintended refusal now reaches the approved destination. Also verify one permitted call and the planned busy, voicemail or overflow path so the repair does not turn a deliberate global decline into a routing loop.
Remove temporary PJSIP logging, protect unredacted traces and retain the smallest evidence set needed for escalation. No PBX, endpoint, provider, identity, screening rule, dialplan branch, retry policy, failover path 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: 603 Decline and global failures ↗
- Asterisk hangup-cause mappings ↗
- Asterisk PJSIPHangup application ↗
- Asterisk HANGUPCAUSE architecture and use ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk debug-information collection ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.