Treat the response as an event list, not a single record
PJSIPShowRegistrationsOutbound raises one OutboundRegistrationDetail for every loaded outbound-registration object, can raise associated AuthDetail rows, and ends only when OutboundRegistrationDetailComplete arrives. The initial AMI response, one desired detail row or a client timeout is not a complete inventory.
Record the responding node, installed Asterisk branch, manager identity, action timestamp, ActionID and collection deadline. Preserve every event until the terminal event, then filter by exact object name. Do not stop reading because the expected registration appeared early.
Reconcile terminal counts with collected rows
The configuration guide shows a completion event with EventList: Complete plus Registered and NotRegistered counters. Count unique registration detail rows, preserve duplicates rather than silently collapsing them, and compare the row statuses with the terminal aggregates. A missing terminal event makes the snapshot incomplete even when the counts appear plausible.
Keep the ActionID or other explicit request correlation throughout the response. AMI is asynchronous; unrelated events can interleave with the action list, and a shared connection can carry events for other consumers.
Keep detail, aggregate and transition states separate
OutboundRegistrationDetail documents Registered, Unregistered and Rejected. The asynchronous Registry event documents Registered, Unregistered, Rejected and Failed, with an optional cause. The completion event aggregates Registered and NotRegistered, while the configuration guide also discusses a Stopped CLI state.
Preserve producer, original value and timestamp. Do not normalize Rejected, Failed, Stopped, Unregistered and aggregate NotRegistered into one generic offline state; they answer different questions and can describe different moments.
Read NextReg and retry controls narrowly
A detail row exposes the registration object, client and server URIs, transport, proxy, auth reference, retry intervals, expiration, status and NextReg. NextReg is the reported seconds until the next registration at that observation. The configuration guide demonstrates zero after retry exhaustion, so zero is not proof that a REGISTER will be sent immediately.
Compare MaxRetries, RetryInterval, ForbiddenRetryInterval, FatalRetryInterval, AuthRejectionPermanent, expiration and the current state before predicting another attempt. Loaded configuration and runtime timer state remain separate.
Redact associated authentication detail before storage
The action can emit AuthDetail for associated auth objects. The branch-23 schema includes password, MD5 credential, OAuth secret, password digest and refresh token fields. Treat the raw event stream as secret-bearing even when the intended report needs only object identity, username, realm or supported algorithms.
Redact at collection before logs, tickets, metrics, traces or analytics receive the data. Do not publish placeholder length, hashes or partial tokens as proof of equality; use a controlled secret-management comparison outside the shared evidence record.
Correlate inventory, transitions, signaling and calls independently
PJSIPRegister first unregisters the selected object and then starts registration from loaded configuration. The current PJSIPUnregister action page says future attempts stop until registration is started again, while the configuration guide says a manually unregistered object can re-register from its prior expiration; preserve that unresolved documentation conflict.
For one authorized object, retain action response, Registry transition, bounded SIP exchange, fresh completed inventory and observation beyond the prior refresh boundary. None alone proves provider binding, inbound routing, outbound authorization or usable media. No live PBX or registration was tested for this review.
Keep legacy registry and PJSIP registration evidence separate
The AMI chan_sip migration guide does not equate a SIPshowregistry row with a current PJSIP registration object.
Keep PJSIP and IAX2 registration models distinct
The IAX2 AMI evidence guide avoids importing endpoint, AoR or contact semantics into IAXregistry.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk 23 PJSIPShowRegistrationsOutbound action ↗
- Asterisk 23 OutboundRegistrationDetail event ↗
- Asterisk 23 AuthDetail event ↗
- Asterisk 23 PJSIPRegister action ↗
- Asterisk 23 PJSIPUnregister action ↗
- Asterisk 23 Registry event ↗
- Asterisk 23 outbound-registration configuration reference ↗
- Asterisk outbound-registration configuration guide ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk AMI v2 specification ↗
- Asterisk Manager TCP/IP API ↗
- Asterisk 20 SIPpeers AMI action ↗
- Asterisk 20 SIPshowpeer AMI action ↗
- Asterisk 20 SIPpeerstatus AMI action ↗
- Asterisk 20 SIPshowregistry AMI action ↗
- Asterisk chan_sip configuration status ↗
- Asterisk 21 changes ↗
- Asterisk module deprecations ↗
- Asterisk chan_sip to res_pjsip migration ↗
- Asterisk PJSIPShowEndpoints AMI action ↗
- Asterisk ListCommands AMI action ↗
- Asterisk network security guidance ↗
- Asterisk current IAXpeers AMI action ↗
- Asterisk current IAXpeerlist AMI action ↗
- Asterisk current IAXregistry AMI action ↗
- Asterisk current IAXnetstats AMI action ↗
- Asterisk 22 IAXpeers AMI action ↗
- Asterisk 22 IAXpeerlist AMI action ↗
- Asterisk 22 IAXregistry AMI action ↗
- Asterisk 22 IAXnetstats AMI action ↗
- Asterisk IAX2 security guidance ↗
- Asterisk iax.conf sample ↗
- Asterisk chan_iax2 implementation source ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.