Freeze a completed state snapshot
Collect the full PJSIPShowRegistrationsOutbound transaction through OutboundRegistrationDetailComplete. Match the exact object, client and server URIs, transport, proxy, auth reference, status, NextReg, retry controls and completion counters. Redact protected auth material.
If the object is absent, investigate configuration ownership, syntax, URI validation and loading. A partial list, dashboard label or missed event is not a completed empty or stopped state.
Preserve the producing status vocabulary
OutboundRegistrationDetail documents Registered, Unregistered and Rejected. The CLI guide also describes Stopped. Registry can report Registered, Unregistered, Rejected or Failed, while the list-complete event counts Registered and NotRegistered.
Do not collapse these into one offline label. Record the source, timestamp and exact value, then correlate the latest state with the last bounded SIP exchange.
Classify temporary, authentication and fatal responses
The outbound-registration guide treats no response, 408, 500, 502, 503, 504 and 600-class responses as temporary. Loaded retry interval and maximum retry count govern later attempts. Authentication rejection, 403 and other fatal responses have separate controls.
Do not loosen intervals merely to create visible traffic. First confirm registrar identity, realm, credentials, account state and response policy; repeated errors can hide a durable fault or trigger upstream protection.
Interpret NextReg with the retry history
NextReg is a point-in-time countdown reported for the loaded object. The Asterisk example shows zero after registrations reached their maximum retry count. Zero is therefore not proof of an immediate attempt, a disabled scheduler or a particular failure cause.
Preserve the last response, retry count, control action, configuration reload, DNS and connection observations. A changed DNS answer alone does not restart a stopped state or close an existing transport.
Use runtime control only after finding the first divergence
PJSIPRegister restarts a loaded object by unregistering first and scheduling from current configuration. PJSIPUnregister has conflicting current documentation about later attempts, so confirm installed behavior and observe beyond the prior refresh boundary.
Do not use *all or a repeated action loop to compensate for a malformed URI, wrong proxy, rejected credentials, exhausted retries or a configuration owner that will regenerate the fault.
Verify registration and calls as separate outcomes
After correction, preserve a new REGISTER exchange, accepted expiration, completed state snapshot and at least one scheduled renewal. Then test inbound routing and outbound calling independently when authorized, including media and release.
A Registered value establishes neither the provider’s DID route nor dialplan, caller identity, codec, RTP or hangup success. No PBX, registration, provider binding, packet, media stream or live call was inspected or tested.
Read stopped behavior against retry and NextReg evidence
The AMI inventory guide preserves the unresolved unregister scheduling conflict and installed-branch evidence.
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 ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.