Registration flapping is when a SIP phone or trunk re-registers far more often than it should, often every few seconds. The phone may appear online momentarily then go offline, with users seeing “available” flicker on and off. The cause is almost always a mismatch between Expires negotiation, NAT timeout, or authentication state.
SIP registration is how endpoints tell a registrar where they can be reached. The endpoint sends a REGISTER request with its Contact URI and an Expires value indicating how long the binding should be valid. The registrar accepts (200 OK), rejects (4xx), or challenges (401) the registration.
Bindings expire on the registrar after the Expires interval. The endpoint must re-register before that to keep the binding alive. Most phones default to re-registering at 80 to 90 percent of the Expires interval to leave headroom for retries.
A healthy registration is steady: one refresh per Expires cycle, with predictable timing. Anything more frequent than that is anomalous.
Two distinct patterns get called “registration problems”:
The phone successfully registers, then within a short time (seconds to a minute) sends another REGISTER, succeeds, then sends another. The pattern repeats indefinitely. Each registration succeeds individually — the issue is frequency.
The phone sends REGISTER, gets 401, sends REGISTER with auth, gets 401 again, retries, gets 401 again. Authentication never succeeds. The phone is stuck in a loop trying to authenticate. See the SIP 401 Unauthorized guide for the auth-loop scenario.
Both produce similar symptoms (phone appears unstable in the dashboard) but require different fixes. Flapping is a timer or NAT issue. Looping is an auth issue.
The Expires header in REGISTER is a negotiation, not a demand. The phone proposes a value; the registrar can accept it, reduce it, or reject it as too low.
Registrar returns 200 OK with the same Expires value (or a per-Contact Expires parameter on the Contact header). The phone refreshes at ~90% of that value.
Registrar returns 200 OK with a lower Expires value. This is allowed under RFC 3261. The phone honors the lower value, leading to more frequent refreshes than the phone wanted. If the registrar's setting is too aggressive, this manifests as flapping.
Registrar returns 423 Interval Too Brief with a Min-Expires header indicating the minimum acceptable value. The phone should retry REGISTER with Expires set to or above Min-Expires. Some phones loop here if they do not parse Min-Expires correctly.
For trunk registrations to a carrier: Expires of 600 to 3600 seconds is typical. Carriers usually accept up to 3600. For phones to a local PBX: 3600 is fine if the network is stable; lower (300 to 600) is better if NAT keepalive matters and the phone does not send dedicated keepalive packets.
UDP NAT mappings expire after a period of inactivity. To keep the registration path open, something must traverse the NAT regularly. There are three common approaches:
Set the registration Expires below the NAT timeout. If the NAT closes UDP mappings after 60 seconds, registering every 30 seconds keeps the path open. This works but creates registrar load and looks like flapping if you do not know it is intentional.
Most modern phones send small keepalive packets (CRLF, double CRLF, or empty UDP packets) at a configurable interval — typically 25 to 30 seconds. This keeps the NAT mapping open without re-registering. Yealink, Polycom, Cisco, Grandstream, and Snom all support this. Combined with longer registration intervals (3600), this is the cleanest pattern.
The PBX or registrar sends OPTIONS to the phone's last-known Contact at a regular interval. If the OPTIONS is replied to, the path is alive and the binding is kept fresh implicitly. Asterisk and FreeSWITCH both support this. See the SIP OPTIONS keepalive guide for setup.
The signal in registration traces is in the timing and the Expires negotiation:
Registration flapping is usually caused by the registrar reducing the Expires value to something much shorter than the phone requested, NAT keepalive being implemented as frequent re-registration instead of dedicated keepalive packets, or SIP ALG on a firewall rewriting the Contact header inconsistently. The phone keeps re-registering to fix what it sees as a broken or expiring binding.
Flapping is when each registration succeeds, but the phone re-registers far more often than the Expires value would suggest. It is a timing or NAT issue. A registration loop is when registration repeatedly fails — the phone sends REGISTER, gets 401, retries with auth, gets 401 again, and never succeeds. That is an authentication issue.
A phone should re-register at approximately 90 percent of the negotiated Expires interval. For Expires: 3600 (one hour), the refresh happens around every 54 minutes. Re-registering every few seconds is flapping, not normal behavior. NAT keepalive should be handled by dedicated keepalive packets at 25 to 30 second intervals, not by short registration cycles.
Paste your SIP trace into SIPSymposium. The analyzer detects Expires negotiation issues, Contact rewrites, NAT keepalive timing, and the patterns that produce registration flapping.