Why Does SIP Registration Keep Failing?

SIP registration fails in three distinct ways, and the first job is to decide which one you have. Either the server never answers, the server answers with a refusal such as 401 or 403, or registration succeeds and later drops. Each has its own causes. The checklist below runs through all of them in the order that finds the fault fastest.

Quick checklist

1. No answer at all? Check address, port, transport and firewall. See step one below.
2. 401 or 403? Check the password, auth username, domain and account state.
3. Works then drops? Check NAT keep-alive, registration expiry and transport.
4. TLS selected? The server certificate must be from a public CA.
5. Several devices on one extension? Check the server's contact limit.
6. Repeated failures from your network? Check for an IP ban.
7. Only on one network? Compare Wi-Fi with mobile data and check IPv6.

Step 1: Does the server answer at all?

If the softphone reports a timeout or "Could not reach the server", nothing reached the server or nothing came back. Confirm the Server hostname, the port and the Transport. Try switching between UDP and TCP. On a Mac or iPhone talking to a PBX on the local network, make sure the app has Local Network permission, which Apple describes in technote TN3179. How to Fix SIP 408 Request Timeout covers this problem in more detail. Do not move on until you receive some reply, even a refusal.

Step 2: Are the credentials right?

RFC 3261 section 10 describes REGISTER; section 22 describes the digest authentication that protects it. One 401 is expected. A second 401, or a 403, means the server rejected the hashed credentials. Check:

• the password, retyped from the server or portal;
• the Auth username, which on a PBX should equal the extension number or be left empty;
• the Domain, which should be empty unless the provider lists one separately;
• the account state, which only the administrator can confirm.

Details are in How to Fix SIP 401 Unauthorized and How to Fix SIP 403 Forbidden.

Step 3: Does DNS resolve to the right server?

When you enter a hostname without a port, most softphones look up SRV records (_sip._udp, _sip._tcp, _sips._tcp) and then A or AAAA records. A stale SRV record, a split-horizon DNS that gives different answers inside and outside the office, or a hostname that only resolves on the company VPN all send the REGISTER to the wrong place. Test by entering the server's IP address with an explicit port. If that registers, the fault is DNS.

Step 4: Why does registration drop after it succeeds?

This is the most frustrating pattern: a green registered indicator followed, minutes later, by "not registered" or by missed calls that never rang.

NAT mappings expire

Your router creates a temporary mapping for the UDP flow between the phone and the server. Home routers often drop it after 30 to 60 seconds of silence. When the server later sends a request, there is no mapping and the packet is discarded. The phone still believes it is registered until its next REGISTER.

Fixes, roughly in order of effectiveness:

1. Use TCP or TLS. Connection-oriented transports keep the NAT mapping alive as long as the connection exists, and the phone can reopen it.
2. Enable keep-alives in the phone if offered. RFC 5626 standardises this for SIP; many clients also send a small UDP packet or CRLF periodically.
3. Shorten the registration expiry so the REGISTER itself refreshes the mapping. RFC 3261 lets the server impose its own minimum with a 423 Interval Too Brief reply.
4. Make sure the server supports rport (RFC 3581) so it replies to the address and port the request actually came from, not the private one inside the Via header.

The server shortens the expiry

Servers may override the expiry the phone asks for. If the server returns a short expiry and the phone's refresh timer is set to the requested value, the registration lapses between refreshes. Well-behaved clients read the expiry from the 200 OK and refresh early, but it is worth confirming the server's minimum and maximum expiry settings. On Asterisk the relevant options are documented at docs.asterisk.org.

Step 5: Is the TLS certificate valid?

With TLS the handshake happens before any SIP message. If the certificate fails validation, the phone closes the connection and the server logs nothing useful. The certificate must:

• be issued by a public certificate authority the device trusts;
• match the hostname you typed in the Server field, not the IP address;
• not be expired.

SIPdia rejects self-signed certificates, as its documentation states; the alternative is UDP or TCP inside a VPN. Servers that hand out a free public certificate, for example through an ACME client, avoid this problem. TLS and SRTP explains what the encryption covers.

Step 6: Has the extension reached its contact limit?

Each registered device adds a contact to the account. Servers cap this, often at one. When the cap is reached the next device is refused, or it replaces the previous one and the first device stops ringing. If you register the same extension on a Mac, an iPhone and a desk phone, raise the limit on the server or create separate extensions and ring them together.

Step 7: Is your IP address banned?

A run of failed registrations, from you or from another device on the same public address, triggers fail2ban and similar tools. During the ban, requests are dropped or refused. Correcting the credentials changes nothing until the ban lifts. Ask the administrator to check and remove the ban, then fix the device that caused it.

Step 8: Is it this network, or every network?

Register on mobile data and on Wi-Fi in turn. If one works, the difference between the two networks is the cause. Look for:

• a firewall that blocks UDP or TCP 5061;
• a SIP ALG on the router (What Is SIP ALG and Should You Disable It?);
• a captive portal or guest network that only allows web traffic;
• Local Network permission on Apple devices when the PBX is on the LAN.

IPv6

Some networks are IPv6 first. If the hostname has an AAAA record and the phone prefers IPv6 but the server's SIP service only listens on IPv4, the REGISTER goes nowhere. Try the IPv4 address directly. If that works, either fix the server's IPv6 listener or remove the AAAA record for the SIP hostname.

Next steps

Once the registration holds, confirm that calls work in both directions. Why Can I Register but Not Make Calls? covers the next layer of problems. For background on what a registration actually does, read SIP registration explained and What is a SIP account?. If you are configuring SIPdia, the iPhone setup tutorial shows where each field lives.