Asterisk PJSIP endpoint identification: order, scope and evidence

Place identification before authentication and routing

When a SIP request arrives, Asterisk first needs to associate it with a configured endpoint. That decision selects endpoint policy such as inbound context, authentication and media rules. A request that cannot be identified has not yet reached the DID or extension logic you may be tempted to edit.

Inventory each phone, trunk and trusted proxy with its intended identification method. Keep outbound registration separate: registering to a carrier does not automatically tell Asterisk which endpoint owns a later inbound INVITE.

Separate the available methods

Asterisk documents username matching from the From header, auth_username matching from an Authentication header, source-IP matching through an identify object, and identify-object matching by a configured header or request URI. These methods make different trust assumptions. A caller-controlled From value is not equivalent to a known signaling address, and an intermediate SBC changes the source visible to Asterisk.

The endpoint’s identify_by setting permits methods for that endpoint. IP, header and request-URI matches also need the corresponding identify object and module. For registrations, at least one selected method must also be able to determine the AOR. Within one identify object, the current module reference says multiple source, header or request-URI criteria are alternatives: any matching criterion selects the endpoint. Do not describe those fields as cumulative controls.

Bind hostname and request-URI behavior to the installed version

The current Asterisk 23-generated module reference allows source matches to contain IP addresses or hostnames. It resolves A and AAAA records and, with srv_lookups enabled and no explicit source port, also expands the documented SIP SRV records. Capture the loaded resolved addresses and source port; a hostname in configuration is not a live authorization oracle for every future carrier address.

The same reference lists request-URI matching from 18.23.0, 20.8.0 and 21.3.0. Asterisk's security advisory GHSA-qqxj-v78h-hrf9 lists those exact initial releases as affected and 18.23.1, 20.8.1 and 21.3.1 as patched. Verify the full installed build and distributor patch state before relying on the method. Header and request-URI regular expressions are documented as expensive, so prefer an exact bounded value where possible and prove a negative case.

Treat global order as shared behavior

The global endpoint_identifier_order determines which installed identifiers Asterisk tries first. The documented default is ip,username,anonymous, while the performance guide shows a phone-heavy example that moves username ahead of IP. That example is a workload illustration, not a universal security recommendation.

Changing the order can make a broader or earlier method claim a request before the intended method sees it. Record the current order, overlaps and expected winner for representative phone, trunk and proxy requests. Never add anonymous merely to suppress an identification error.

Account for the authentication challenge boundary

With digest authentication, an Authentication header is normally absent from the first request. Asterisk therefore warns that auth_username defers the unmatched-request security event until a challenged request arrives with that header, subject to the global unidentified-request controls. This is materially different from an immediate IP or username match.

Do not confuse delayed identification with successful authentication. After an endpoint is selected, validate the challenge, account identity, realm, algorithm and result separately. Preserve enough logging to distinguish an unknown endpoint from a known endpoint with an invalid password.

Read the effective order and loaded identify objects together

Use the running process to distinguish four different states. pjsip show identifiers lists the registered identifier mechanisms in the order Asterisk will try them. pjsip show settings exposes the effective global settings. pjsip show identifies lists loaded identify objects, while pjsip show identify <name> and pjsip show endpoint <name> expose one object's criteria and the endpoint's permitted identify_by methods.

One list does not substitute for the others. An installed ip identifier does not prove the expected identify object loaded; a loaded object does not prove its endpoint permits that method; and a permitted method does not prove it wins the global order for one request. Preserve the exact source address, transport, From user, authentication user, Request-URI and relevant header with the CLI snapshot, then name the first identifier expected to match.

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

Keep hostname expansion and future provider addresses separate

Asterisk 22 documents IP-identify match values as IP addresses or hostnames. With srv_lookups enabled and no source port, it can expand the documented SIP SRV services and add the resolved A and AAAA addresses; otherwise it resolves the hostname directly. That creates matching candidates for the loaded configuration. It is not proof that every future carrier edge, proxy or address range is authorized.

Capture the loaded matches after the normal configuration lifecycle and compare them with the actual packet source. If DNS or the provider's signaling pool changes, re-evaluate the accepted address set through the provider's current implementation record. Do not replace a bounded match with a broad network merely because one expected address was absent.

Inspect the running system and prove non-overlap

Use pjsip show identifiers to list the identifier modules actually available, then inspect the intended endpoint and its loaded settings. Capture one authorized request with source address, relevant headers, request URI, matched endpoint and resulting context. Compare that evidence with the saved configuration after its normal reload or restart lifecycle.

Test at least one request for every overlapping endpoint class, including a legitimate failure. Confirm that an unrelated source or identity remains rejected. Roll back if a new method or order broadens access, changes the selected context or masks security events.

pjsip show identifiers
pjsip show endpoints
pjsip show endpoint trunk-primary

Diagnose the rejected transaction before redesigning identification

When Asterisk reports that it could not identify an inbound request, use the unidentified-request diagnosis to compare that message's source, From user, Authentication user, header and Request-URI with the loaded modules, global order, endpoint permissions and identify objects. It preserves registration, authentication, routing and media as later boundaries and requires both an authorized positive and unrelated negative test.

Treat registration line tokens as a bounded identifier

An outbound registration can add a unique line token and associate it with an endpoint when the far side returns that token. The line-matching guide keeps this path separate from source-IP, username, header and request-URI identification.

Do not confuse a permitted source with an identified endpoint

An ACL result and endpoint identification answer different questions. Use the PJSIP ACL guide and rejection diagnostic to preserve both decisions before changing match order or ranges.

Resolve identify-object ownership before inspecting matches

The PJSIP Realtime diagnostic checks the optional module's Sorcery section, family mapping, set-oriented cache and row before request matching.

Bind Vonage source evidence to one inbound request

Pair the configured Vonage URI and current service-address evidence with the observed request source and endpoint match using the Vonage inbound diagnostic.

CarrierX endpoint delivery still needs a PBX match

A provider attempt to the configured endpoint does not prove Asterisk selected the intended endpoint and context. Correlate both sides with the CarrierX diagnostic.