SIP 403 Forbidden in VoLTE and IMS โ Authentication and Authorization Diagnosis
SIP 403 in VoLTE means the IMS server rejected the request due to an authorization failure. Diagnosing REGISTER rejection, IMPI/IMPU mismatch, ISIM provisioning errors, and operator barring per RFC 3261 and 3GPP TS 33.203.
SIP 403 (โForbiddenโ) in VoLTE and IMS signals an authorization failure: the IMS network has received and understood the request but refuses to fulfill it. In the IMS REGISTER flow, a 403 is a final rejection of the UEโs identity or authorization โ it is not a challenge (that is SIP 401) but a definitive refusal that prevents IMS registration until the underlying authorization issue is resolved.
SIP 403 in IMS differs fundamentally from 4xx errors related to content negotiation (488) or temporary unavailability (480). It indicates a subscription-level or authentication-level problem that cannot be corrected by retrying the same REGISTER.
Technical Reference
| Field | Value |
|---|---|
| SIP response code | 403 |
| Full name | Forbidden |
| Standard | RFC 3261 ยง21.4.6, IETF |
| 3GPP IMS context | 3GPP TS 33.203 ยง6.1, IMS authentication; TS 29.228 Cx interface |
| Response source | S-CSCF (authorization check), P-CSCF (SA failure) |
| Applicable requests | REGISTER, INVITE, SUBSCRIBE |
| Retry behavior | None expected โ subscription change required |
The IMS Registration and Authentication Flow
Understanding SIP 403 requires understanding the normal IMS REGISTER flow:
- UE sends SIP REGISTER to P-CSCF with IMPI in the Authorization header (no credentials yet)
- P-CSCF forwards REGISTER to I-CSCF, which queries the HSS for the serving S-CSCF
- S-CSCF queries the HSS (Cx: MAR โ Multimedia Auth Request) for the authentication vector
- HSS returns the IMS AKA authentication vector (RAND, AUTN, IK, CK, XRES)
- S-CSCF returns SIP 401 with the WWW-Authenticate challenge (RAND, AUTN)
- UE computes its response using the ISIM/USIM K key and sends a second SIP REGISTER with the computed RES
- S-CSCF verifies RES against XRES and, if correct, returns SIP 200 OK โ IMS registration complete
SIP 403 replaces step 5 (or occurs after step 6) when the S-CSCF or HSS determines the UE is not authorized:
- Before the 401 challenge: the HSS returns an error to the S-CSCF because the IMPI has no IMS subscription, or the IMPI-to-IMPU binding is invalid
- After the REGISTER with credentials: the RES does not match XRES (authentication failure) or the HSS has marked the subscription as barred
Root Cause 1: IMPI Not Found or Not Authorized in the HSS
The IMPI (IMS Private Identity, formatted as imsi-<IMSI>@ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org) is the primary key used by the S-CSCF to query the HSS. If the HSS does not recognize the IMPI โ because the IMS subscription was not provisioned for this IMSI, or because the IMPI format does not match the HSS configuration โ the HSS returns an error and the S-CSCF generates a 403 Forbidden.
Most common scenario: a USIM provisioned for LTE (EPS subscription) without an IMS subscription (no IMPI/IMPU provisioned in the HSS IMS database). The EPS attach succeeds but every SIP REGISTER receives 403.
Root Cause 2: IMPU Barred or Subscription Suspended
The IMPU (IMS Public User Identity, formatted as sip:+<MSISDN>@ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org or as a tel URI) is the registered calling identity. If the IMS subscription is suspended (non-payment, administrative barring, number porting in progress), the HSS marks the IMPU as barred. The S-CSCF returns 403 in response to any REGISTER for a barred IMPU.
Root Cause 3: P-CSCF Security Association Failure
The P-CSCF establishes an IPsec Security Association (SA) with the UE during IMS registration (per TS 33.203). If the SA parameters (SPI, port numbers, encryption algorithm) negotiated in the initial REGISTER do not match those configured at the P-CSCF, or if the UE sends an integrity-protected REGISTER with an incorrect MAC, the P-CSCF may return 403 without forwarding the request to the S-CSCF. This is a transport-security failure at the P-CSCF level.
Root Cause 4: REGISTER Sent Outside Authorized P-CSCF Address
Operators configure the allowed P-CSCF addresses in the IMS APN. If the UE resolves a P-CSCF address that is not listed in the operatorโs IMS topology (for example, due to DNS misconfiguration returning an incorrect address), the REGISTER may reach an unauthorized proxy that returns 403, or the correct P-CSCF may return 403 because the REGISTER arrived via a path that violates the operatorโs topology.
Step-by-Step Field Diagnosis
Step 1 โ Confirm cause 403 in the IMS log. In the decoded IMS OTA log, locate the SIP REGISTER transaction and identify the final response code as 403. Verify the Reason header (if present) for an operator-specific error reason string. Distinguish from 401: a 401 contains a WWW-Authenticate header with RAND and AUTN values; a 403 does not.
Step 2 โ Check whether the IMS subscription is provisioned. On the operator side, confirm the IMSIโs IMS subscription in the HSS: IMPI present, IMPU registered, IMPU-to-IMPI association valid, and subscription status is active (not barred or suspended). A missing or inactive IMS subscription is the most common root cause.
Step 3 โ Verify the IMPI format in the REGISTER. In the decoded REGISTER (first REGISTER, before the 401 challenge), read the Authorization headerโs username field. It must match the IMPI format configured in the HSS exactly: imsi-<15-digit-IMSI>@ims.mnc<3-digit-MNC>.mcc<3-digit-MCC>.3gppnetwork.org. A formatting mismatch (wrong MNC padding, IMSI truncation) produces a 403.
Step 4 โ Test IMS registration with a confirmed provisioned SIM. Insert a SIM confirmed to have a valid IMS subscription in the same device on the same P-CSCF. A successful REGISTER (200 OK) confirms the issue is USIM or subscription-level, not P-CSCF or network configuration.
Step 5 โ Inspect the P-CSCF address and IPsec SA parameters. In the DIAG log, verify the P-CSCF IP address used by the UE (from PCO in Attach Accept, or from DNS). Confirm it matches the expected P-CSCF address. Check the Security-Client and Security-Server headers in the REGISTER and the P-CSCFโs response: algorithm mismatch or SPI conflict indicates an IPsec SA negotiation failure.
SIP 403 in INVITE Transactions
Beyond REGISTER, SIP 403 can appear in INVITE responses when:
- The called number is barred from receiving calls (operator-side call barring service)
- The originating UE is not authorized to call international numbers (international call restriction active in the HSS)
- An IMS application server (for supplementary services) rejects the INVITE based on the subscriberโs service profile
In INVITE-based 403 rejections, the Via header stack identifies whether the 403 comes from the called partyโs S-CSCF (subscription barring) or from an intermediate AS (supplementary service restriction).
Capturing SIP 403 in the Field
IMS OTA signaling is captured via DIAG log. The decoded SIP REGISTER transaction shows the full 403 response including any Reason header, the P-Asserted-Identity header (if present in the REGISTER), and the Contact and Authorization headers from the REGISTER request. On the calling device, the 403 is visible as a REGISTER transaction failure in the IMS log with no successful 200 OK following.
Related SIP Codes
- SIP 401 โ Unauthorized (IMS AKA challenge โ expected in the normal REGISTER flow, not a rejection)
- SIP 407 โ Proxy Authentication Required (proxy-level authentication challenge, analogous to 401)
- SIP 480 โ Temporarily Unavailable (callee not registered โ subscription may be valid, IMS registration absent)
- SIP 503 โ Service Unavailable (server-side overload, not authorization failure)
- SIP 603 โ Decline (callee actively rejects the call โ subscription is valid)
Founder of HiCellTek. 15+ years in telecom, operator side, vendor side, field side. Building the field tool RF engineers deserve.
Request a personalized demo of HiCellTek โ 2G/3G/4G/5G network diagnostics on Android.