SIP Registration Expiry Explained Why Phones Disappeared After a While

A phone that registers successfully and then becomes unreachable later is a different problem from a phone that never registers at all. The first REGISTER proved that credentials, signaling reachability and at least one transaction worked. The later disappearance made more sense once I paid attention to registration expiry and the fact that the registrar is storing temporary location state, not a permanent association.

A SIP endpoint tells the registrar where it can be contacted and normally includes an expiry interval. Before that interval ends, the endpoint refreshes the registration. If the refresh never arrives, the registrar eventually removes the contact. Looking at the registration table over time is therefore more informative than checking it once immediately after boot. A contact that repeatedly appears and expires can point toward endpoint timing, connectivity or NAT state rather than a simple password problem.

NAT adds another timer to the picture. A router may remove an idle UDP mapping before the SIP registration itself expires. The registrar still has a contact that appears valid, but an inbound request toward the old public source port may no longer reach the phone. Shorter refresh intervals, SIP keepalive mechanisms, CRLF keepalives or other NAT-aware behavior can help maintain reachability depending on the endpoint and network. The exact mechanism varies, but the principle is that application state and NAT state have separate lifetimes.

This also explained why a phone could place outbound calls while incoming calls failed after being idle. An outbound request creates fresh NAT state, so signaling from the phone reaches the server and the server can respond along that mapping. Before the outbound activity, the stored contact may have pointed toward a mapping that no longer existed. The symptom looked asymmetric because the first packet originated from different sides.

The practical check became temporal rather than static: watch the REGISTER sequence, record the expiry value, see when the endpoint refreshes, and compare that with NAT behavior and the registrar's contact table. A registration line marked 'OK' is only a snapshot. Reachability depends on that state being refreshed before both the SIP registration and the underlying network mapping become stale.