Read the complete proxy challenge sequence
Capture the first request, 407 response and next same-method request. Record the responder, Request-URI, Route set, Call-ID, CSeq method and number, top Via branch, Proxy-Authenticate realm, nonce and algorithm, then note whether the retry contains Proxy-Authorization and which final response follows. Redact usernames, response digests and account data before sharing evidence.
An initial 407 can be a normal proxy challenge when Asterisk sends the authenticated retry and the transaction then succeeds. Repeated 407 responses, no retry or a terminal failure require diagnosis. Keep 401 separate: a server or registrar uses WWW-Authenticate and the client answers with Authorization, while a proxy uses Proxy-Authenticate and Proxy-Authorization.
Identify the proxy and the request path it challenged
Bind the response to the exact network hop and method instead of treating every 407 as a registrar-password failure. Compare the source of the 407, Via chain, Route headers, Request-URI and configured outbound proxy with the provider's current instructions. A proxy-auth challenge can apply to INVITE or another outbound request as well as REGISTER.
RFC 3261 permits a response to carry multiple authentication challenges when proxies aggregate forked results. Preserve every Proxy-Authenticate and WWW-Authenticate field and its realm; one successful credential does not answer a different realm. Do not copy credentials between unrelated proxies merely because the domains look similar.
Select the correct Asterisk outbound-auth owner
For an outbound call or other endpoint request, inspect the loaded endpoint and its outbound_auth relationship. For an outbound REGISTER, inspect the registration object and that object's own outbound_auth. Both options point to auth objects, but the endpoint and registration are separate owners and can follow different proxy paths. The inbound endpoint auth option serves the opposite direction and is not a substitute.
Use the Asterisk CLI views for the exact endpoint, auth object and registration rather than relying only on a configuration file. On FreePBX, trace those loaded objects back to the managed trunk fields; do not repair generated PJSIP files directly.
Compare realm, username and supported digest algorithm
Match the challenge realm to an outbound auth object that has the intended username and credential form. Current Asterisk guidance recommends leaving an outgoing realm empty or wildcarded unless the exact remote realm is known. A pre-hashed credential is bound to the username, realm and digest algorithm, so a hash prepared for another realm or algorithm cannot answer this challenge.
Asterisk documents SHA-256 and SHA-512-256 support as dependent on the Asterisk, PJProject and OpenSSL versions. Use pjproject show buildopts to inspect the running build and compare the loaded auth object with every offered algorithm. Do not downgrade authentication policy or expose the clear-text password just to make one retry appear.
Distinguish a missing retry from a rejected retry
If no next request carries Proxy-Authorization, check whether the correct endpoint or registration selected an outbound auth object, whether any object matched the realm and algorithm, and whether Asterisk associated the response with the original transaction. If the authenticated retry is present but 407 repeats, compare its username, realm, nonce, algorithm, URI and CSeq with the proxy's account evidence.
Do not interpret a later 403, 404, timeout or successful response as another 407. Those are separate routing or authorization boundaries after the proxy-auth step. A successful proxy challenge proves only that this proxy accepted credentials for this transaction; it does not establish destination permission, registration state, media or caller identity.
Control outbound-registration retry behavior
Asterisk's outbound-registration guide says authentication-related rejection is permanent by default when auth_rejection_permanent is enabled. Disabling that option can make 401 and 407 temporary and therefore subject to retry_interval and max_retries. That control changes retry behavior; it does not correct a realm, username, credential, algorithm or proxy-path error.
Preserve the current setting and registration state before changing it. Avoid creating a repeated authentication loop against a provider. Correct the demonstrated owner or digest input first, reload through the authoritative configuration path, and observe one controlled renewal plus the next scheduled refresh.
Prove one narrow correction
Repeat the same method through the same proxy and verify one 407, one higher-CSeq retry containing Proxy-Authorization for the challenged realm and the expected final response. If multiple realms were challenged, verify that the retry preserves the required authorization fields rather than assuming the first one is sufficient.
Enable PJSIP protocol logging only for the shortest useful capture and remove or narrow it afterward. A clean proxy-auth sequence does not prove RTP, emergency calling, every destination or continued registration. No PBX, endpoint, proxy, 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: proxy-to-user authentication ↗
- IETF RFC 8760: SIP digest authentication ↗
- Asterisk PJSIP authentication ↗
- Asterisk res_pjsip endpoint and auth reference ↗
- Asterisk outbound registration guide ↗
- Asterisk outbound-registration configuration ↗
- Asterisk PJSIP configuration examples ↗
- Asterisk debug-information collection ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.