SIP Registration Explained: Expiry, Qualify and NAT Keepalives

What registration is for

SIP registration answers one question: where is extension 1001 right now?

A phone is not permanently wired to the PBX. It could be on a desk, on a laptop at home, or on a mobile network. Registration is how it tells the server "extension 1001 is currently reachable at this address" — a binding between an identity and a location.

The phone sends a REGISTER request whose Contact header carries where it can be reached, and an Expires value saying how long that binding should be considered valid. The server stores it. Without a current registration the server has nowhere to send an incoming call, which is why an unregistered extension simply never rings.

Registration is a two-step exchange

A normal registration involves an authentication round trip, and this catches people reading logs for the first time.

The phone sends REGISTER with no credentials. The server responds 401 Unauthorized with a challenge. The phone re-sends the REGISTER, this time with a computed response. The server replies 200 OK.

That first 401 is normal, not a failure. It is how the protocol works. What indicates a real problem is a 401 that repeats endlessly — challenge, response, challenge again — which means the credentials are wrong or something is altering the request in transit.

Expiry: the number that causes most trouble

Registration bindings expire deliberately. If a phone is unplugged, the server needs to eventually stop believing it is reachable, and expiry is the mechanism. The phone re-registers periodically to keep the binding alive.

The trouble is the interaction with NAT. When a phone behind a router registers, the router creates a NAT mapping — a temporary association between the internal address and an external port — and that mapping has its own timeout, typically shorter than the registration expiry.

The result is a specific and very common failure: the phone registers successfully, works for a few minutes, then stops receiving inbound calls while still appearing registered on the server. Outbound calls work fine, because those create fresh outbound traffic. Inbound calls fail, because the router has forgotten the mapping and has nowhere to deliver the incoming packet.

The fix is to re-register (or otherwise send traffic) more often than the NAT mapping expires. Registration intervals in the region of 60 to 120 seconds are common for NATed phones, against a default that might be an hour.

Note that the server can impose a minimum. A request for a shorter expiry than the server permits is answered with 423 Interval Too Brief, and the phone must retry with a longer value.

Qualify: the server checking the phone

Registration tells the server where a phone claimed to be. Qualify checks whether it is still actually there.

With qualify enabled, Asterisk periodically sends an OPTIONS request to the registered contact and measures the response. This does two useful things: it detects a phone that has vanished without unregistering, and — importantly for NAT — the traffic itself keeps the router's mapping alive.

In PJSIP this lives on the AOR:

[1001]
type=aor
max_contacts=1
qualify_frequency=30
qualify_timeout=3

A qualify_frequency of 30 seconds is a reasonable default for NATed endpoints — frequent enough to hold most NAT mappings open, infrequent enough not to generate meaningful traffic. Setting it to 0 disables qualification entirely.

Related settings worth knowing: max_contacts controls how many devices may register against the same AOR — leave it at 1 and a user's softphone will displace their desk phone. remove_existing governs what happens when that limit is reached.

Diagnosing registration problems

Start with what the server actually believes:

pjsip show endpoints
pjsip show aors
pjsip show contacts
pjsip show registrations   # outbound registrations to providers

pjsip show contacts is the one that matters most — it shows the current bindings with their status and round-trip time. An endpoint with no Avail contact is not reachable, regardless of how correct the configuration file looks.

For live detail, watch the exchange:

asterisk -rvvv
pjsip set logger on

Common patterns and what they mean:

• Registers, then drops after a few minutes. NAT mapping timeout. Shorten the registration interval and enable qualify.
• Repeating 401s. Wrong credentials, or a middlebox rewriting the request so the digest hash no longer matches. Disable SIP ALG on the router.
• 403 Forbidden. Not a credentials challenge at all — the server is refusing on policy. Check IP allow-lists and account status.
• 423 Interval Too Brief. The requested expiry is below the server's minimum. Increase it.
• Registers but no inbound calls. The contact address is wrong — typically a private address advertised from behind NAT. Enable rewrite_contact so Asterisk uses the address the request actually came from.
• One device knocks another offline. max_contacts is too low for the number of devices on that extension.

Trunk registration is the same idea, inverted

An outbound registration to a carrier uses the same mechanism with the roles reversed: your Asterisk is the client, the carrier is the registrar. Configured as a type=registration object, it is checked with pjsip show registrations.

Not every trunk needs one. IP-authenticated trunks identify you by source address instead, using a type=identify object, and register nothing at all. Knowing which model your carrier uses saves a lot of pointless debugging — you cannot troubleshoot a registration that was never meant to exist.

Frequently asked questions

Why does my phone register and then stop working?

Almost always a NAT mapping expiring before the registration does. Shorten the registration interval to 60–120 seconds and enable qualify so periodic traffic holds the mapping open.

Is a 401 during registration a problem?

No. The first 401 is the standard authentication challenge and the phone should immediately retry with credentials. Only a repeating cycle indicates a fault.

What does qualify actually do?

It sends periodic OPTIONS requests to registered contacts to confirm they are still reachable and to measure latency. As a side effect it keeps NAT mappings alive, which is often the more valuable function.

Why can only one of my two devices register?

max_contacts on the AOR limits how many contacts may bind to it. Raise it to allow a desk phone and a softphone on the same extension.