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 to a Ring Group 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 and algorithm fail for INVITE requests from the same device, same source IP and port, same username, same password.
-
Evidence
-
REGISTER and OPTIONS succeed
- Both complete a full digest challenge and 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 and session
INVITE 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
Recomputing the expected digest response by hand from the captured nonce, cnonce, nc, qop, username, realm, method, and Request-URI, plus the plaintext secret configured on the endpoint, produces a value that exactly matches the response 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 digest 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 reload 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 and response round trips logged, so packets are not being dropped.
-
- 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 or dialog-establishing request path.
- Also worth noting: chan_sip is not available on this system (module show like chan_sip returns 0 modules loaded), so switching this extension to the legacy SIP driver, which resolved a similar-sounding HT813 issue in an older thread here, is not an option on this Asterisk version.
-
Request
- Looking for guidance on:
-
- Whether this matches a known Asterisk or PJSIP issue, possibly in res_pjsip_authenticator_digest or the pjsip_distributor endpoint identification for INVITE specifically.
-
- Any Asterisk core version known to fix this.
-
- Any additional diagnostic that would help pin down the exact failure point.
- Happy to provide full raw SIP traces, with IPs and secrets redacted, on request. This is running on a small self-hosted VPS for a single small business, so any pointers toward a config-level workaround would be very welcome too.