Asterisk outbound registration stopped retrying

Classify the last known state

Run pjsip show registrations and identify the exact outbound registration object, server URI and status. If the object is absent, investigate loading, syntax and URI errors before changing retry values. If it is present, align the status with a bounded signaling trace and the timestamp of the last attempt.

A missing REGISTER, a REGISTER with no response and a final rejection are different incidents. Preserve the registrar response and Asterisk log message; a dashboard label alone cannot show which branch occurred.

Read temporary and permanent failures differently

Asterisk documents no response, 408, 500, 502, 503, 504 and 600-class responses as temporary outbound-registration failures. Those failures may use retry_interval until max_retries is reached. The Asterisk 22 module reference documents defaults of 60 seconds and 10 attempts, but confirm the loaded object rather than assuming an example or default is active.

Other responses are normally treated as permanent. A stopped retry loop can therefore be designed behavior, not proof that the scheduler or network failed.

Do not turn rejection into traffic

The auth_rejection_permanent option controls whether failed 401 or 407 authentication challenges are permanent; the documented default is enabled. forbidden_retry_interval can permit later attempts after a 403, and fatal_retry_interval can permit retries after other fatal responses. Both intervals default to zero in the Asterisk 22 module reference.

Do not enable or shorten these intervals merely to make attempts visible. First confirm the carrier identity, realm, credential, account state and response policy. Repeated authentication or forbidden requests can hide a durable configuration error and may trigger upstream protection.

Correct one demonstrated cause

For an unloaded object, correct the reported configuration error or malformed server_uri or client_uri. For a timeout, verify name resolution, the intended registrar address, transport and firewall path. For a rejection, compare the complete challenge and response with the carrier’s current instructions while keeping secrets out of shared traces.

Plan activation through the configuration owner. On a FreePBX-managed system, use its supported trunk and Apply Config workflow rather than editing generated files. On standalone Asterisk, use the documented reload or restart procedure appropriate to the changed object and the installed version.

Verify recovery beyond Registered

After the controlled activation, confirm a new REGISTER exchange, the accepted expiration and at least one renewal. Then test inbound delivery and outbound calling separately, including two-way audio and hangup. Registration establishes a binding relationship with the registrar; it does not prove dialplan selection, caller identity authorization, destination permission or media delivery.

Record the observed retry timing and final status. Restore temporary protocol logging and any deliberately altered retry setting to the approved operating baseline when the investigation ends.

Check DNS without confusing TTL and retry state

When DNS now points to a healthy target but registration remains Stopped or uses an older path, follow the PJSIP DNS-change diagnostic. It records resolver answers, connection reuse, last response, retry limit and next attempt separately.

Use PJSIPRegister only after proving why retries stopped

The AMI action diagnostic checks object identity, persistent retry configuration, registrar response and NextReg before restarting one registration.