The SIP registration process is shown as follows:
The SIP protocol employs a component called Registrar. It is a server that accepts REGISTER requests and saves the information received in these packets on the location server for their managed domains. The SIP protocol has a discovery capacity; in other words, if a user starts a session with another user, the SIP protocol has to discover an existent host where the user can be reached. The discovery process is done (among others) by a Registrar server that receives the request and finds the location to send it. This is based in a location database maintained by the Registrar server per domain. The Registrar server can accept other types of information, not only the client's IP addresses. It can receive other information such as Call Processing Language (CPL) scripts on the server.
Before a telephone can receive calls, it needs to be registered with the location database. In this database, we will have all the phones associated with their respective IP addresses. In our example, you will see the sip user, [email protected], registered with the IP address, 200.180.1.1.
RFC 3665 defines best practices to implement a minimum set of functionalities for a SIP IP communications network. In the following table, the flows are defined according to RFC 3665 for registration transactions. According to RFC 3665, there are five basic flows associated with the process of registering a user agent.
|
Message flow |
Description |
|---|---|
 |
A successful new registration: After sending the Register request, the user agent will be challenged against its credentials. We will see this in detail in Chapter 5, Subscriber Management. |
 |
An update of the contact list: As it is not a new registration, the message already contains the Digest and a 401 message won't be sent. To change the contact list, the user agent just needs to send a new register message with the new contact in the CONTACT header field. |
 |
A request for the current contact list: In this case, the user agent will send the CONTACT header field empty, indicating that the user wishes to query the server for the current contact list. In the 200 OK message, the SIP server will send the current contact list in the CONTACT header field. |
 |
The cancellation of a registration: The user agent now sends the message with an EXPIRES header field of 0 and a CONTACT header field configured as |
 |
Unsuccessful Registration: The UAC sends a REGISTER request and receives a 401 Unauthorized Message in exactly the same way as the successful registration. In the sequence, it produces a hash and tries to authenticate. The server, detecting an invalid password, sends a 401 Unauthorized message again. The process will be repeated for the number of retries configured in the UAC. |