Registration

12.1 What registration does: it binds an AOR to a Contact

Alice calls sip:bob@biloxi.example. That URI is Bob’s AORAOR. The public SIP address of a user, such as sip:alice@atlanta.example.: his public address, which does not change. It does not say where Bob’s phone is. Proxy B finds the phone in its location servicelocation service. The database of bindings from AORs to Contact addresses., and the location service learns it from Bob’s phone, with a REGISTER request (Module 3).

When Proxy B gets a request for the AOR, it sends it to the registered Contacts:

No binding means no route to Bob: Proxy B answers 480 Temporarily Unavailable. Registration is for incoming calls. Bob’s phone can often make calls when its registration is broken, so “outgoing works, incoming fails” is the classic sign of a registration problem.

Most registrars challenge the first REGISTER with 401, and the phone sends it again with credentials (Module 13). The flows in this module leave the challenge out, to show the bindings more clearly.

12.2 REGISTER: Request-URI, To, From, Contact, Expires

This is the first REGISTER of Bob’s desk phone:

REGISTER sip:biloxi.example SIP/2.0
Via: SIP/2.0/UDP 203.0.113.20:5060;branch=z9hG4bKr001x7
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example>;tag=76ff7a07
To: Bob <sip:bob@biloxi.example>
Call-ID: 8463jsGq2@203.0.113.20
CSeq: 1 REGISTER
Contact: <sip:bob@203.0.113.20:5060>
Expires: 3600
Content-Length: 0

The expiry can be in the Expires header, for every Contact, or in an expires parameter on one Contact. The parameter wins. With neither, the registrar uses its default:

The parameter belongs outside the angle brackets: <sip:bob@203.0.113.20:5060>;expires=600. Inside them, it is part of the URI, and the registrar ignores it (Module 4).

REGISTER is a request outside any dialog. Its 200 OK has a To tag, but no dialog follows, and a Record-Route in a REGISTER means nothing:

The phone sends REGISTER to the registrar that it is configured with. Without one, it uses the domain of its AOR, sip:biloxi.example, and finds the server with DNS (Module 11).

12.3 Refresh, query, and remove a registration

A binding is soft state: it expires unless the phone refreshes it. The same request, REGISTER, does all four jobs. The difference is in Contact and Expires:

Every 200 OK lists all current bindings of the AOR — not only the one in the request — each with the time it has left. The expires value always counts from now.

Step through Bob’s day: add, refresh, query, remove. The table on the right is the registrar’s location service, as RFC 3261 §10.3 builds it.

RFC 3261 says only “before the expiry”. Most phones refresh at about half of it, or a fixed time before it. The expiry to use is the one in the 200 OK, which can be shorter than the request (12.5):

A phone keeps one Call-ID while it runs. After a restart it uses a new one. The registrar compares the Call-ID and CSeq, so a delayed REGISTER cannot undo a newer one:

12.4 More than one device per AOR; q values

Bob has a desk phone, a mobile app, and a softphone. Each one registers the same AOR, with its own Contact and its own Call-ID. The registrar keeps one binding per Contact, and each 200 OK shows all three.

A q parameter from 0 to 1 on each Contact says which device Bob prefers:

Proxy B uses q to order its targets. Devices with the same q can ring together; a higher q rings first:

Without q, all bindings have the same preference, and a proxy usually rings them all at once. Module 9 covers forking: several early dialogs, and what happens when two devices answer.

Each device refreshes and removes only its own binding. One device that removes all bindings with Contact: * logs out the other devices too.

12.5 423 Interval Too Brief and Min-Expires

The registrar chooses the expiry, not the phone. It can shorten a long request, and it can refuse a very short one:

Why would a phone ask for 60 seconds? Every REGISTER goes out through Bob’s NAT router, and an outgoing packet keeps the router’s mapping open. A short expiry is a crude keepalive. For the registrar, it is load: 10,000 phones that register every 60 seconds send almost 170 REGISTER requests per second, and each one may also need a digest check. That is why registrars set a Min-Expires, though RFC 3261 asks them to keep it low:

Expiry and the NAT mapping

Two timers decide whether a call reaches Bob behind NAT, and they are not related:

• The registration expiry, at the registrar: does Proxy B know where Bob is?
• The NAT mapping timeout, in Bob’s router: does the router still let packets in on that public port?

Only outgoing packets keep the mapping open. An incoming INVITE does not. When the mapping is gone, the INVITE from Proxy B arrives at a closed port, and the router drops it. Bob’s phone still shows “Registered”. When the phone sends something again, the router may open a new mapping on a new public port — and the binding still has the old one until the next REGISTER.

Change the settings and select a point in the hour to send Alice’s INVITE:

RFC 5626 picked its UDP keepalive interval for exactly this reason:

12.6 Path and Service-Route

Many providers put an edge proxy between the phones and the core: an SBC, or the P-CSCF in IMS (Module 27). Calls to Bob must go through the edge proxy, because only it can reach Bob’s phone — it holds the connection, or it knows the NAT mapping. But Proxy B only has Bob’s Contact. How does it know to go through the edge?

Path (RFC 3327) records the edge proxy during registration. The edge proxy adds a Path header to the REGISTER, the registrar stores it with the binding, and Proxy B puts it in Route when it sends a request to that Contact:

Path looks like Record-Route, but it lives longer:

Service-Route (RFC 3608) goes the other way. The registrar returns it in the 200 OK, and the phone uses it as a pre-loaded Route for its own new requests (Module 10.7), so they reach the proxy that serves Bob:

When Bob calls Carol, his phone puts its outbound proxy first, then the Service-Route:

INVITE sip:carol@chicago.example SIP/2.0
Route: <sip:edge.biloxi.example;lr>, <sip:orig@proxy.biloxi.example;lr>

A phone shows support with Supported: path. Without it, a registrar should refuse a REGISTER that has a Path, with 420 Bad Extension, because a proxy may have added itself to the path without the phone’s knowledge:

12.7 SIP Outbound and GRUU (overview)

SIP Outbound: the phone keeps the connection

Behind NAT or a firewall, nobody can open a connection to Bob’s phone. RFC 5626, SIP Outbound, turns this around: the phone opens the connection, keeps it alive, and the server sends Bob’s calls back over it.

Registration needs two new Contact parameters for this:

• +sip.instance: a permanent, unique name for the device, the instance IDinstance ID. A permanent, unique URN for one device, sent in the +sip.instance Contact parameter (RFC 5626). It does not change when the device reboots or moves.. It does not change when the phone restarts or moves.
• reg-id: the number of the flow. A device can register over two flows, to two edge proxies, for redundancy.

Without them, the registrar only sees Contact URIs. When Bob’s mobile moves from Wi-Fi to 4G, its new Contact is a second binding, and the old one, which leads nowhere, stays until it expires. Calls to Bob fork to both, and the old branch fails slowly. With an instance ID and reg-id, the registrar knows that the new Contact replaces the old one. Compare the two:

On the flow, the phone sends keepalives. On TCP and TLS, a keepalive is a double CRLF, and the server answers with one CRLF. On UDP, it is a STUN request.

The registrar confirms Outbound with Require: outbound in the 200 OK. If it is missing, Outbound is not in use, and the phone must fall back to the methods in 12.5. Module 20 covers NAT traversal in detail.

GRUU: an address for one device

The AOR reaches all of Bob’s devices. Sometimes a request must reach exactly one: Alice transfers Bob’s call to Carol, and Carol’s phone must call Bob’s desk phone, not his voicemail and not his mobile. The Contact address cannot do this, because it is often a private address behind NAT. A GRUUGRUU. A URI that reaches one device of a user, not all of them (RFC 5627). It has the gr parameter. can:

A phone that sends an instance ID and Supported: gruu gets two GRUUs in the 200 OK:

Contact: <sip:bob@198.51.100.77:41270;transport=tcp>
 ;+sip.instance="<urn:uuid:5f3c0a2e-6b1d-4c8e-9a47-2d61b0e8c3f5>";reg-id=1
 ;pub-gruu="sip:bob@biloxi.example;gr=urn:uuid:5f3c0a2e-6b1d-4c8e-9a47-2d61b0e8c3f5"
 ;temp-gruu="sip:tgruu.1er2har@biloxi.example;gr";expires=600

The phone then puts its GRUU in the Contact of its INVITEs and 200 OKs. Proxy B receives a request for the GRUU and sends it only to the Contacts of that one device:

IMS uses instance IDs and GRUUs (Module 27). Many other networks use neither SIP Outbound nor GRUU: they rely on rport, keepalives, and an SBC or a proxy that rewrites the Contact (Module 20).

Common mistakes

Summary

• Registration stores a binding from an AOR to a Contact in the location service. No binding means a call to the user fails, often with 480.
• A REGISTER has the domain in its Request-URI and the AOR in To. It keeps one Call-ID while the phone runs, and adds one to CSeq each time.
• One request does it all: a Contact adds or refreshes, no Contact queries, expires=0 removes one binding, and Contact: * with Expires: 0 removes all.
• Every 200 OK lists all bindings of the AOR, each with the time left. The registrar may shorten the expiry; the phone must refresh before the expiry in the 200 OK.
• Several devices can register one AOR; q values order them. 423 with Min-Expires refuses a very short expiry.
• Behind NAT, the mapping timeout matters as much as the registration expiry: keep the mapping open with keepalives.
• Path puts edge proxies in the route to the phone; Service-Route gives the phone its route for outgoing requests. SIP Outbound replaces a moved device’s binding and keeps its flow alive; a GRUU reaches one device.