Asterisk PJSIP endpoint inspection: configuration fields, channel identity and proof

Treat the endpoint as a configuration profile

The res_pjsip endpoint is the primary SIP behavior profile. It can associate authentication, AoR and transport objects and contains policy for context, codecs, identity, media, timers, subscriptions, fax and other behavior. It is not a dialable location by itself; an AoR and one or more contacts provide destination information.

Preserve the endpoint name, configuration backend and collection time. A section with a similar name, a registered contact or a caller-provided SIP user does not by itself prove which endpoint object was selected.

Query one supported endpoint field at a time

PJSIP_ENDPOINT(name,field) reads a supported option from the named endpoint object. The function is documented since Asterisk 12.0.0. Useful fields include aors, auth, context, allow, codec preferences, dtmf_mode, direct_media, identify_by, transport, identity-trust settings and media-encryption policy.

Choose a field that answers one question and retain the exact name and value. An endpoint lookup is configuration evidence; it does not show the resolved contact, emitted request, negotiated codec, received media, authenticated identity or final call result.

Start a live-channel lookup from CHANNEL(endpoint)

On a PJSIP channel, CHANNEL(endpoint) returns the name of the endpoint associated with that channel. Pass that exact value into PJSIP_ENDPOINT() when the decision concerns the current leg. CHANNEL(contact) and CHANNEL(aor) are separate values and may be absent; the documentation notes that those two are only available on outgoing legs when present.

A caller leg and each callee leg can therefore lead to different endpoint objects. Run the lookup on the channel that owns the behavior under investigation instead of inferring an endpoint from caller ID, dialed digits, display text or a sibling channel.

Separate identification from endpoint policy

Inbound SIP must first be matched to an endpoint. Identification can use user, IP, anonymous or other loaded identifier modules and their configured order. A successful match selects the endpoint profile; it does not prove authentication, authorization, AoR ownership or that the presented identity is trustworthy.

Record the SIP request evidence and the selected endpoint separately. When matching is disputed, compare the relevant From user, source address or identify object with loaded runtime state before changing the endpoint field being inspected.

Keep configured values, defaults and session results distinct

Some endpoint fields can be omitted and resolved through documented defaults. For example, an endpoint without an explicit transport uses the first compatible configured transport for the target URI. An empty explicit field is therefore not automatically the same as no runtime selection.

Similarly, allow, media_encryption, direct_media, dtmf_mode and identity options express policy. Preserve the outbound request, SDP, response, channel formats and media observations before claiming what one session actually used.

Log bounded evidence and repeat the same leg

Capture the endpoint name and only the fields needed for the diagnosis. Avoid dumping authentication material, unrestricted ACLs, certificate paths or an entire configuration object into general logs. Correlate the same channel unique ID and SIP Call-ID when protocol evidence is required.

Test one known endpoint, an intentionally absent endpoint, an inbound leg and an outbound leg. This guide is documentation-derived; no Asterisk instance, endpoint, channel or call was tested.

[inspect-current-endpoint]
exten => 701,1,Set(EP_NAME=${CHANNEL(endpoint)})
 same => n,Set(EP_AORS=${PJSIP_ENDPOINT(${EP_NAME},aors)})
 same => n,Set(EP_CONTEXT=${PJSIP_ENDPOINT(${EP_NAME},context)})
 same => n,NoOp(Current PJSIP endpoint metadata collected for bounded diagnostics)
 same => n,Hangup()

Separate endpoint dtmf_mode from the current channel value

The PJSIP_DTMF_MODE guide follows the endpoint field into one caller or callee leg and then verifies the actual digit method and consumer.

Keep allow_transfer separate from per-channel ownership

The PJSIP transfer-handling guide distinguishes endpoint transfer permission from the runtime decision to use core or ARI-only handling.

Do not confuse an endpoint label with one NOTIFY destination

The PJSIP NOTIFY diagnostic uses loaded endpoint, contact and emitted-request evidence to identify where one message actually went.

Bind endpoint inspection to the channel that selected it

The PJSIP channel-context guide pairs CHANNEL(endpoint) with the same leg's dialog, target and socket evidence instead of treating an endpoint name as a URI or destination.

Do not infer endpoint health from scrape success

The Prometheus metrics guide keeps route availability and metric-provider output separate from the endpoint, AoR, contact and call evidence shown by live PJSIP inspection.

Identify the source that supplied the endpoint object

The PJSIP Realtime diagnostic compares Sorcery mapping order, backend row, cache and CLI object before diagnosing endpoint behavior.

Add maintenance state to endpoint inspection

The PJSIP maintenance-mode guide adds exact-endpoint status without substituting it for registrations, contacts or transport evidence.

Inspect the endpoint-to-AoR scope before PJSIPQualify

The AMI PJSIPQualify guide shows why an endpoint name and individual contact results are not interchangeable.

Do not infer message rendering from endpoint existence

The AMI SendText diagnostic follows one live channel through protocol response and endpoint presentation.

Resolve the endpoint behind an out-of-call message

The AMI MessageSend diagnostic records the endpoint before following AoR, contact and Request-URI.