SIP Registration Explained

SIP registration is the process by which a SIP client tells a server where it can be reached. The client sends a REGISTER request that binds its address of record, such as sip:1001@pbx.example.com, to a contact address, such as sip:1001@192.168.1.20:5060. The server stores this binding and uses it to route incoming calls. Registration is temporary. It carries an expiry time, and the client must refresh it before that time runs out or the server forgets where the client is. Section 10 of RFC 3261 defines the procedure.

Why is registration needed at all?

A SIP address like sip:1001@pbx.example.com is a logical identity. It says nothing about which device the user is on or what IP address that device currently has. Laptops move between networks, phones switch between Wi-Fi and mobile data, and home routers hand out changing addresses. Registration solves this. Each time the device starts or changes network, it registers its current location. The server, acting as a registrar, keeps a location table. When a call arrives for 1001, the server looks up the table and forwards the INVITE to the registered contact.

Without a current registration, the server has no idea where to send incoming calls. Outgoing calls may still work, since the client knows where the server is, but inbound calls fail.

What does a REGISTER request contain?

A REGISTER request is a SIP request like any other, with a few specific features.

REGISTER sip:pbx.example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.20:5060;branch=z9hG4bK2a76a36849;rport
From: <sip:1001@pbx.example.com>;tag=86652d54
To: <sip:1001@pbx.example.com>
Call-ID: ac41db3ce89a443e@192.168.1.20
CSeq: 1 REGISTER
Contact: <sip:1001@192.168.1.20:5060>;expires=3600
Max-Forwards: 70
Content-Length: 0

• The request URI is the domain, with no user part. It names the registrar responsible for the domain.
• From and To both hold the address of record. In a REGISTER they are normally identical.
• Contact holds the location where the device wants to receive requests. This is the binding being created.
• Expires, either as a header or a Contact parameter, proposes how long the binding should last in seconds.
• Call-ID should stay the same across REGISTER refreshes from one device until it restarts, and CSeq increases by one each time.

How does the authentication challenge work?

Almost every server requires authentication for REGISTER. The exchange has four steps.

1. The client sends REGISTER without credentials.
2. The server replies 401 Unauthorized with a WWW-Authenticate header containing a realm and a nonce. Some servers, acting as proxies, reply 407 Proxy Authentication Required instead.
3. The client computes a digest from the username, realm, password, nonce, method and request URI, and resends REGISTER with an Authorization header carrying the result.
4. The server verifies the digest and replies 200 OK. The response lists the accepted Contact bindings and their remaining expiry.

A 401 on the first attempt is not an error. It is the expected start of the handshake. Seeing a 401 or 407 after the client has already sent credentials usually means the server rejected them. The exception is a challenge marked stale=true, which only asks the client to retry with a fresh nonce. A 403 Forbidden usually means the same, or that the account is disabled or blocked. Check the password and auth username first, as described in What is a SIP account?.

How does expiry and refresh work?

The client proposes an expiry. Common values are 3600 seconds or, for NAT reasons, something much shorter such as 60 to 300 seconds. The server may accept it, shorten it or reject it with 423 Interval Too Brief if it is below the server minimum. The 200 OK carries the value actually granted.

The client schedules a refresh before the granted expiry passes. Most clients refresh at roughly half to ninety percent of the interval. A refresh is simply another REGISTER with the same Call-ID, an incremented CSeq and the same Contact. The server extends the binding.

To unregister, the client sends REGISTER with Expires: 0 for its Contact. Softphones do this when they quit or when the user disables an account. A client that crashes or loses power cannot unregister, so the binding stays until it expires on its own.

How does the client find the registrar?

If the account provides a full server address and port, the client sends REGISTER straight there. If only a domain is given, the client follows RFC 3263: it queries NAPTR records to find supported transports, then SRV records such as _sip._udp.pbx.example.com for the host and port, then A or AAAA records. If no SRV records exist, it falls back to the default port for the transport: 5060 for UDP and TCP, 5061 for TLS. Clients such as SIPdia perform the SRV lookup when the Server field has no explicit port.

Why does registration fail or misbehave behind NAT?

The Contact header carries the address the client believes it has. Behind a NAT router, that is a private address like 192.168.1.20. The server receives the REGISTER from the router's public address, say 203.0.113.5 port 41234, but the Contact says 192.168.1.20 port 5060. If the server trusts the Contact, it sends incoming INVITEs to an address it cannot reach. The user sees a green "registered" indicator and never receives a call.

Several mechanisms address this.

• rport, defined in RFC 3581. The client adds rport to its Via header. The server fills in the source port it actually saw and sends responses back to that address and port. Many servers also rewrite the Contact binding to the observed address. In Asterisk, force_rport and rewrite_contact do this.
• STUN. The client asks a public STUN server what its public address and port are, then puts those in the Contact and SDP. This works for many home routers but not for symmetric NAT.
• Short expiry and keepalives. NAT routers drop idle UDP mappings after a short time, often 30 to 120 seconds. A client that registers every 60 seconds, or sends small keepalive packets, keeps the mapping open so the server can still reach it.
• Connection reuse over TCP or TLS. Over a connection-oriented transport, the server can send requests back down the same connection the client opened. RFC 5626 formalises this with the ob parameter and flow tokens. Even without full RFC 5626 support, TCP and TLS avoid most NAT contact problems.

What do common registration responses mean?

Response	Likely meaning
200 OK	Registered. Check the returned expiry.
401 / 407 (first)	Normal challenge. Client should resend with credentials.
401 / 407 (repeated)	Wrong password or auth username.
403 Forbidden	Credentials rejected, account disabled, or source address refused by an access list on the server.
404 Not Found	Username does not exist on this server or wrong domain.
423 Interval Too Brief	Requested expiry below server minimum. Increase it.
408 / timeout	Server not reached. Wrong address, port or transport, a firewall, or an address banned by fail2ban.
503 Service Unavailable	Server overloaded or refusing. Try again later or contact the administrator.

The troubleshooting articles cover the most common failures step by step: SIP 401 Unauthorized, SIP 403 Forbidden, SIP 408 Request Timeout and why SIP registration keeps failing.

Next steps

If registration still fails, the troubleshooting hub covers specific error responses. For how the transport choice affects NAT behaviour, read SIP over UDP, TCP and TLS. To review the fields a registration depends on, see What is a SIP account?.