SIP Timers and Extension Re-Registration: A Field Guide

SIP Timers and Extension Re-Registration: A Field Guide

An extension that has mysteriously stopped receiving calls is one of the most common problems in VoIP support, and it usually has nothing to do with the phone. In SIP, an endpoint is reachable because it registered with the registrar and refreshed that registration before it expired. When the refresh stops or is rejected, the extension becomes unreachable even though the device is powered on, connected to the network, and apparently healthy. The timers involved are simple to describe and easy to misconfigure, and their values are rarely reviewed after installation. Understanding how registration expiry, endpoint refresh behaviour, retry intervals, and NAT binding timeouts interact explains most registration faults, and it also explains why a change in one timer can produce symptoms that look unrelated to it.

The Four Timers That Matter

Four values govern whether an endpoint stays registered. The registrar assigns an expiry when the registration is accepted, telling the endpoint how long the registration remains valid. The endpoint chooses when to refresh, normally as a fraction of that expiry so the refresh arrives comfortably before expiry. If the refresh fails, the endpoint retries according to its own retry interval, and when the retries are exhausted the endpoint may continue retrying at a slower rate. Alongside these, the NAT binding timeout on a router determines how long the mapping that allows inbound traffic to reach the endpoint survives without outbound traffic.

Why Registration Failures Look Like Other Problems

A common symptom is one-way audio on inbound calls only: the caller hears the called party, but the called party hears nothing. This pattern frequently appears when the mapping between the internal address and the external address seen by the far end is no longer valid. The outbound refresh traffic keeps the mapping alive, so the failure appears only when the endpoint stops sending traffic — after quiet hours, a weekend, or a suspension. Once the mapping expires, inbound RTP cannot reach the endpoint, even though the call is signalled successfully.

Other common symptoms include an extension that re-registers every few minutes under load because the registrar is rejecting some refreshes, an endpoint that shows as registered yet cannot be called because the route points somewhere stale, and a device that never returns after a power cut because its retry behaviour requires a reachable registrar. Each of these has a timer explanation, and each resolves once the relevant timer is identified.

Designing Timer Settings for Real Deployments

Timer settings should follow the constraints of the deployment rather than defaults from a vendor. The key relationships are straightforward. The endpoint's refresh must comfortably precede expiry, leaving room for a failed attempt and a retry. The retry interval must be short enough that recovery after a brief network interruption is fast, but not so short that a widespread outage produces a registration storm across the whole estate. The NAT binding timeout must be at least as long as the longest plausible interval between outbound packets, which for an idle endpoint is the refresh interval itself.

Where the endpoint sits behind a carrier-grade or enterprise NAT, the registrar may also send unsolicited keepalives specifically to maintain the mapping. Whether this is required, and at what interval, depends on the network. The practical approach is to observe the actual traffic rather than to infer: a packet capture across a maintained call will show exactly which packets keep a mapping alive and how often they are sent.

• Confirm the expiry the registrar assigns rather than assuming the configured value is applied
• Verify the endpoint refresh interval leaves room for one failed attempt and a retry
• Align NAT binding timeouts so they outlive the longest idle period on the endpoint
• Check whether unsolicited keepalives are in use and whether they are sufficient for your network
• Review retry behaviour under a planned outage to confirm recovery time is acceptable
• Re-test after any router, firewall, or NAT device replacement, since defaults differ between models

Diagnosing Registration Problems

Redstone Approach

Redstone can support registration design on Redstone REX and RGW series deployments, including advising on how SIP accounts should be configured for the network path in use, and how expiry and refresh behaviour interacts with the systems Redstone provides. Redstone engineers can also help with structured fault-finding when extensions behave inconsistently, by establishing whether the fault lies in the endpoint, the registrar, or the network in between.

Because timer defaults are often inherited from a previous platform or a different network, Redstone recommends that registration settings be reviewed as part of any migration or WAN change, and documented so that a future fault does not restart the diagnosis from scratch.