SIP 480 Temporarily Unavailable

What 480 actually means

RFC 3261 describes 480 as: the callee's end system was contacted successfully, but the callee is currently unavailable — not logged in, logged in but in a state that precludes taking the call, or with do-not-disturb active. The response MAY carry a Retry-After header suggesting a better time to call, and the user may well be reachable somewhere this particular server does not know about. Nothing about it is definitive; it is the politest failure in the 4xx class.

There is a second, entirely separate producer of the same code. RFC 3261 §16.5 tells a proxy whose target set comes up empty — the location service holds no binding for the address of record — to return an error, and recommends 480 for the job. So the same three digits cover "the phone rang and nobody picked up" and "there is no phone to ring". The trace distinguishes them by timing, as below.

One more thing the RFC says explicitly: the reason phrase SHOULD be settable by the UA. "Temporarily Unavailable", "Temporarily not available", "No Answer" and "Subscriber absent" are all the same status. Match on the code, never the phrase.

What actually causes it

The registration is gone

The most common cause on the enterprise side. The registrar was asked for bindings and had none: the registration expired and the phone has not refreshed yet; the phone dutifully re-registers to node A of a cluster while inbound calls land on node B, which does not share the registration store; or the account on the phone differs subtly from the AOR being called — extension number against user name — so the binding exists but under a different key. Note that "the phone says Registered" is a statement about the phone's memory of its last successful REGISTER, not about what the registrar holds now. Trust the registrar's table, at the timestamp of the failing call.

Nobody answered

The call was delivered, it rang, and a timer ran out. A PBX whose dial step has no voicemail or failover destination has to tell the caller something when the ring timer expires, and 480 is the conventional choice — Asterisk-family systems answer this way for both "no registered contact" and "rang until the dial timer lapsed", which is exactly why the same code confuses people. The tell is unambiguous: a 180 Ringing first, then a 480 arriving a suspiciously round number of seconds later, matching somebody's configured ring time.

Do-not-disturb

Many desk phones answer an incoming INVITE with 480 while DND is active; others send 486, and server-side DND features vary again. A 480 that comes straight back from the far UA within milliseconds, on an account whose registration is provably healthy, is DND until shown otherwise.

A binding into a dead NAT pinhole

The registrar has a Contact, but it points at a NAT mapping that expired after the last keepalive. The proxied INVITE disappears into it and nothing comes back; when the transaction times out, some systems relay a 408 and plenty of B2BUAs report 480 instead. The shape to recognise is a slow 480 — tens of seconds — with no ringing at all. The mechanics of the silent leg are the 408 page's territory.

When it arrives from the PSTN

Off a gateway, 480 is usually a translated ISUP release. RFC 3398 maps Q.850 cause 19 (no answer from the user), cause 20 (subscriber absent — the mobile is switched off, out of coverage, or detached from the network) and cause 31 (normal, unspecified) all to 480. Cause 18 (no user responding) maps to 408 on paper, but in the field plenty of gateways emit 480 for the whole ring-no-answer family, so do not lean on the 408/480 distinction to tell 18 from 19. In the reverse direction, a gateway handed a 480 from the SIP side releases the ISUP call with cause 18.

A well-behaved gateway attaches the original cause as a Reason header (RFC 3326): Reason: Q.850;cause=19. When it is present, believe it over the status code — the cause value is the more specific of the two. The full table in both directions is on the Q.850 cause code page.

480 vs 486 vs 404 vs 603

Four codes that all read as "call failed, user's fault" and mean four different things:

• 486 Busy Here — the call reached a device and the device is busy, at that device. Forking may still find the user elsewhere; 600 Busy Everywhere is the version that says stop looking.
• 404 Not Found — the user does not exist at this domain at all. Retrying later changes nothing; check the Request-URI for a digit-manipulation mistake before believing it.
• 603 Decline — a definitive refusal on behalf of the user everywhere. A 6xx ends the search; typically a human pressed reject, or policy did it for them.
• 480 — the weakest claim of the four: not reachable right now, try again later, possibly with a Retry-After hint.

What to check in the trace

1. Did a 180 Ringing (or a 183 carrying ringback) precede the 480? Ringing first means the user side — no answer, DND-after-alert, or reject. No ringing means the registration or routing side.
2. Clock the gap from INVITE to 480. Milliseconds is a local location-service miss or DND. Fifteen, twenty or thirty seconds is somebody's ring timer. Thirty-two seconds is a transaction timeout being translated — see the 408 page.
3. Establish which element generated it. Did the INVITE leave the egress side of your SBC or proxy at all? A 480 on the ingress leg with no matching egress INVITE was minted locally, and your registrar — not the far end — is the story.
4. Read the Reason header if there is one. Q.850 cause 19 versus 20 is the difference between "rang, no answer" and "handset off or out of coverage".
5. Ask the registrar what it held at that moment: which bindings, with what expiry, on which node. Compare against the phone's re-REGISTER cadence in the same capture — a binding that expires sixty seconds before each refresh is the whole answer.
6. Check that the Request-URI actually matches the AOR the device registers. User-versus-extension mismatches produce empty target sets that masquerade as flaky registration.