SIP 401 / 407

SIP 401 and 407 authentication loops in Asterisk

A single 401 or 407 is not an error at all - it is the normal first half of SIP digest authentication. The failure is the loop: REGISTER, challenge, REGISTER, challenge, several times in a few seconds, never arriving at a 200 OK. This is what a trunk not registering almost always looks like from the client side.

What it looks like in the log

[2026-08-17 08:31:02] VERBOSE[3120] res_pjsip_logger.c: <--- Received SIP response (534 bytes) --->
SIP/2.0 407 Proxy Authentication Required
Proxy-Authenticate: Digest realm="asterisk",nonce="1c8f2b0a"
CSeq: 4471 REGISTER
[2026-08-17 08:31:02] VERBOSE[3120] res_pjsip_logger.c: <--- Transmitting SIP request (712 bytes) --->
REGISTER sip:pbx.example.net SIP/2.0
[2026-08-17 08:31:04] VERBOSE[3120] res_pjsip_logger.c: <--- Received SIP response (534 bytes) --->
SIP/2.0 407 Proxy Authentication Required

What it means

Digest authentication is a two-round-trip handshake. The endpoint sends a request with no credentials, the server replies with a challenge containing a realm and a nonce, and the endpoint re-sends the request with a hash computed over the username, password, realm and nonce. If that hash is right, the server accepts it.

When the hash is wrong the server cannot tell you why it is wrong - it only knows the digest did not match. So it challenges again, the endpoint answers again, and the two of them will do this until the registration timer gives up. Seen from the server's side, the same loop is logged as a stream of "Failed to authenticate" NOTICEs against the source address. The loop in the log is the whole diagnosis: it says the digest computation is producing a different answer on each side, and there are only a handful of inputs that go into it.

Most common causes

  1. 01The password is wrong

    The obvious one, and still the most common. Watch for trailing whitespace pasted into a config file and for a password changed on the PBX but not on the phone.

  2. 02The realm does not match

    The realm is an input to the digest hash, so a mismatch produces a wrong hash even when the password is perfect. This bites when a provider specifies a realm that differs from their SIP domain, or when Asterisk's default realm of asterisk was overridden in pjsip.conf on one side of an upgrade.

  3. 03The username is not the auth username

    The user in the From header and the user used for authentication are separate fields and frequently differ on carrier trunks. Setting only one of them leaves the other defaulting to something that will not authenticate.

  4. 04auth_type set to userpass while a hash is configured

    If auth_type=md5 is expected and password= is set instead of md5_cred=, or the reverse, Asterisk computes the digest from the wrong material.

  5. 05A stale nonce being reused

    Some endpoints cache a nonce past its lifetime. The server rejects it as stale and re-challenges, and a device that keeps replaying the same one will loop forever.

How to tell which one it is

Read the realm straight off the WWW-Authenticate or Proxy-Authenticate header in the challenge, then compare it character for character against the realm configured on the endpoint. This one comparison resolves a large share of these loops and takes ten seconds once the challenge line is in front of you.

Next, read the username parameter in the Authorization header of the re-sent REGISTER. That is the name the endpoint is actually authenticating as, which is not always the one in the From header, and not always what the config appears to say.

How to fix it

Related failures