Asterisk PJSIP cannot identify an inbound request: endpoint-matching diagnosis

Anchor the investigation to one rejected request

Record the exact timestamp and timezone, transport, local listener, source IP and port, request method, Request-URI, From user and domain, Call-ID and the first specific Asterisk message. Asterisk's troubleshooting guide shows that an inbound request must be associated with a configured endpoint before endpoint policy or dialplan routing can apply. If that match fails, editing an inbound route, DID pattern, codec list or RTP setting is premature.

Use a narrowly scoped PJSIP logger only for an authorized reproduction, protect identities and authentication material, and disable temporary logging afterward. Keep a known-working request through the same listener as a control. Do not publish full SIP captures or turn on anonymous matching merely to make the warning disappear.

Prove which objects and identifier modules are loaded

Inspect the running engine rather than assuming that a saved file or PBX interface entry loaded successfully. Use pjsip show endpoints, inspect the expected endpoint and identify object, and run pjsip show identifiers to see the available identifier modules and their order. The Asterisk troubleshooting guide notes that an object can fail to load because of an invalid option, missing type or other configuration error.

For a generated platform such as FreePBX, compare the supported interface, generated configuration and loaded PJSIP objects without editing generated files directly. A successful Apply Config action is not evidence that the intended endpoint or identify object exists in the running process.

Record the loaded winner before changing order

Run pjsip show identifiers and pjsip show settings to preserve the effective global order, then pjsip show identifies, pjsip show identify <name> and pjsip show endpoint <name> for the intended association. The first identifier that returns an endpoint owns the request, so a broad earlier match can prevent a later, more specific mechanism from being consulted.

Compare the failing request with a known-good control and predict the winner for both. A change is justified only when the evidence identifies the wrong owner, missing object, disallowed endpoint method or stale address set. Rearranging the order until one call passes can silently move phones, trunks or proxies into the wrong context.

pjsip show identifiers
pjsip show settings
pjsip show identifies
pjsip show identify trunk-primary
pjsip show endpoint trunk-primary

Trace global order and endpoint permission separately

The global endpoint_identifier_order controls which installed identifier mechanisms run first. An endpoint's identify_by list controls which methods may identify that endpoint. These are different controls: a permitted method cannot match if its module is absent, while an earlier broad method can claim a request before the intended mechanism is tried.

Write down the loaded global order, the expected endpoint's allowed methods and any overlapping candidate. Predict the winner for the failing request and for the control before changing anything. If several endpoints could match, narrow the authoritative criterion instead of simply rearranging identifiers until one call succeeds.

Compare the actual field used by each method

Username identification uses the From user; auth_username depends on a username in an Authentication header; IP identification uses an identify object; and the IP identifier module can also match a configured header or Request-URI. Compare the captured request with the exact loaded criterion, including source port, domain and URI form. Do not substitute the called DID, Contact user, asserted caller ID or outbound registration username unless the selected method actually reads that field.

Asterisk documents that auth_username may defer the unmatched-request event until a challenged request carries an Authentication header. Treat that as an identification timing boundary, not proof of successful authentication. Validate the later digest challenge and result separately.

Do not convert security-event timing into match evidence

Asterisk 22 documents that digest auth_username normally cannot inspect an Authentication header on the first request because the client has not yet received a challenge. Security-event generation can therefore be deferred until a challenged request supplies that header. The global unidentified-request count and period control when that event is generated; they do not identify an endpoint, authenticate a credential or authorize a call.

Preserve the initial request, challenge, retried request, selected endpoint, authentication result and security event as separate observations. Do not lower thresholds, enable anonymous matching or remove authentication merely to suppress a log message. A delayed event can still describe a rejected attack, while a matched endpoint can still fail authentication or later policy.

Validate IP, hostname, header and URI boundaries

The current IP identifier reference allows address and CIDR matches with optional source ports, hostnames resolved through A and AAAA records, optional SIP SRV expansion, header criteria and Request-URI criteria. Within one identify object these criteria are alternatives: any one can select the endpoint. That OR behavior can make a convenient extra match broader than intended.

Compare all provider signaling addresses and ports with current first-party service records, the DNS answers visible to this host and the actual source on the wire. Keep trusted proxy addresses separate from the originator behind them. Prefer an exact bounded header or URI value over an expensive regular expression, prove an authorized positive and an unrelated negative, and do not authorize an oversized carrier or cloud range merely to cover one observed edge.

Keep registration, identification, authentication and routing distinct

Outbound registration tells a remote registrar where this Asterisk system can be reached; it does not automatically identify a later inbound INVITE. Asterisk's proxy guidance documents a registration line option that can add a token to incoming INVITEs for identification, but that is a specific supported relationship, not a general consequence of REGISTER succeeding.

After the endpoint is selected, prove authentication if configured, then the endpoint context and dialed extension, and only then media. Record each boundary independently. This prevents a matching repair from being misreported as a complete inbound-call repair when the next stage still fails.

Make one bounded change and prove rollback

Change only the authoritative endpoint, identify object, provider source record, generated platform setting or documented identifier order required by the evidence. Apply it through the correct lifecycle for the installed branch and management platform. Repeat the failed request and the control, then confirm the selected endpoint, context, authentication result and final call outcome.

Also repeat the negative case so an unrelated source, username, header or URI remains rejected. Roll back if the selected endpoint, context or security-event behavior broadens unexpectedly. No Asterisk host, branch, distribution patch, module, endpoint, identify object, DNS response, provider signaling address, proxy, registration, credential, SIP transaction, dialplan, media path or live call was inspected or tested for this guide.

Check registration-linked identification only when the token exists

When a provider is expected to return the unique Contact line token, use the registration-return diagnostic to compare the accepted Contact with the inbound Request-URI or To header before adding source-IP or header rules.

Confirm an ACL did not reject the request first

Before changing endpoint identifiers, use the PJSIP ACL rejection diagnostic to preserve the packet source, module-wide and endpoint rules, and any REGISTER Contact decision.