Read the complete challenge sequence
Capture the first request, 401 response and next same-method request. Record the responder, Request-URI, Call-ID, CSeq method and number, Via branch, challenge realm, nonce and algorithm, then note whether the retried request contains Authorization and what final response follows. Protect usernames, response digests and other account data in shared evidence.
An initial 401 with WWW-Authenticate is a normal server challenge when the next request answers it and succeeds. Repeated 401 responses, no authenticated retry, or a terminal failure require diagnosis. Keep 407 Proxy Authentication Required separate because it uses a proxy challenge and Proxy-Authorization.
For inbound traffic, prove Asterisk recognized an endpoint
Asterisk's PJSIP troubleshooting guide documents a security-preserving behavior: when an inbound request cannot be matched to an endpoint, Asterisk sends a 401 with dummy challenge information that cannot be authenticated against. This prevents a different response from revealing valid endpoint names. A repeated 401 can therefore be an identification failure before it is a password failure.
Use the source address, transport, request identity and loaded identify rules to bind the request to the intended endpoint. Compare pjsip show endpoint <name> and the matching identify object with the same packet. Do not replace a secret or weaken authentication until the endpoint association itself is established.
For a matched inbound endpoint, inspect InAuth and digest inputs
When Asterisk is the server, the endpoint's auth option selects the inbound authentication object; the CLI endpoint view exposes it as InAuth. Compare the loaded username, realm, configured credential form and supported algorithms with the challenge and retry. Username case, realm and algorithm are part of the digest inputs. Never log or publish the clear-text password.
Current Asterisk documentation makes SHA-256 and SHA-512-256 support version- and dependency-sensitive. Use pjproject show buildopts to inspect the running build and the loaded auth object to inspect policy. A digest pre-hash is tied to its realm and algorithm; a hash for one algorithm cannot generate a valid response for another.
For outbound traffic, use the correct outbound-auth owner
When Asterisk receives 401 from a provider or registrar, identify whether the challenged object is an endpoint request or an outbound REGISTER. An endpoint uses outbound_auth; an outbound registration has its own outbound_auth relationship. The inbound auth option serves the opposite direction and should not be treated as a substitute.
Compare the challenge realm with the selected auth object. Asterisk recommends leaving an outbound realm empty or wildcarded unless the exact server realm is known, while pre-hashed credentials require that realm to be known in advance. Confirm that the loaded object can answer one of the offered algorithms and that the retried request actually carries Authorization.
Separate bad credentials from account authorization
If the authenticated retry is present but 401 repeats, preserve the provider or endpoint log for the same transaction and compare username, realm, algorithm, nonce handling and credential ownership. Do not infer the secret from the status code, rotate unrelated accounts or change multiple digest controls at once.
A later 403 is a different boundary: the server understood the request and refused it. Likewise, a successful REGISTER establishes one binding, not permission for every destination or asserted identity. Keep the 403 investigation and call-routing evidence separate.
Prove one narrow correction
Correct the demonstrated identity, realm, algorithm, credential or object relationship in its authoritative configuration. On FreePBX, use the managed extension or trunk fields and Apply Config instead of editing generated PJSIP files. Repeat the same method and verify one clean challenge, one authenticated retry and the expected final response; then observe a later registration refresh or a nearby allowed call.
Enable PJSIP protocol logging only for the shortest useful capture and remove or narrow it afterward. A successful challenge sequence is the proof for this boundary; it does not establish media, emergency or every destination path. No PBX, endpoint, provider, account, password, realm, algorithm, registration or live-call behavior was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: SIP digest challenge processing ↗
- Asterisk PJSIP authentication ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk res_pjsip configuration reference ↗
- Asterisk outbound registration guide ↗
- Asterisk outbound-registration configuration ↗
- Asterisk debug-information collection ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.