Troubleshooting · SIP Codes
SIP 480 Temporarily Unavailable
480 is SIP's shrug: the callee's system was reached (or their registration is on file) but the user cannot take this call right now, and the response declines to say precisely why. It is generated by platforms on behalf of endpoints that are registered-but-unreachable, on Do Not Disturb, or whose contact has gone stale — the gray zone between 'busy' (486, the endpoint actively said so) and 'nobody home' (408, silence).
Most 480 tickets are really registration or presence tickets wearing a code's clothing. Diagnose the endpoint's state, not the caller's.
What typically produces a 480
- Do Not Disturb at the endpoint or platform: many systems translate DND into 480 toward callers (others use 486 — vendor choice), routing the caller to the unavailable treatment, usually voicemail.
- Registered but unreachable: the binding exists, the INVITE is sent, the endpoint doesn't respond (off, unplugged, NAT mapping dead), and the platform converts its internal timeout into a 480 for the caller rather than a raw 408.
- Stale registration after a move: the server holds the phone's previous address (home ↔ office moves, IP changes) and faithfully rings a ghost.
- Simultaneous-registration limits: the same extension registered from a new device while the platform allows one contact — calls offer to a device the user isn't watching.
- Calibrated unavailability: some PBXs answer 480 during maintenance windows or when a user's presence is set to an explicit unavailable state in a UC client.
480 vs 486 vs 408 — the triage value
Teach your help desk this trio and half of 'calls go to voicemail' tickets self-classify: 486 — the endpoint itself answered and said busy: a live device, a live user state. 480 — the platform answered for the endpoint: the device didn't participate; think registration, reachability, platform-level DND. 408 — nobody answered anybody; think transport and paths. 480 therefore sends you to the admin portal's registration page before you touch the physical phone — the opposite order from a 486.
Fix sequence
- Check the endpoint's DND/presence state in the platform (not just the phone — UC clients and portals hold their own state that syncs imperfectly).
- Inspect the registration: is it current, from the expected IP/device, with a sane expiry? Re-register the phone (reboot or manual re-register) and compare the contact address to reality.
- Place a test call while watching the platform trace: does an INVITE leave toward the registered contact, and does anything return? INVITE into a void + fresh-looking registration = stale binding or dead path.
- If the user has multiple devices/apps on one extension, test with all but one signed out — find which registration is absorbing the calls.
- Align the timers: registration expiry comfortably above your NAT's UDP timeout, with keepalive enabled, so 'registered but unreachable' stops regenerating after every quiet period.
- Retest inbound from an external number (not just internal) — external calls exercise the platform path that produces 480s.
Frequently asked questions
- Callers get 480 but the user insists DND is off.
- Believe both: the platform's record of the user's state and the phone's local DND are different databases that usually sync — and occasionally don't (app vs desk phone, portal setting vs device key). The platform trace shows which state the routing decision used.
- Why does 480 appear after the phone is unplugged for the weekend?
- Because the registration lingers until expiry. The platform offers calls to the binding, gets silence, and eventually answers 480. Shorter expiries and graceful de-registration (phones that unregister on shutdown) reduce the window.
- Is 480 ever the far carrier's doing?
- On outbound calls, yes — the far network can return 480 for its own unreachable subscribers. The sender's identity in the trace tells you whether to fix your house or report theirs.