SIP 480 Temporarily Unavailable in VoLTE — Callee Reachability Diagnosis

SIP 480 (“Temporarily Unavailable”) is returned in VoLTE when the S-CSCF or P-CSCF cannot deliver a SIP INVITE to the called party’s UE. Unlike SIP 503 which reflects server-side overload, SIP 480 is callee-side unavailability: the called UE is not reachable, not IMS-registered, or is in a state where it cannot accept calls.

In VoLTE field diagnostics, SIP 480 is one of the most frequent call setup failure codes. It arises from a gap between LTE radio connectivity and IMS registration state — a UE that appears connected at the RF level may still be unreachable at the SIP level.

Technical Reference

Root Cause 1: Callee IMS Registration Expired or Failed

The most common cause of SIP 480 in VoLTE. The called UE has:

• Completed LTE attach (EMM-REGISTERED) and established the IMS APN bearer (QCI 5)
• Sent a SIP REGISTER that succeeded (200 OK) at some point in the past
• Failed to refresh the registration before the registration expiry timer elapsed

The S-CSCF’s binding database contains an expired or absent entry for the called UE’s public user identity (IMPU). When an INVITE arrives for that IMPU, the S-CSCF returns 480 to the originating S-CSCF/P-CSCF.

The IMS registration timer (Expires header in the REGISTER response) is typically 3600 seconds in most operator deployments. A UE that loses its IMS APN bearer, moves between radio conditions, or reboots may fail to re-register in time.

Root Cause 2: Called UE Not IMS-Registered

The callee’s UE is connected to LTE but has never completed IMS registration in the current PLMN, or IMS registration was rejected. This occurs when:

• The IMS APN bearer (QCI 5) was not established (PCRF rejection, PGW failure)
• The SIP REGISTER transaction received a 403 (Forbidden) or 401 (Unauthorized) rejection
• The device does not support VoLTE (UE does not include +g.3gpp.ims.headercompression or +g.3gpp.srvcc-alerting in Contact header)

In all cases, the S-CSCF returns 480 because no REGISTER binding exists for the IMPU.

Root Cause 3: P-CSCF Cannot Reach the Callee’s UE

Even when IMS registration exists and is current, the P-CSCF may be unable to forward the INVITE to the UE because the IMS APN bearer (QCI 5) was lost after the REGISTER (for example, due to an idle mode bearer suspension or a handover failure). The REGISTER binding in the S-CSCF is still active, but the P-CSCF’s path to the UE’s contact address is broken. In this case, the P-CSCF of the called party generates the 480.

Root Cause 4: Do Not Disturb (DND) or IM-SSF Rejection

In operator deployments that implement IMS application servers for supplementary services (DND, barring), the IM-SSF (IP Multimedia — Service Switching Function) or a dedicated AS may return 480 when call barring or Do Not Disturb is active for the called subscriber. The Via header stack will show the AS address as the 480 source.

Step-by-Step Field Diagnosis

Step 1 — Identify the 480 source via the Via header. In the decoded 480 response, read the Via header stack. The topmost Via entry identifies the node that generated the 480. A Via entry from the called party’s S-CSCF address confirms the S-CSCF could not find a REGISTER binding. A Via entry from the called party’s P-CSCF confirms the forwarding path to the UE is broken.

Step 2 — Check the callee’s IMS registration status. On the operator side, query the S-CSCF’s REGISTER binding table for the called IMPU. If no binding exists or the binding has expired, the 480 is due to IMS deregistration. Correlate with the called device’s IMS log: a REGISTER transaction ending in failure or a missing REGISTER entirely confirms deregistration.

Step 3 — Verify the callee’s IMS APN bearer. In the callee’s NAS/EPS bearer log, confirm a QCI 5 dedicated EPS bearer is active. If the QCI 5 bearer was released or failed after the REGISTER (visible as an EPS Bearer Deactivation event), the callee’s P-CSCF cannot reach the UE even though the S-CSCF binding may still be valid for a short period.

Step 4 — Distinguish from SIP 503. If the 480 is returned very quickly (within milliseconds) and the Via stack contains only one entry (the called P-CSCF or S-CSCF), this is a lookup failure — not a signaling transport issue. A 503 from the same address would indicate server overload. The error code itself (480 vs 503) in the decoded SIP message is the definitive indicator.

Step 5 — Test callee re-registration. On the callee device, force a SIP re-REGISTER (by toggling airplane mode, cycling IMS APN, or using a DIAG command to reset the IMS stack). A successful 200 OK to the REGISTER followed by a successful INVITE confirms the 480 was due to a stale or missing registration.

SIP 480 in IMS Re-INVITE Flows

SIP 480 can also appear during mid-call procedures, not only during call setup. If the called UE loses its IMS registration during an active VoLTE call (for example, due to an inter-PLMN handover or IMS APN bearer loss), a subsequent re-INVITE or UPDATE from the originating UE targeting the callee may receive a 480. This triggers call release by the originating side.

Capturing SIP 480 in the Field

IMS OTA signaling is captured via DIAG log. The decoded SIP transaction shows the full INVITE request and 480 response including the Via header stack, Contact headers from the REGISTER, and Reason headers if present. On the calling side, the 480 appears in the SIP INVITE transaction as a non-2xx final response, visible in the IMS call log as a call setup failure with SIP error 480.

Related SIP Codes

• SIP 503 — Service Unavailable (server-side overload, not callee-side unavailability)
• SIP 486 — Busy Here (callee is registered but actively engaged in another call)
• SIP 487 — Request Terminated (INVITE cancelled by the caller before a final response)
• SIP 604 — Does Not Exist Anywhere (callee’s identity does not exist in the IMS network — permanent, not temporary)
• SIP 403 — Forbidden (authorization failure, registration rejected — callee cannot register)