Three responses, three different problems
Authentication failures are the most common reason a phone will not register or a trunk will not pass calls, and the response code tells you almost everything — provided you know which is which. The three you will meet are 401, 403 and 407, and confusing them sends you looking in entirely the wrong place.
The critical distinction is between a challenge and a refusal. 401 and 407 are challenges: the server is asking you to prove who you are. 403 is a refusal: the server has decided, and is not asking for anything.
401 Unauthorized — the registrar is challenging you
A 401 is user-to-user authentication. The server receiving the request challenges the client directly using a WWW-Authenticate header, because the endpoint requires credentials before it will act.
The single most important thing to understand: a 401 on the first attempt is completely normal. SIP registration is designed as a two-step exchange. The phone sends a REGISTER with no credentials, the registrar replies 401 with a challenge, and the phone re-sends the REGISTER with a computed response. That is the protocol working correctly.
What indicates a real fault is a repeating 401 — challenge, response, challenge again, forever. That means the credentials being supplied are wrong, or something in the path is altering the request so the computed hash no longer matches.
407 Proxy Authentication Required — a proxy is challenging you
A 407 is structurally identical to a 401 but comes from an intermediary rather than the endpoint. A proxy in the path challenges the client using a Proxy-Authenticate header before it will forward the request onward, typically to enforce routing policy or access control.
The client answers with Proxy-Authorization rather than Authorization. Devices that handle 401 correctly but ignore 407 do exist, and they fail in exactly one scenario: when a proxy sits in the path. If registration works direct but fails through a session border controller or carrier proxy, suspect this.
How digest authentication works
SIP borrows HTTP's digest scheme, and it is worth knowing the mechanics because they explain several otherwise baffling failures.
Rather than sending a password, the exchange is challenge-response. The server generates a nonce — a randomly generated value — and sends it in the challenge. The client computes a cryptographic hash combining its credentials with that nonce and returns the hash. The password itself is never transmitted.
The nonce exists specifically to prevent replay attacks. Because each challenge carries a fresh nonce, an attacker who captures a valid response cannot reuse it: the next challenge will use a different nonce, and the captured hash will not match.
Two practical consequences follow:
- Nonces expire. A client that takes too long to answer a challenge gets rejected and must start again. On a badly congested or high-latency link this can produce intermittent registration failures that look random.
- The hash covers request details, not just the password. If a middlebox rewrites the request URI or another covered field in transit, the hash computed by the client no longer matches what the server computes — and you get an authentication failure with entirely correct credentials. This is one of the more insidious ways a router's SIP ALG breaks a working system.
403 Forbidden — the server has decided
403 is different in kind. The server understood the request perfectly well and refuses to fulfil it. Critically, no authentication challenge is issued — the refusal is based on existing identity verification or on policy.
That absence of a challenge is the diagnostic. If you see a bare 403 with no preceding challenge, the server is not asking for credentials; it has already concluded you may not do this. Common causes on a trunk:
- The source IP is not on the carrier's allow-list (IP-authenticated trunks)
- The account is suspended, unpaid or disabled
- You are dialling a destination or prefix the account is not permitted to reach
- The number format is not what the carrier accepts, so the route is refused outright
- Too many failed attempts have triggered a temporary block
Diagnosing in practice
Watch the actual exchange rather than reasoning from the logs' summary lines:
asterisk -rvvv
pjsip set logger on # or: sip set debug onThen read the pattern:
- 401 → REGISTER with credentials → 200 OK. Working normally. Nothing to fix.
- 401 → REGISTER → 401 → REGISTER… Wrong secret, wrong username, or the auth realm does not match what the server expects.
- 407 appearing where you expected 401. A proxy is in the path. Confirm the device supports proxy authentication.
- 403 with no challenge at all. Not a credentials problem. Check IP allow-listing, account status and dialling permissions before touching passwords.
Always read any Warning or Reason header attached to a 403 — carriers frequently put the actual explanation there while returning a generic code.
A note on brute-force attempts
If your SIP port is reachable from the internet, you will see continuous authentication attempts against extension numbers. Repeated 401s in your logs from addresses you do not recognise are not a configuration problem — they are scanning.
Two responses matter: use long random secrets rather than anything resembling the extension number, and run fail2ban against Asterisk's security log so repeat offenders are blocked at the firewall.
Frequently asked questions
Is a 401 an error?
Not on its own. The first 401 in a registration is the normal authentication challenge; the phone should immediately retry with credentials. Only a repeating cycle of 401s indicates a real failure.
What is the difference between 401 and 407?
401 comes from the endpoint or registrar using WWW-Authenticate; 407 comes from a proxy using Proxy-Authenticate. The mechanism is the same, the challenger is different.
Why do I get 403 Forbidden with correct credentials?
Because 403 is not about credentials. No challenge is issued — the server is refusing on policy. Check IP allow-lists, account status, and whether the destination you dialled is permitted.
Why does authentication fail only through my router?
Digest hashes cover parts of the request. If a SIP ALG rewrites the request in transit, the hash no longer matches and authentication fails despite correct credentials. Disable SIP ALG.