A challenge can be normal
A server can respond with 401 and WWW-Authenticate; a proxy can use 407 and Proxy-Authenticate. The client then retries with the corresponding authorization header. The digest is computed from credentials and challenge/request information rather than sending the password as a plain header value. This does not make an unencrypted capture harmless. Digest exchanges can expose identities and support password-guessing attacks, particularly with weak secrets or legacy algorithms. Protect signaling transport and capture files as well as the credential itself.
Check the negotiated inputs
Compare realm, nonce, algorithm, username and the URI used in the digest calculation. A stale nonce can legitimately trigger a fresh challenge. Repeated challenges with no progress may indicate mismatched credentials, an unsupported algorithm or an authorization identity different from the extension number. RFC 8760 adds stronger digest algorithms, including SHA-256 and SHA-512/256. Endpoint and registrar support must align; enabling a stronger algorithm only on one side can interrupt registration. Do not describe MD5-era interoperability as a reason to accept short passwords or disable TLS validation.
For Asterisk PJSIP specifically, SHA-256 and SHA-512-256 support arrived in 22.2.0 (and corresponding 20.12.0/21.7.0 releases) with PJProject 2.15.1. OpenSSL and build/runtime capabilities also matter. pjproject show buildopts reports supported algorithms on the running system. Test both peer capabilities and the configured UAS/UAC algorithm lists before a staged change; a guide labeled “Asterisk 22” is not enough to establish support on every 22.x patch level.
Separate authentication from permission
A successful digest response establishes a credential relationship; it does not authorize every destination or feature. A later 403 can reflect policy, tenant assignment or destination restrictions. Check server-side reasons without repeatedly changing a working password. Rotate a suspected exposed secret, update its authorized endpoints and inspect registration and call history. When sharing evidence, remove Authorization headers and secrets entirely. Keep response codes, realm where appropriate, algorithm and anonymized timing so the failure remains diagnosable.
Retain Twilio challenge and retry evidence
The Twilio termination diagnostic captures the 407 challenge, credential-list association, authenticated retry and final response without treating an initial ACL rejection as a digest failure.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261 ↗
- IETF RFC 8760 ↗
- Asterisk: PJSIP authentication algorithms and version prerequisites ↗
- Twilio Elastic SIP Trunking configuration ↗
- Twilio Elastic SIP Trunking troubleshooting ↗
- Twilio sending-SIP best practices ↗
- Twilio CredentialList resource ↗
- Twilio Trunk resource ↗
- Twilio error 32201: source IP address not in ACL ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.