Asterisk PJSIP repeated 401 or 407 authentication diagnosis

First decide whether the challenge is expected

A 401 or 407 is not automatically an authentication failure. A SIP user-agent server or proxy can challenge an initial request, after which the client retries with an Authorization or Proxy-Authorization header. The symptom is a loop when the retried request is challenged again, never appears, selects the wrong credential, or ends in an unexpected final failure.

Capture one bounded attempt and preserve request method, direction, Call-ID, CSeq, branch, response source, status code, challenge type, realm, algorithm and whether an authorized retry followed. Keep REGISTER and INVITE exchanges separate: successful registration does not prove that an independently challenged call uses the same realm, proxy or auth object.

Locate the Asterisk role and referenced object

If Asterisk sent the challenge, it is acting as the UAS and the endpoint's auth object is relevant. If Asterisk received the challenge, it is acting as the UAC and the endpoint or registration's outbound_auth relationship is relevant. Confirm the endpoint was identified before assuming that the desired auth object was selected.

Inspect the running objects rather than only the source file or GUI. A typo, missing relationship, rejected reload or different registration object can leave the previous policy active. On FreePBX, investigate the supported configuration owner and generated result rather than editing generated PJSIP files.

Compare realm and username before changing the secret

For outbound authentication, Asterisk matches the received realm to an exact, empty or wildcard auth-object realm. For inbound authentication, the configured realm becomes part of the challenge. A pre-computed digest binds username, realm and password; a realm or username mismatch therefore looks like a bad secret even when the operator copied the expected characters.

Compare the observed challenge with the loaded object and the provider's current first-party configuration record. Do not rotate a credential until the object, realm and username are established. A secret rotation can add a second unknown and disrupt working methods or trunks that share the credential.

Check algorithm support and credential material

On the running host, use pjproject show buildopts and the installed Asterisk branch documentation to determine supported algorithms. Compare the remote challenge order with supported_algorithms_uac, or compare the local UAS preference with what the client supports. Asterisk 22 gains SHA-256 and SHA-512-256 digest support at 22.2.0 with the required PJProject and OpenSSL capabilities; an older or differently built system may not provide them.

If the object uses pre-computed password_digest values, confirm that one exists for every allowed algorithm and that it was created with the exact username and realm. A digest for one algorithm cannot satisfy another. Do not copy hashes or Authorization values into general logs.

Read the retry and final response as a sequence

Follow the next request with the incremented CSeq and the relevant authorization header. Determine whether it returned to the same server or proxy, whether a stale nonce produced a new challenge, and whether another hop introduced a different realm. A load balancer, outbound proxy or forked request can make several challenges visible without one endpoint simply repeating itself.

If Asterisk never sends the retry, review realm matching, allowed algorithms, available credential material and configuration-load errors. If it sends a retry that is rejected, compare the server-side account state and time-correlated logs using redacted identifiers. Do not treat a packet capture alone as proof of the remote account status, rate limit or password database.

Correct one demonstrated cause and retest

Change only the proven relationship, realm, username, allowed-algorithm set, matching credential material or remote account state. Preserve rollback and reload or restart only through the supported lifecycle. Repeat the failing request, one known-good control and an intentional wrong-secret case. Confirm the intended algorithm, accepted authorized retry and final registration or call result.

Turn off temporary PJSIP logging and remove raw credentials, digests and personal calling data from retained evidence. No PBX, build, auth object, endpoint, registration, provider, credential, packet exchange, rate limit, account state, protected transport or call was inspected or tested for this diagnosis.

core show version
pjproject show buildopts
pjsip show endpoint <endpoint>
pjsip show auth <auth-object>
pjsip show registrations
pjsip show history

Filter one challenge and credentialed retry sequence

The PJSIP History diagnostic preserves the initial request, challenge, ACK and retry without joining separate Asterisk call legs by guesswork.