VoIP.info Guide

Asterisk AMI PJSIP contact lists, status events and qualification evidence

Separate completed contact snapshots, dynamic-registration detail, asynchronous state changes and requested qualification without turning any one surface into proof of a working call.

Reviewed 2026-10-19Current branch-23 PJSIPShowContacts, ContactList, ContactListComplete, ContactStatus, ContactStatusDetail, PJSIPShowRegistrationInboundContactStatuses, PJSIPQualify, PJSIP_CONTACT and res_pjsip references plus PJSIP troubleshooting and AMI v2 guidance were reviewed October 19, 2026. Installed branch, loaded modules, manager permissions and filters, configuration owner, contact population, registration lifecycle, qualify exchange and call behavior remain deployment specific. No PBX, module, manager account, session, AoR, endpoint, contact, registration, OPTIONS exchange, packet, media stream or live call was inspected or testedAdvancedDocumentation based · not lab tested

Choose the contact evidence surface before collecting data

PJSIPShowContacts lists every loaded contact known to res_pjsip. PJSIPShowRegistrationInboundContactStatuses lists status detail for dynamic inbound-registration contacts. ContactStatus is an asynchronous change event, while PJSIP_CONTACT(name,field) reads one exact contact field.

Record the responding node, installed branch, manager identity, timestamp, exact AoR, endpoint and contact identifier. Static contacts, dynamic REGISTER-created contacts, status snapshots and change history answer different questions.

Treat ContactList as a timestamped all-contact snapshot

PJSIPShowContacts raises one ContactList row per contact and ends with ContactListComplete. Rows can expose object identity, URI, endpoint, expiration, Via, Call-ID, Path, user agent, qualification policy, current status and last round-trip measurement. Retain complete rows and the terminal event.

The snapshot status vocabulary is Reachable, Unreachable, NonQualified or Unknown. A row is not registration history, an OPTIONS transcript, a future reachability promise or proof that an INVITE and media will succeed.

Keep asynchronous ContactStatus transitions distinct

ContactStatus is raised when a contact state changes and uses Unknown, Unreachable, Reachable, Unqualified, Removed and Updated. Do not flatten NonQualified from a list row into Unqualified from the transition event without retaining the source field and event type.

A missing transition does not prove no change occurred: the observer may have connected late, lacked system-event permission, filtered the event, lost the session or queried another node. The global send_contact_status_on_update_registration option separately controls refresh-update events and defaults to no.

Correlate lists and events without inventing continuity

Give each list action a unique ActionID; retain the immediate response, every row and ContactListComplete, then reconcile ListItems. The AMI v2 specification defines list completion and cancellation and places correlation responsibility on the client. Socket silence, timeout or an arbitrary row count is not completion.

Build history only from observed, timestamped events plus periodic completed snapshots. A current row cannot reconstruct missed transitions, and a transition event cannot enumerate contacts that never changed during the observation window.

Interpret qualification policy and explicit qualify requests precisely

qualify_frequency=0 means do not periodically qualify; qualify_timeout includes time spent on required DNS lookups; qualify_2xx_only changes which OPTIONS responses count as available. The stored RoundtripUsec is the last reported measurement, not continuous latency.

PJSIPQualify targets an endpoint. An accepted AMI action proves only that the request was accepted. Preserve the subsequent contact transition, a new completed contact snapshot and—when authorized—signaling evidence before concluding that a particular contact answered.

Protect registration metadata and test service separately

Contact URI, Via address and port, Call-ID, Path, user agent, proxy and endpoint relationships can expose topology and device information. Apply least privilege, manager event filtering, secure transport, redaction and bounded retention.

For service acceptance, trace endpoint selection, chosen contact, INVITE, response, SDP and RTP independently. Reachable qualification is not proof of ringing, answer, codec agreement or two-way audio. No PBX, module, manager account, session, AoR, endpoint, contact, registration, OPTIONS exchange, packet, media stream or live call was inspected or tested.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.