Environment
- FreePBX 17.0.30
-
- Asterisk 22.10.1 (FPBX-17.0.30(22.10.1))
-
- Endpoint device: Grandstream HT813 (firmware 1.0.17.3), extension 190, PJSIP/UDP, non-WebRTC
-
- Extension purpose: FXO gateway bridging a PSTN landline (Airtel) to a Ring Group (500) on the PBX
-
Summary
- For PJSIP extension 190, digest authentication succeeds consistently for REGISTER and OPTIONS requests using the currently configured secret, but the identical credentials/algorithm fail for INVITE requests from the same device, same source IP/port, same username, same password.
Evidence
-
REGISTER and OPTIONS succeed
-
REGISTER and OPTIONS both complete a full digest challenge/response cycle and return 200 OK. The endpoint subsequently shows as Reachable in pjsip show endpoint 190, with a live registered Contact.
-
INVITE fails identically, same device/session
-
INVITE to sip 500 at pbx.bbtech.in port 5060 gets repeated 401 Unauthorized through nc=00000006, then the device gives up. Asterisk log shows a pjsip_distributor notice for the INVITE request reading Failed to authenticate. On later retries within the same call, a second notice also appears interleaved, reading No matching endpoint found after 5 tries in 0.1 ms.
-
Independent verification that the digest response is mathematically correct
-
Given the exact captured nonce, cnonce, nc, qop, username, realm, method, and Request-URI from a failing INVITE attempt, and the plaintext secret configured on the endpoint, recomputing the expected digest response by hand (HA1 = MD5 of user colon realm colon pass, HA2 = MD5 of method colon uri, response = MD5 of HA1 colon nonce colon nc colon cnonce colon qop colon HA2) produces a value that exactly matches the response value sent by the device. Verified for multiple INVITE attempts across two different secrets. This rules out password mismatch, typo, or stale credential on either side.
-
Ruled out causes
-
- Password mismatch: ruled out by direct MD5 recomputation, tested with two different secrets.
-
- Duplicate or orphaned PJSIP objects: pjsip show auths shows exactly one auth object per extension.
-
- Stale sorcery or database corruption: extension was fully deleted and recreated from scratch with a full Apply Config in between; the identical failure reproduced immediately afterward.
-
- Firewall or Fail2Ban blocking: calling IP is in the Trusted zone, no active bans, and the SIP exchange completes fully at the application layer with multiple 401 challenge/response round trips logged, so packets are not being dropped.
-
- Weak Password Detection module: no weak secrets detected.
-
- License or module restriction: all core modules involved are GPL and Enabled, no commercial module gating applies.
-
- PJSIP identify_by IP ACL: adding a static identify object for the device IP did not fix the issue and introduced additional intermittent No matching endpoint found errors, so it was reverted.
-
- SIP OPTIONS keep-alive interference: disabled on the device and retested, no change.
Observation of interest
The “No matching endpoint found after N tries” message appears specifically during INVITE authentication retries, never during REGISTER or OPTIONS, and never on the first 2-3 INVITE retries. It appears intermittently partway through the retry sequence. This suggests a possible race or state issue in endpoint identification specifically under the INVITE / dialog-establishing request path.
Request
Looking for guidance on:
- Whether this matches a known Asterisk/PJSIP issue, possibly in res_pjsip_authenticator_digest or the pjsip_distributor endpoint identification for INVITE specifically.
- Any Asterisk core or FreePBX module version known to fix this.
- Any additional diagnostic (pjsip set logger on, core set debug on res_pjsip_authenticator_digest, or a core dump) that would help pin down the exact failure point.
Happy to provide full raw SIP traces (redacting IPs/secrets) on request.