Identify the responder, method and SIP leg
Capture one bounded failure and record the request method, Call-ID, CSeq, request URI, response direction and responding address. RFC 3261 defines 480 for a callee that is currently unavailable or for a proxy or redirect server that recognizes the user but has no current forwarding location. The code does not by itself identify the endpoint, registration, policy or system that made that decision.
Determine whether Asterisk received 480 from a phone, SBC or provider, or sent it toward the caller after a local call attempt. Preserve both SIP legs when Asterisk originates a new INVITE. Do not convert a user-facing unavailable announcement, CDR disposition or downstream 480 into an end-to-end root-cause statement.
Preserve the response before Asterisk coarsens it
Asterisk maps SIP 480 and 483 to the same AST_CAUSE_NO_ANSWER value in its hangup-cause table. That mapping is deliberately coarser than the wire response: a stored cause 19 cannot prove whether the peer sent 480, a request exhausted Max-Forwards with 483, or another branch produced the final dial result.
Use per-channel hangup-cause inspection to retain the technology-specific value alongside the Asterisk cause, then correlate it with DIALSTATUS, timestamp, unique ID and linked ID. The Dial application can expose CHANUNAVAIL, NOANSWER or another aggregate result depending on the channel and attempt; preserve each outbound channel before interpreting the aggregate.
If a local PJSIP endpoint is unavailable
Inspect the loaded endpoint, its AORs, every current contact and qualification state. Asterisk documents that an endpoint needs an associated AOR and the AOR needs address information before it can be dialed. An empty contact set can follow expiry, deliberate unregister, failed provisioning, a wrong AOR reference or contact-removal policy; registration history and current state are not interchangeable.
Compare the contact URI, expiry, transport and observation time with the exact failed call. Do not increase expiration, disable qualification or add a static contact until the intended ownership model is known. A contact that is present or reachable by OPTIONS still does not prove that its INVITE policy, alerting or media will succeed.
If a phone, proxy or provider returned 480
Follow the response to the system that emitted it. RFC 3261 examples include a user not logged in, a state that precludes communication, do-not-disturb and a recognized address with no valid forwarding location. The optional Reason-Phrase or Retry-After can add evidence, but neither is guaranteed and neither replaces the responder's logs or account state.
For a phone, check the exact contact, registration, do-not-disturb and local call policy. For a provider or proxy, ask for the same Call-ID, called identity and timestamp, then check registration or location bindings, number routing and account policy. Do not rotate credentials, change codecs or declare a service outage solely because 480 appeared.
Verify dialplan treatment and alternate destinations
Inspect the branch after Dial() and how the system treats an unavailable result. Voicemail, another registered contact, a queue, an alternate trunk or a final announcement may be intentional, but each creates a different call leg and failure domain. Confirm which branch actually ran instead of adding a catch-all route that can weaken destination controls.
In a FreePBX-managed system, use supported route, extension, follow-me and voicemail configuration rather than editing generated dialplan. Keep provider failover separate from user-location handling: a second carrier cannot make an unregistered internal endpoint available, while forwarding to a public number can create a new billed and emergency-identity context.
Prove the narrow correction and expected unavailable case
After correcting the demonstrated layer, repeat the failed destination and one nearby control call. Confirm the selected contact or next hop, final SIP response, Dial result and intended voicemail or overflow behavior. Also test an intentionally unavailable user so the repair does not turn absence into uncontrolled forwarding or endless retries.
Remove temporary protocol logging and redact credentials, addresses and personal calling data from retained evidence. No PBX, endpoint, provider, registration, location service, do-not-disturb state, route, voicemail, failover, capacity, availability or live-call behavior was tested for this guide.
pjsip show endpoint <endpoint>
pjsip show aor <aor>
pjsip show contacts
core show channels conciseSources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: SIP 480 Temporarily Unavailable ↗
- Asterisk SIP and PJSIP hangup-cause mappings ↗
- Asterisk per-channel hangup-cause inspection ↗
- Asterisk Dial application results ↗
- Asterisk 22 res_pjsip endpoint and AOR configuration ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk bounded debug-information collection ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.