Troubleshooting · Symptoms
Phones Not Registering: Diagnosing REGISTER Failures
A phone that cannot register is a paperweight: no dial tone service, no inbound calls, a sad icon on the screen. Registration is SIP's simplest transaction — the phone sends REGISTER, the server challenges it (401), the phone answers with credentials, the server accepts (200 OK). When it fails, the failure happens at exactly one of those steps, and a capture or the server's response code tells you which.
Resist the urge to factory-reset first. Registration faults are overwhelmingly configuration, credentials or network reachability — in that order — and a reset usually just erases the evidence.
The four failure shapes
| What happens | Meaning | First checks |
|---|---|---|
| REGISTER sent, no response at all | Packets aren't reaching the server, or replies aren't returning | Server address/DNS, port (5060 UDP/TCP, 5061 TLS), firewall egress, ISP blocking SIP, wrong transport |
| 401 challenge, phone retries, still 401 (loop) | Server challenges but never accepts the answer | Wrong password/secret, wrong auth username vs extension, digest realm mismatch, time skew on TLS |
| 403 Forbidden | Server refuses this registration outright | Account disabled, MAC/extension not provisioned, IP ACL on the server, registration from an unapproved location |
| Registers, then drops and re-registers (flapping) | Registration succeeds but expires or is torn down | Expires value vs NAT UDP timeout, SIP ALG rewriting Contact, multiple devices fighting over one extension |
The address in the Contact header
When a phone behind NAT registers, its Contact header carries its private address unless something fixes it. A server that stores that literal Contact will send inbound INVITEs to an unroutable address — the phone shows 'registered' yet calls go to voicemail or fail, a sibling fault covered in the voicemail guide. Healthy setups fix this at the server/SBC (which notes the actual source address) or via the phone's NAT settings. When registration 'works' but inbound doesn't, compare the Contact the phone sent against the address the server recorded; the capture at the network edge shows both.
Phone --- REGISTER ----------> Server Phone <-- 401 Unauthorized ---- Server (challenge: normal) Phone --- REGISTER + Auth ---> Server Phone <-- 200 OK -------------- Server (registered; Expires: 3600) # A healthy exchange. Your capture will stop at one of these lines; # where it stops is the diagnosis.
Diagnosis sequence
- Scope it: one phone, one site, or everyone? Everyone-down after a change points at network/server; one phone points at that device or its credentials.
- Read the phone's status screen for the exact SIP response it last received (many display it) — 403 vs timeout are different universes.
- Verify the basics against the provisioning record: server hostname (resolve it — DNS failures look exactly like server failures), port and transport (UDP vs TCP vs TLS must match the account), extension and auth ID, and the secret, re-typed rather than assumed.
- Capture the REGISTER exchange at the phone's network segment. Classify with the table: silence, 401 loop, 403, or flapping.
- For silence: test reachability — can the phone's network reach the server IP/port (another device on the same VLAN, a provider status check)? Check firewall egress rules and whether the ISP or a new security appliance blocks SIP.
- For flapping: compare the registration Expires against your NAT UDP timeout; enable the phone's keepalive (or shorten its re-register interval below the timeout) and disable SIP ALG on the path.
- Verify: phone shows registered with a sane expiry countdown, an inbound test call rings it, and it survives past one full registration period without dropping.
Frequently asked questions
- Why did all phones unregister after we changed routers?
- The new router changed the NAT/firewall behavior the registrations depended on — SIP ALG enabled by default, short UDP timeouts, or blocked egress. Compare settings against the old unit before suspecting the provider.
- The phone registers on Wi-Fi at home but not in the office.
- The office network is the variable: VLAN without a route to the server, a firewall policy, or a captive portal. That contrast is the fastest localization you will get — protect it by not changing the phone's config while testing networks.
- Is the 401 response an error?
- The first 401 is not — it is the server's authentication challenge and part of every healthy registration. A 401 that persists after the phone answers with credentials is the failure (wrong secret, wrong auth username, or a digest mismatch). See the 401/407 guide.