Asterisk PJSIPRegister and PJSIPUnregister: runtime control with state proof

Start from a completed inventory

Run PJSIPShowRegistrationsOutbound and retain the response, every OutboundRegistrationDetail and associated AuthDetail, then OutboundRegistrationDetailComplete. Match exact ObjectName, client and server URIs, transport, proxy, auth reference, status and NextReg.

A partial list or GUI label is not a safe control target. The registration object is separate from endpoint, AoR, identify, inbound route and provider account state.

Use one exact object and avoid *all by default

Both runtime actions accept a registration object name or *all. Treat *all as a fleet-wide control with a wider outage, registrar-traffic and evidence surface. Freeze target, operator, reason, maintenance window, correlation value and rollback before sending.

If the exact object is absent, resolve configuration ownership and loading rather than guessing from a trunk label, username or server URI.

Do not hide the PJSIPUnregister documentation conflict

The current action reference says PJSIPUnregister stops future attempts and directs callers to PJSIPRegister to restart them. The current outbound-registration guide says a manually unregistered object later re-registers from its last expiration. The installed version and exact control surface decide the operational result.

Observe beyond the previous refresh boundary. An accepted action does not prove remote binding removal, and neither statement is presented as universal across uninspected releases.

Treat PJSIPRegister as a state transition

PJSIPRegister unregisters the selected object first, then starts registration and schedules later attempts according to loaded configuration. Preserve both phases, their SIP responses and the effect of retry, expiration, authentication and fatal-failure controls.

Do not use repeated register actions as a polling loop or workaround for a rejected configuration. They can add provider traffic while leaving the underlying object unchanged.

Correlate response, Registry event and fresh state

Record the immediate AMI response separately from later Registry events and a new completed outbound-registration inventory. Retain Registered, Unregistered, Rejected and Failed event values without flattening them into the detail event’s smaller vocabulary.

A manager reconnect can miss an event, while an event can precede another state change. The fresh list, NextReg, bounded packet evidence and observation through the next refresh close different gaps.

Prove restoration without calling registration a call test

After the intended transition, confirm the exact object, observe at least one scheduled refresh and verify unrelated registrations were unchanged. Correct persistent configuration in its authoritative owner rather than automating recovery around a bad object.

Provider binding, inbound DID routing, outbound authorization, SDP, RTP and hangup remain separate tests. No PBX, manager session, registration object, provider binding, packet, media stream or live call was inspected or tested.

Re-list after each bounded runtime control

The AMI list diagnostic requires a fresh completed inventory after a scoped control.