Identify which registrar rejected which REGISTER
Capture one complete REGISTER transaction and preserve the direction, request URI, Contact, Expires value, final response and Min-Expires header. SIP 423 means the server rejected a refresh interval as too short; it does not identify a credential, NAT or reachability fault by itself. A normal retry may ask for an interval at least as large as Min-Expires.
First decide whether Asterisk sent the rejected REGISTER to a provider or whether a phone sent it to Asterisk. An outbound registration object makes Asterisk the registering client. A dynamic endpoint AOR makes Asterisk the registrar receiving a phone registration. Those paths use different controls and different owners. Do not change both sides from one status line.
When Asterisk is the registering client
Inspect pjsip show registrations and the matching registration object, then compare its configured expiration with the value on the wire and the registrar's Min-Expires. Asterisk 22 documents a 3600-second default for the registration object, but the loaded value and actual REGISTER are the evidence for this incident. retry_interval and max_retries govern unsuccessful retry policy; they do not replace the requested registration lifetime.
If the same short interval repeats, verify that the intended registration object loaded and that FreePBX generated the expected trunk settings after Apply Config. Align the client request with the provider's documented minimum or support-confirmed account policy. Do not enable a broad fatal-response retry loop as a substitute for correcting an explicit interval mismatch.
When Asterisk is the registrar
Inspect the endpoint's loaded AOR and the rejected phone REGISTER. In Asterisk 22, minimum_expiration is the minimum explicit contact lifetime and defaults to 60 seconds; maximum_expiration defaults to 7200 seconds. These AOR controls apply to dynamic registration contacts, not to a separate outbound-registration object.
Compare the phone's transmitted Contact expiration with the AOR policy. Prefer a supported endpoint refresh setting that honors the server minimum. Lower the AOR minimum only after evaluating registration load, restart bursts, NAT behavior and the effect on every endpoint using that object. A large maximum does not prove a long binding was requested or granted.
Keep the neighboring timers separate
A 423 registration interval is not SIP 422 session-timer negotiation, an OPTIONS qualification interval, an outbound retry delay or a NAT keepalive. It also does not prove that the accepted contact remains reachable for calls. Treat those clocks as separate observations even when their values happen to match.
Use a narrowly timed pjsip set logger on capture only for the failing transaction, because protocol logs can contain identities, addresses and authorization material. Remove or disable temporary logging after the evidence is collected and redact shared extracts.
Prove the correction through a refresh
After one controlled change, capture the next REGISTER and final success response. Record the requested interval, any server-adjusted expiration and the contact shown by the registrar. Observe at least one later refresh rather than stopping at the first 200 response. For a phone registered to Asterisk, place an inbound call after idle time; for a provider registration, test inbound delivery and outbound calling separately.
Restore the prior setting if the expected binding does not remain usable. Document the running Asterisk version, object name, server policy and observed interval without copying credentials or full authorization headers. No PBX, endpoint, carrier, interval, registration or live-call behavior was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: registration retry, Min-Expires and SIP 423 ↗
- Asterisk 22: outbound registration options ↗
- Asterisk 22: PJSIP AOR expiration options ↗
- Asterisk PJSIP troubleshooting guide ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.