In this example, shown in Figure 2.3, Heisenberg sends a SIP REGISTER request to a type of SIP server known as a registrar server. The SIP registrar server receives the message uses the information in the request to update the database used by proxies to route SIP requests. Contained in the REGISTER message To header is the SIP URI address of Heisenberg. This is Heisenberg's "well-known" address, perhaps printed on his business card or published on a Web page or in a directory. Also contained in the REGISTER is a Contact URI, which represents the current device (and its IP address) that the user Heisenberg is currently using. The registrar binds the SIP URI of Heisenberg and the IP address of the device in a database that can be used, for example, by the proxy server in Figure 2.2 to locate Heisenberg. When a proxy server with access to the database receives an INVITE request addressed to Heisenberg's URI (i.e., an incoming call), the request will be proxied to the Contact URI of the currently registered device.
This registration has no real counterpart in the telephone network, but it is very similar to the registration a wireless phone performs when it is turned on. A cell phone sends its identity to the base station (BS), which then forwards the location and phone number of the cell phone to a home location register (HLR). When the mobile switching center (MSC) receives an incoming call, it consults the HLR to get the current location of the cell phone. Further aspects of SIP mobility are discussed in Chapter 9.
The REGISTER message sent by Heisenberg to the SIP registrar server has the form:
REGISTER sip:registrar.munich.de SIP/2.0 Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bKus19 Max-Forwards: 70 To: Werner Heisenberg <sip:[email protected]> From: Werner Heisenberg <sip:[email protected]> ;tag=3431 Call-ID: [email protected] CSeq: 1 REGISTER Contact: sip:[email protected] Content-Length: 0
The Request-URI in the start line of the message contains the address of the registrar server. In a REGISTER request, the To header field contains the URI that is being registered, in this case sip:[email protected]. This results in the To and From header fields usually being the same, although an example of third-party registration is given in Section 4.1.2. The SIP URI in the Contact address is stored by the registrar.
The registrar server acknowledges the successful registration by sending a 200 OK response to Heisenberg. The response echoes the Contact information that has just been stored in the database and includes a To tag:
SIP/2.0 200 OK Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bKus19 To: Werner Heisenberg <sip:[email protected]>;tag=8771 From: Werner Heisenberg <sip:[email protected]> ;tag=3431 Call-ID: [email protected] CSeq: 1 REGISTER Contact: <sip:[email protected]>;expires=3600 Content-Length: 0
The Contact URI is returned along with an expires parameter, which indicates how long the registration is valid, which in this case is 1 hour (3,600 seconds). If Heisenberg wants the registration to be valid beyond that interval, he must send another REGISTER request within the expiration interval.
Registration is typically automatically performed on initialization of a SIP device and at regular intervals determined by the expiration interval chosen by the registrar server. Registration is an additive process—more than one device can be registered against a SIP URI. If more than one device is registered, a proxy may forward the request to either or both devices, either in a sequential or parallel search. Additional register operations can be used to clear registrations or retrieve a list of currently registered devices.