842 in this example, and sends it in a REGISTER to the bootstrap node, which has node-ID 020 (1). In most cases, the bootstrap node is not the node currently responsible for this region. So the bootstrap responds with information about the nodes it knows nearest to where node A will be placed in the overlay, in this case node B, with Node-ID 345. This information is passed back in the new headers, extended by SOSIMPLE, within a SIP 302 moved temporarily response (2). Then node A will repeat the process, using this nearer node as the new bootstrap node (3-4), until it reaches node C, which is currently responsible for maintaining the appropriate section of the overlay. Node C responds with a SIP 200 OK response indicating information about nearby neighbors in the headers (5-6), thus allowing the joining node to insert itself into the overlay. 9.3.1.2 User Operations User registration and resource location are decentralized in SOSIMPLE. In order to register, or to contact another user, the node responsible for stor- ing the information of that user must be located. An illustration about the resource location process is shown in Figure 9.6 [4]. In this example, Alice will locate Bob, and the naming convention is fol- lowed. First, the node of Alice hashes the user name Bob to produce a resource- ID. After getting the resource-ID, the node of Alice searches the Node-ID nearest to the resource-ID of Bob in its finger table and gets node A. Then, the node of Alice sends a message to node A (1). As node A is not respon- sible for that resource-ID, it sends a SIP 302 moved temporarily reply. The reply includes the closest node, Node B, found in its finger table in the head- ers (2). The node of Alice will keep on trying the node received from the replies (3, 4, 5, 6) until it finds the node responsible for the resource-ID of Bob. C 2009 by Taylor & Francis Group, LLC SIP Handbook: Services, Technologies, and Security Node A Alice's node Node B Bob's node Node C FIGURE 9.6 Alice locates user Bob and establishes a communic