Asterisk AMI PJSIP AoR lists, contact policy and exact inspection

Define the AoR question before collecting rows

PJSIPShowAors lists every loaded PJSIP Address of Record. Use it for inventory, configuration comparison and finding an exact object name. Record the responding node, installed branch, configuration owner, manager identity, timestamp and the specific mismatch you are investigating.

An AoR groups locations where an endpoint may be contacted. It is not the endpoint policy object, a registration transaction, a contact qualification result or an outbound-registration object. Similar names do not prove association.

Treat AorList as a configuration-and-summary row

For each AoR, PJSIPShowAors raises AorList and ends with AorListComplete. The row can include expiration policy, qualification options, MaxContacts, replacement controls, mailbox and proxy fields, support for Path, and associated contact text. Retain the entire row and exact object name.

The contact field is a current summary, not a historical ledger or full contact-object record. MaxContacts limits contacts added through external interaction; it does not cap static contact= entries.

Use the correct exact-object surface

AMI does not document a separate single-AoR action beside PJSIPShowAors. PJSIPShowEndpoint can emit AorDetail for each AoR associated with one exact endpoint. PJSIP_AOR(name,field) reads a documented AoR configuration field, while PJSIP_CONTACT(name,field) reads one exact contact object.

Choose the surface that answers the question. Endpoint-associated detail can omit an unassociated AoR; a dialplan function read is not an AMI list; contact detail does not establish which endpoint will select it.

Correlate completion, count and changing contact state

Retain a unique ActionID, the immediate response, every AorList row and AorListComplete. Compare ListItems with the retained rows after accounting for parser rules. A timeout, quiet socket, disconnect or guessed count does not prove completion.

Contact state can change immediately through REGISTER refresh, de-registration, expiry, replacement policy, static configuration, reload or another node. Preserve timestamps and do not merge overlapping list transactions by arrival order.

Interpret max_contacts and replacement controls precisely

max_contacts, remove_existing and remove_unavailable interact. The current res_pjsip reference says max_contacts applies to contacts added through external interaction, while replacement controls determine whether and which existing contacts are removed when a new registration would exceed the limit.

Expiration, qualification frequency, timeout and qualify_2xx_only describe different policies. A loaded value does not prove a REGISTER was accepted, an OPTIONS exchange completed or a call reached the intended device.

Protect topology and test downstream service separately

AoR names, contact URIs, proxy values, mailbox associations, Path information and object relationships can expose operational topology. Restrict AMI network access and privileges, redact secrets, bound retention and avoid exporting inventories into broad dashboards without a need.

For service acceptance, trace endpoint selection, authentication, AoR and contact choice, signaling, SDP and media independently. No PBX, module, manager account, session, AoR, endpoint, contact, registration, REGISTER transaction, qualification exchange, channel, packet, media stream or live call was inspected or tested.

Follow AoR contact summaries into the all-contact inventory

The AMI contact-evidence guide compares compact AoR contact text with complete contact rows, exact fields and change events.