Asterisk PJSIP AoR and contact inspection: identity, fields and runtime evidence

Keep endpoint, AoR and contact objects separate

An endpoint is the SIP behavior profile. An Address of Record tells Asterisk where that endpoint may be contacted and can contain one or more contact objects. A contact represents one routable SIP URI and associated runtime fields. These names may look similar, but they are not interchangeable.

Start with the endpoint, record the exact aors value, then inspect each named AoR and its contacts. A loaded endpoint does not prove an AoR loaded, and a loaded AoR does not prove a contact currently exists.

Read AoR configuration and contact identifiers deliberately

PJSIP_AOR(name,field) reads a supported field from one named AoR. The contact field is special: it returns permanent and dynamic contacts as one or more comma-separated internal contact identifiers. Those identifiers are inputs for PJSIP_CONTACT(); they are not themselves SIP URIs or dial strings.

Preserve the complete returned list before splitting it. An empty contact field is different from a missing AoR, a misspelled name or an endpoint that references another AoR.

Resolve each contact identifier to the required field

PJSIP_CONTACT(name,field) accepts the internal contact identifier and can expose fields such as URI, expiration time, Path, User-Agent, endpoint, registration server, last Via address and port, Call-ID, status and last qualify RTT. Query only the field needed for the decision and retain the contact identifier beside the result.

Status and RTT describe qualification evidence, not call success, speech quality or registration validity. A URI describes the stored destination; it does not prove that a new SIP request reached or was accepted by that device.

Distinguish permanent and dynamic contact lifecycle

A static contact= URI on an AoR creates a contact from configuration. A registrar-created contact follows an accepted inbound REGISTER and its expiry, replacement and removal rules. max_contacts, remove_existing, remove_unavailable, expiration limits and registrar state can therefore change which identifiers are present.

Record whether each contact is permanent or dynamic, its source, expiry evidence and collection time. A value captured before reload, re-registration or network change should not be represented as current later.

Do not substitute inspection for dialing behavior

PJSIP_DIAL_CONTACTS() builds a dial string from contacts currently available for an AoR or endpoint. PJSIP_AOR() and PJSIP_CONTACT() inspect object fields. A non-empty inspection result does not prove the generated dial string, channel creation, parallel attempt, answer or bridge outcome.

When routing is the problem, preserve inspection output, the generated dial string and the resulting outbound channels as separate evidence. Qualification can affect reachability decisions, but a successful OPTIONS exchange is still not an answered INVITE.

Log bounded metadata and recheck the same object

Use the narrowest useful fields, redact user and network identifiers when records leave the PBX, and avoid logging credentials or an unrestricted contact inventory. Correlate the same AoR and contact identifier with CLI output and one bounded signaling trace when protocol evidence is required.

Test one expected contact, a multi-contact AoR, an expired or removed registration and a misspelled object name. This guide is documentation-derived; no Asterisk instance, object, contact or call was tested.

[inspect-contact]
exten => 700,1,Set(CONTACT_IDS=${PJSIP_AOR(700,contact)})
 same => n,Set(FIRST_ID=${CUT(CONTACT_IDS,,1)})
 same => n,Set(FIRST_URI=${PJSIP_CONTACT(${FIRST_ID},uri)})
 same => n,NoOp(AoR 700 first contact ID and URI collected for bounded diagnostics)
 same => n,Hangup()

Start the object chain with the exact endpoint field

The PJSIP endpoint inspection guide adds the loaded endpoint and current channel association before the AoR and contact identifiers already inspected here.

Add completed AMI inventories to contact inspection

The AMI inbound-registration diagnostic correlates AoR, URI, contact ID, expiry and completion boundaries.

Correlate contact inspection with exact endpoint detail

The AMI endpoint-state diagnostic reconciles the endpoint list, associated AoR detail and current contacts.