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 destinations604 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.
Require an authoritative global assertion
RFC 3261 defines 604 as a global failure from a server with authoritative information that the user in the Request-URI does not exist anywhere. It is stronger than 404, which says the addressed user or domain was not found by the recipient handling that domain, and it is different from 485, which says the Request-URI was ambiguous.
The code does not by itself prove that a public telephone number was never assigned, permanently disconnected, portable, or unavailable in every commercial network. Bind the claim to the exact URI, namespace and responder that asserted authority.
Preserve the request and the authority boundary
Record the method, Request-URI user and domain, URI parameters, Call-ID, CSeq, Via branch, response source and exact signaling leg. Keep those fields separate from display name, From, To, P-Asserted-Identity and the digits a person originally entered. Number normalization or domain rewriting can change the resource whose existence was evaluated.
A PBX, proxy, provider or back-to-back user agent may translate a downstream result. The final code shown to an endpoint does not establish which directory was consulted or whether its knowledge is authoritative for the original address.
Account for 6xx branch handling
For a stateful proxy, RFC 3261 says that a received 6xx response stops new branches and triggers cancellation of pending client transactions before the global failure is forwarded. Preserve the decisive 604 alongside the resulting CANCEL and 487 branch outcomes. Do not treat each cancelled branch as an independent proof that the user is absent.
For a B2BUA or application that creates separate calls, correlate channels and route decisions rather than assuming transparent proxy behavior. An alternate carrier, voicemail destination or local failover is a separate policy question, not a reason to discard the original 604 evidence.
Do not reconstruct 604 from cause 1
Asterisk maps SIP 404, 485 and 604 to AST_CAUSE_UNALLOCATED, Q.850 cause 1. The translation is useful for cross-technology handling but loses the original code, responder and scope. A cause-1 CDR, announcement or application result therefore cannot prove that a PJSIP leg received 604.
Retain the wire response and per-channel technology cause. For Asterisk PJSIP, the focused 604 investigation separates a bad local URI, a remote authoritative result and a coarser translated cause.
Correct one namespace owner and test negatives
If the request was rewritten incorrectly, repair only the demonstrated normalization, domain or route rule. If an authoritative directory contains an erroneous record, use its supported lifecycle and preserve rollback. Do not create a permissive catch-all, probe unrelated identities or route around an authorization boundary merely to suppress 604.
Retest the intended address, a nearby valid address, a deliberately nonexistent address and an unauthorized target. Confirm both the responding system and the exact Request-URI. A later successful setup still requires separate answer, media and release checks.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: 604 Does Not Exist Anywhere and 6xx handling ↗
- Asterisk hangup-cause mappings ↗
- Asterisk hangup-cause inspection ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.