Inbound SIP trunk rejected as an unidentified endpoint

Recognize the failure boundary

An external caller reaches the carrier, but the PBX rejects the incoming INVITE before the expected dialplan route. The trunk may still place outbound calls. A successful outbound registration does not prove that inbound requests map to the intended PJSIP endpoint.

Record the call time, called DID, carrier address as seen by the PBX, SIP response and nearby Asterisk security event. Capture only authorized signaling. If the request never reaches the PBX, first investigate the carrier destination, DNS, firewall and transport.

Match the actual source to an endpoint

Asterisk documents distinct endpoint identification methods. A provider INVITE can carry the caller identity in From, so assuming that header identifies the trunk may match the wrong endpoint. In an IP-authenticated design, inspect the loaded identify object and compare its network match to the actual source address.

The current module reference accepts a comma-delimited list of IP addresses or hostnames. A hostname is expanded into resolved A and AAAA addresses, with SRV expansion when enabled and no source port is supplied. Treat that as loaded address-set behavior rather than a promise that future carrier addresses will be trusted automatically. If one identify object contains source, header or request-URI criteria, any one matching criterion can select its endpoint; do not read them as cumulative AND controls.

At the Asterisk CLI, inspect the endpoint and loaded identify association. Use the PJSIP troubleshooting guide for the exact command syntax and installed version. If traffic arrives through an SBC or proxy, the source visible to Asterisk can be the proxy; the direct carrier address is then the wrong identify target.

Use the endpoint-identification guide to compare the loaded global order with the methods permitted for the intended endpoint. A method that is installed but not allowed for that endpoint cannot complete the match.

Inspect the effective identifier state before broadening the trunk

Preserve pjsip show identifiers, pjsip show settings, pjsip show identifies, the intended identify object and its endpoint. Compare the provider request's actual source address and port with every loaded match. For a hostname, Asterisk 22 can expand A and AAAA records and, when enabled without a source port, the documented SIP SRV services; capture the resulting loaded set instead of assuming the name continuously authorizes any address the provider might use.

Changing global order or adding a larger network can affect unrelated phones, trunks and proxies. Prove the intended positive request and a deliberately unrelated negative request, then confirm the selected endpoint and context before moving to DID routing.

Separate identification from authentication

An unmatched request and a matched endpoint with wrong auth are different incidents. The former needs investigation of the identify method and loaded configuration. The latter needs the endpoint’s inbound auth object, challenge and retried request checked without exposing secrets in a ticket.

Do not broaden trusted IP ranges or enable anonymous calling to make an inbound test pass. In a FreePBX-managed system, inspect the supported trunk configuration and generated effective state before editing anything; direct changes to generated files will not be durable.

Only then inspect DID routing

Once the INVITE is associated with the intended endpoint, verify the dialplan context and the called number format delivered by the carrier. A route mismatch after identification is handled in the separate FreePBX inbound route guide.

Check the installed branch before request-URI matching

The current module reference lists match_request_uri from Asterisk 18.23.0, 20.8.0 and 21.3.0. An Asterisk security advisory lists exactly those initial releases as affected by an endpoint-identification flaw and names 18.23.1, 20.8.1 and 21.3.1 as patched. Do not add request-URI identification on an unverified build, and do not infer safety from a major-version label alone.

Record the installed full version and packaging source, compare it with the vendor's supported patched release, and preserve the current endpoint match before changing methods. A request-URI or header regex is also documented as expensive; use an exact bounded value where the provider contract permits it and verify that an unrelated URI or header remains rejected.

Prove both directions and rollback

Place an external inbound call and an authorized outbound test, record the source address and matched endpoint, then repeat after applying the normal managed configuration. Restore the prior identify scope if the result broadens access or matches another trunk.

Continue a delivered Magrathea call into endpoint identification

If an INVITE reaches a nominated Magrathea destination but does not match the intended trunk, use the Magrathea resilience evidence path to keep provider pool health separate from PBX endpoint identification.

Preserve didlogic source, Request-URI and identity model

For an unidentified inbound INVITE, the didlogic diagnostic separates digest Contact delivery from an IP-authenticated SIP URI and records the first PBX identify result.