SIP Registration Failure: Troubleshooting Guide
A practical order for decoding SIP REGISTER failures: from response codes to credentials, transport and clock.
A SIP terminal that will not register is the most common failure on a fresh install. The server shows no extension and the device loops on 'registering' until the handshake completes.
Registration is a SIP transaction defined by RFC 3261. The endpoint sends REGISTER, the server replies with 401 Unauthorized and a challenge, and the endpoint re-sends with credentials. Reading the responses and trace in the right order shows whether the fault is credentials, transport, clock or certificate.
What the response code already tells you
You do not need to guess: the final response code narrows the cause before you open a config page.
A single 401 Unauthorized is the normal challenge step: the server asks, the endpoint answers with credentials, and registration completes. A 401 that repeats every cycle means the credentials are rejected. 407 Proxy Authentication Required is the proxy variant, pointing at a proxy credential rather than the registrar account.
403 Forbidden means the account is disabled, blocked by an access list, or the source address is not permitted. 404 Not Found means the registrar does not recognise the domain or route. 408 Request Timeout and 503 Service Unavailable point at the network or the server process, not the password.
- 401 once — normal challenge, registration should complete.
- 401 repeating — wrong username, password, realm or algorithm.
- 403 — account disabled, ACL or source address block.
- 404 — wrong domain, realm or registration route.
- 408 / 503 — transport or server process failure.
Credentials and the 401/407 handshake
The REGISTER challenge uses the endpoint's configured credentials. The username, realm, password and algorithm must all match what the server stores, or a repeating 401 results.
Watch the realm. The server proposes a realm in the 401 and the endpoint must echo it exactly; some provisioning systems upper-case or trim it, which breaks the digest. Also confirm the algorithm: MD5 is common, but a server set to SHA-256 rejects MD5 responses with a fresh 401.
407 is easy to misread: it appears when a proxy sits between endpoint and registrar and needs its own credential. With no proxy in your topology, a 407 means the device points at the wrong outbound proxy address.
Transport, port and reachability
SIP commonly uses UDP 5060, TCP 5060 and TLS 5061, all conventions rather than mandates. A server can listen on any port, but mismatched expectations cause silent failure.
Confirm the endpoint and the server agree on transport. An endpoint set to TCP against a UDP-only listener never gets a reply, so it shows 408 Request Timeout. The same happens when a firewall blocks 5060. Open the signalling port both ways before blaming credentials.
A SIP ALG on the gateway often makes registration worse. A buggy ALG mangles the Via, Contact and SDP headers so the server cannot route the response; if registration is flaky behind a router, disable the ALG and test again.
- Confirm transport (UDP/TCP/TLS) matches on both ends.
- Confirm the signalling port (commonly 5060 / 5061) is open both ways.
- Disable SIP ALG on the edge router and re-test.
- Check the outbound proxy and registrar address fields.
Clock, certificates and TLS
When the server listens on TLS 5061, the handshake depends on the clock. A certificate is valid only between its not-before and not-after timestamps. If the endpoint clock is off by months, the TLS handshake fails before any SIP message, and the symptom looks like a connection timeout, not a cert error.
Point every SIP device at an NTP source and verify the date after a cold boot; some terminals ship with a stale clock and sync once, which breaks TLS until reboot.
Keep certificate validity in view. A server certificate that expired overnight will reject every TLS registration at once, mistakable for a mass credential failure. TLS protects the signalling channel and is separate from permission settings such as which extensions may register from which address.
Triage order that finds the cause
Work top-down; most faults are found in the first two steps.
First confirm the endpoint can reach the server port (for example a probe on 5060/5061); if that fails the fault is network, not SIP. Second, capture the REGISTER exchange: REGISTER, 401, then REGISTER with Authorization. If the second still draws 401, the credentials are wrong. Third, read the server auth log for the reject reason. Fourth, confirm the clock and, on TLS, the certificate chain.
- Probe the signalling port from the endpoint subnet.
- Capture REGISTER / 401 / REGISTER-with-credentials.
- Read the server auth log for the reject reason.
- Verify clock (NTP) and, on TLS, certificate validity.
- Only then change credentials or rebuild the account.
Frequently asked questions
- Why do I see two 401 responses in the trace?
- You normally see REGISTER, 401 challenge, then REGISTER with credentials and a 200 OK. Two 401 cycles in a row mean the credentials in the second REGISTER were still rejected, so check username, password, realm and algorithm.
- Is a 403 the same as a wrong password?
- No. A repeating 401 points at credentials. A 403 Forbidden usually means the account is disabled, blocked by an access list, or the source address is not permitted, even when the password is correct.
- TLS registration fails but UDP works. What changed?
- On TLS 5061 the certificate validity and the endpoint clock matter. A clock far from the certificate window, or an expired server certificate, breaks the handshake before SIP starts. Confirm NTP and certificate dates.
- My phone shows 408 Request Timeout with no 401. Where do I look?
- If no 401 ever arrives, the REGISTER is not reaching the server. Check transport match, the signalling port being open both ways, the outbound proxy address, and whether a SIP ALG is rewriting the message.
- Can a SIP ALG cause registration failure?
- Yes. A SIP ALG rewrites Via, Contact and SDP headers, and a buggy one can mangle the REGISTER so the server cannot route its response. Disabling the ALG on the edge router often resolves flaky registration.
- Does FlySip fix echo or background noise on calls?
- No. Echo cancellation and noise suppression are jobs for the sister products FlyAec and FlyDenoise. The SIP server and terminals handle signalling, routing and media transport, not acoustic processing.
Registration is only the first step. Once endpoints are registered, the next fault you will meet is one-way audio behind NAT — see SIP NAT traversal and RTP relay. For door release logic read DTMF door access control, and browse all SIP guides or the FlySip product overview.