SIP registration fails with 401 or 403: what to check

2026-11-07

When a phone or trunk cannot register, you will almost always see a 401 Unauthorized or a 403 Forbidden in the capture. They mean very different things, and telling them apart is half the diagnosis.

401 is normal — once

SIP digest authentication is a challenge/response. The first REGISTER is sent without credentials, the server replies 401 Unauthorized with a WWW-Authenticate header (containing the realm and a nonce), and the client then sends the REGISTER again with an Authorization header. A successful registration looks like this:

UA → S   REGISTER
UA ← S   401 Unauthorized   (WWW-Authenticate: realm, nonce)
UA → S   REGISTER           (Authorization: digest ...)
UA ← S   200 OK

So a single 401 followed by a 200 OK is not a problem — it is the handshake working.

When 401 is the problem

If you see the 401 loop forever — REGISTER → 401 → REGISTER → 401 → … and never a 200 OK — the credentials are being rejected. Check:

Wrong password, or auth username ≠ user part (many systems use a separate "auth ID").
Realm/domain mismatch — the client authenticates against a different realm than the server expects.
Clock skew or nonce handling — stale nonces can cause repeated challenges.

403 is a flat rejection

A 403 Forbidden means the server understood the request and refused it — no retry will help until something changes:

UA → S   REGISTER   (Authorization: digest ...)
UA ← S   403 Forbidden

Typical causes:

Wrong credentials (some servers answer 403 instead of looping on 401).
Account disabled / not provisioned for this user or trunk.
Source IP not allowed — an IP access list or geo-block on the SBC.
Wrong SIP domain / From user that does not match the account.

How to confirm it in the capture

Find the REGISTER and the response.
401 then 200 OK → registration is fine, look elsewhere.
401 loop → check username/auth-ID, password and realm on the second REGISTER's Authorization header.
403 → check account status, the registrar's IP allow-list, and that the SIP domain/From matches the account.

The quickest wins: compare the realm in the server's challenge with what the client is configured for, verify the auth username separately from the display/user part, and — for 403 — confirm the source IP is permitted.