Troubleshooting · SIP Codes
SIP 401 & 407: Authentication Challenges
401 and 407 are the two SIP codes that newcomers misread most, because the first appearance of either is not a failure — it is the server asking 'prove who you are'. SIP authentication is a challenge-response dance: your request is refused with a challenge (a nonce), your phone re-sends with a hashed answer, and the server accepts. A healthy registration shows exactly one 401. A 401 that repeats forever means the answer is never right.
401 comes from the endpoint/registrar itself; 407 is the same challenge issued by a proxy in the path. The mechanics — and the fixes — are identical.
How digest authentication works
SIP uses HTTP-style digest authentication (RFC 3261 §22, updated by RFC 8760 for stronger algorithms). The server's challenge carries a realm and a nonce. The phone computes a hash from the username, realm, password, nonce and request details, and returns it in an Authorization header — the password itself never crosses the wire. This design means three distinct failure species: the hash inputs disagree (wrong password, wrong username, wrong realm), the phone never answers the challenge (broken client behavior, an intermediary stripping headers), or the server rejects a correct-looking answer because the account itself is locked, expired or unauthorized for that service.
Phone --- REGISTER (no auth) ------> Registrar
Phone <-- 401 Unauthorized ---------- Registrar
WWW-Authenticate: Digest realm="provider.example",
nonce="8f3ka92...", algorithm=MD5
Phone --- REGISTER + Authorization -> Registrar
(response = hash of credentials + nonce)
Phone <-- 200 OK -------------------- Registrar healthy
# Pathology: the 401 keeps coming after the answer = the answer
# is being computed from wrong inputs, or never arrives.
Why the loop happens
- Wrong secret — the password on the phone ≠ the password on the account. The most common cause by a wide margin, especially after a provider-side reset or a config copy from another extension.
- Username vs auth-ID confusion — many systems distinguish the extension (address) from the authentication username. Entering the extension in both fields works on some platforms and loops forever on others.
- Realm mismatch — usually automatic; breaks when a proxy rewrites realms or a phone is hard-coded to a stale realm from a previous provider.
- Header-stripping intermediaries — a SIP ALG or SBC that drops or mangles the Authorization header on the second REGISTER, so the server sees an unauthenticated request again and re-challenges.
- Clock skew with TLS — certificate validation failures present as authentication failures on TLS transports; check the phone's date/time (and NTP) before doubting credentials.
Fix sequence
- Confirm the pattern in a capture: challenge → answer → challenge again (loop), or challenge with no answer (client/intermediary problem). That split directs everything below.
- Re-enter credentials from the provisioning record by hand on one phone: extension, auth username, and secret — typed fresh, not copied between fields or restored from an old config backup.
- Check the account state server-side: exists, enabled, not locked by failed attempts (repeated loops can trip lockouts — wait or unlock before retesting).
- Remove intermediaries from suspicion: test the same credentials from a different network (or a softphone) — success elsewhere convicts the path (ALG/SBC), not the credentials.
- For TLS endpoints, verify the phone's clock via NTP and that the server name matches the certificate the platform presents.
- Verify with a clean single-challenge registration and an inbound + outbound test call.
Frequently asked questions
- Is 401 a security attack I should worry about?
- Seeing 401s is normal — they are issued to every unauthenticated request. What deserves attention is volume from unknown sources hitting a public PBX (credential probing). On hosted platforms the provider handles this; on your own PBX, firewall rules and strong secrets are the answer — and registration rate-limiting.
- 407 vs 401 — does it change the fix?
- No. 407 means a proxy issued the challenge (the response goes in a Proxy-Authorization header). The inputs and the failure species are the same; the only difference is which box is asking.
- Our phones show 401 loops after a provider password policy change.
- A policy change that reset or expired secrets produces fleet-wide loops with exactly this signature. Re-provision the new secret by your normal config push and confirm one phone end-to-end before pushing the fleet.