Compare the requested expiry with Min-Expires
A registrar can return 423 when a requested binding expiration is too short. Min-Expires states the minimum it will accept. RFC 3261 permits retry with contact expiration intervals at least that large.
Record the REGISTER, the exact response and the next attempt. Check the Contact-specific expiration as well as the request-level Expires value. A phone’s settings screen is useful context, but the sent request shows what was actually proposed.
Check why the rejected value persists
If the same short value keeps returning, inspect the authoritative provisioning template and the phone’s effective configuration. A local adjustment may be overwritten at the next refresh or restart. Compare another endpoint only if it uses the same registrar policy and firmware behavior.
Do not substitute a generic large number copied from an unrelated provider. Confirm the supported policy with the registrar or trunk documentation. If the response does not provide usable minimum information, preserve it for an interoperability investigation rather than claiming a successful negotiation.
Verify the binding through its lifecycle
After registration succeeds, inspect the expiration granted for the matching contact in the response. Observe a later refresh and place an inbound call after idle time. This checks whether the usable binding persists instead of merely clearing the first error.
If the phone still alternates between registered and unavailable, continue with the registration-loop investigation. Keep session-timer settings separate: 422 uses Min-SE for session intervals and requires a different diagnosis.
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.