SIP Registration: How Your Phone Tells the World Where It Is

SIP Signaling From the Wire Up: Part 4 of 12

When an IP phone powers on, nobody knows where it is. Unlike a traditional phone that's wired directly to a port in a switch closet, an IP phone could be anywhere on any network. It could be at a desk in the main office, plugged in at a branch location, or connected through a VPN from someone's home. The phone needs a way to announce itself to the system and say "I'm extension 200, and right now you can reach me at this IP address and port." That announcement is SIP registration.

Registration is one of the first things that happens when a phone boots up, and it's one of the most common failure points in VoIP systems. If registration fails, the phone can't receive calls. In many setups it can't make calls either. Understanding how registration works at the protocol level makes it much easier to diagnose why a phone is showing "not registered" on its screen or why calls for a particular extension are going straight to voicemail.

What registration does

SIP registration creates a binding between an address of record (AOR) and a contact address. The address of record is the phone's logical identity, something like sip:[email protected]. The contact address is the phone's current physical location on the network, something like sip:[email protected]:5060.

The registrar server stores this binding. When someone calls sip:[email protected], the proxy looks up the current binding in the registrar and knows to send the INVITE to 10.0.0.50:5060. If Alice moves her phone to a different network and re-registers from a new IP address, the binding updates and calls get routed to the new address. This is what allows IP phones to be portable in a way that traditional phones aren't. The same mechanism applies to browser-based softphones, which send the identical REGISTER exchange over a WebSocket connection instead of UDP.

The registration flow

Registration involves a challenge/response authentication sequence. Here's how it plays out.

Step 1: Initial REGISTER (unauthenticated)

The phone sends a REGISTER to the registrar:

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bKnashds7
Max-Forwards: 70
To: "Alice" <sip:[email protected]>
From: "Alice" <sip:[email protected]>;tag=456248
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: <sip:[email protected]:5060>
Expires: 3600
Content-Length: 0

A few things to note. The Request-URI is sip:example.com, which is the domain of the registrar. Unlike an INVITE, which is addressed to a specific user, REGISTER is addressed to the domain. The To and From are both Alice, because she's registering herself. The Contact header contains the address where Alice wants to be reached. The Expires header says Alice wants this registration to be valid for 3600 seconds (one hour).

Step 2: Server challenges with 401 Unauthorized

The registrar doesn't just accept registrations from anyone. It needs to verify that this is actually Alice and not someone pretending to be her. (We cover the full authentication and security model later in the series.) So it rejects the initial REGISTER with a 401 Unauthorized and includes a challenge:

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bKnashds7
To: "Alice" <sip:[email protected]>;tag=2145
From: "Alice" <sip:[email protected]>;tag=456248
Call-ID: [email protected]
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="example.com",
  nonce="84a4cc6f3082121f32b42a2187831a9e",
  qop="auth",
  algorithm=MD5
Content-Length: 0

The WWW-Authenticate header is the challenge. It contains a realm (the authentication domain), a nonce (a unique value generated by the server for this specific challenge), and the algorithm to use. The nonce is a one time value that prevents replay attacks. Someone who captured a previous successful authentication can't just replay the same credentials, because the nonce is different each time.

Step 3: Phone re-registers with credentials

The phone takes the challenge parameters, combines them with Alice's username and password using the specified algorithm, and generates a digest response. It sends a new REGISTER with the Authorization header:

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bKnashds8
Max-Forwards: 70
To: "Alice" <sip:[email protected]>
From: "Alice" <sip:[email protected]>;tag=456248
Call-ID: [email protected]
CSeq: 2 REGISTER
Contact: <sip:[email protected]:5060>
Expires: 3600
Authorization: Digest username="alice",
  realm="example.com",
  nonce="84a4cc6f3082121f32b42a2187831a9e",
  uri="sip:example.com",
  response="dfe56131d1958046689cd83306477ecc",
  algorithm=MD5,
  qop=auth,
  nc=00000001,
  cnonce="0a4f113b"
Content-Length: 0

The CSeq has incremented to 2 (this is a new request), and the branch is different (new transaction), but the Call-ID and tags are the same. Note that REGISTER does not create a dialog. The reuse of Call-ID and From tag here is for correlating the registration sequence (allowing the server to associate the authenticated retry with the original challenge), not for dialog maintenance. This is different from INVITE, where those values identify an ongoing dialog between two parties.

The Authorization header contains the digest response, which is the hash value computed from Alice's credentials and the challenge parameters. The server performs the same computation using the password it has stored for Alice. If the results match, Alice is authenticated.

Note that the password itself never appears in the message. Only the computed hash is transmitted. This means that capturing a REGISTER from the network doesn't directly expose the password, though the digest mechanism is considered weak by modern standards and the hash can potentially be brute forced offline if the password is short or common.

Step 4: Server accepts with 200 OK

If the credentials check out, the registrar stores the binding and sends a 200 OK:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bKnashds8
To: "Alice" <sip:[email protected]>;tag=2145
From: "Alice" <sip:[email protected]>;tag=456248
Call-ID: [email protected]
CSeq: 2 REGISTER
Contact: <sip:[email protected]:5060>;expires=3600
Content-Length: 0

The Contact header in the response confirms the binding and the expiration time. Alice is now registered. The registrar knows that calls for sip:[email protected] should be routed to 10.0.0.50:5060.

Registration lifetime and re-registration

The Expires value in the registration defines how long the binding is valid. When Alice registered with Expires: 3600, the registrar will keep her binding for one hour. If Alice doesn't re-register before that hour is up, the binding expires and she becomes unreachable.

In practice, phones re-register well before the expiration. A phone with a 3600 second registration lifetime might re-register every 1800 or 2700 seconds. The exact behavior varies by phone manufacturer and configuration. The re-registration process is the same as the initial registration: the phone sends a REGISTER, gets challenged, responds with credentials, and gets a new 200 OK with a refreshed expiration.

If re-registration fails for any reason, the phone has a limited window before the existing registration expires. If that window passes without a successful re-registration, the phone drops off the system. Incoming calls fail. The phone shows "not registered" or a similar status.

This is why intermittent registration failures can cause intermittent call problems. The phone might be registered and working, then fail to re-register during one cycle, remain reachable for the remaining lifetime of the old registration, and then lose registration entirely. A few minutes later, the next re-registration attempt might succeed, and everything works again. To the user, it looks like the phones randomly stop working for a few minutes at a time.

What the server can do with Expires

The server doesn't have to accept the client's requested expiration time. It can shorten it. If Alice asks for 3600 seconds but the server's policy is a maximum of 600 seconds, the 200 OK will come back with expires=600 in the Contact header. The phone should respect this and re-register within 600 seconds.

Some servers set very short expiration times as a way to keep tighter control over registrations or to detect failed phones faster. The tradeoff is more registration traffic on the network and more load on the registrar. Very short expirations (under 60 seconds) over unreliable connections, particularly through certain NAT devices that have short UDP timeout values, can cause a cycle of registration, expiry, re-registration that creates instability.

Unregistration

A phone can explicitly unregister by sending a REGISTER with Expires: 0:

REGISTER sip:example.com SIP/2.0
...
Contact: <sip:[email protected]:5060>
Expires: 0

This tells the registrar to remove the binding immediately. A cleanly powered down phone should send this. In practice, not all phones do, especially if they lose power unexpectedly. In that case, the registrar just waits for the existing binding to expire naturally.

A phone can also send a REGISTER with Contact: * and Expires: 0, which removes all bindings for that address of record, not just the one from the current location. This is useful when a phone has been moved and old stale bindings need to be cleaned up.

Common registration problems

Wrong credentials. The phone sends a REGISTER, gets challenged, sends the digest response, and gets a 403 Forbidden. The username or password is wrong. In the trace, you'll see the initial 401, the authenticated REGISTER, and then a 403 instead of a 200. Some servers send 401 again instead of 403 when credentials are wrong, which means the phone will keep trying the same bad credentials in an infinite loop of challenge/response failures.

Firewall blocking. The REGISTER leaves the phone but never reaches the registrar, or the 401 challenge comes back but the authenticated re-register gets blocked. In the trace from the phone's perspective, you'll see the REGISTER go out and then nothing. The phone retransmits several times and eventually gives up. From the server's perspective, it either never received the REGISTER at all, or it sent the 401 and never got the authenticated follow-up.

DNS failure. The phone is configured with a domain name for the registrar (e.g., sip.example.com) but can't resolve it to an IP address. The REGISTER never gets sent because the phone can't determine where to send it. This won't show up in a SIP trace at all because no SIP messages are generated. You'd see it in the phone's own logs as a DNS resolution error.

NAT timeout. The phone registers successfully through a NAT device, but the NAT device's UDP mapping expires before the next re-registration. When a new inbound call arrives, the registrar tries to send the INVITE to the Contact address it has on file, but the NAT mapping is gone, so the INVITE never reaches the phone. The phone's registration appears valid on the server, but it's effectively unreachable. This is one of the most frustrating problems to diagnose because the registration looks fine from both sides. We'll cover NAT issues extensively in post 6.

Server unreachable. The registrar is down, overloaded, or the network path between the phone and the registrar is broken. The phone sends REGISTERs that go unanswered. After the existing registration expires, the phone is offline.

What to look for in a trace

When troubleshooting a registration problem, filter your capture for REGISTER messages from the phone's IP address. You're looking for the sequence: REGISTER, 401, REGISTER with Authorization, and then the final response. If the final response is 200 OK, registration succeeded. If it's a 403 or another 401, there's an authentication problem. If there's no response at all after the initial REGISTER, there's a network or firewall issue.

Check the Expires value in the 200 OK to see how long the registration is valid. Check the Contact address to see what IP and port the server has recorded. If that Contact shows a private IP address and the phone is behind NAT, inbound calls may not work even though registration looks successful from the server's perspective.

Next up: SDP and Media Negotiation: How Two Phones Agree on How to Talk, where we take apart the message body that determines what the call will actually sound like.