VoIP.info Guide

Asterisk AMI PJSIP outbound-registration inventory: completion, state and secret boundaries

Collect the complete outbound-registration event list, preserve each status vocabulary and prevent associated authentication secrets from escaping.

Reviewed 2026-10-27Current Asterisk branch-23 PJSIPShowRegistrationsOutbound, OutboundRegistrationDetail, AuthDetail, PJSIPRegister, PJSIPUnregister, Registry and outbound-registration documentation was reviewed October 23, 2026. The action page and configuration guide still differ on post-unregister scheduling, so installed-branch behavior must be observed. No PBX, module, manager account, session, registration object, auth object, credential, event stream, SIP exchange, DNS answer, timer, provider binding, packet, media stream or live call was inspected or testedAdvancedDocumentation based · not lab tested

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.

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