 locat- ing target end-terminals. Therefore, peers have to calculate the target resource ID based on the target's SIP URI according to the given DHT algorithm. dSIP specifies a resource URI for identifying resources (e.g., SIP URI), such as <sip:bob@xyz.org;resource-ID=1257ebd371> (the resource ID represents the hashed value of the SIP URI). The peer queries its routing table to select the closest known entity (or entities) with respect to the target resource ID (spec- ified by the closeness metric of the DHT algorithm). Then, the REGISTER message is sent to these closest known peers. dSIP specifies three possible mechanisms for the routing process: iterative (see Figure 1.3a), recursive (see Figure 1.3b) and semi-recursive. In all three cases, the final response is either a 200 OK message with the required contact information in case of success, or a 404 Not Found message if the target end-terminal cannot be located. For itera- tive routing, the source (sending peer) receives 302 Redirect response messages from the contacted peers that contain peer IDs that are closer to the sought resource ID according to the given metric. Then, the source iterates sending messages to more and more close peers until the response is either 200 OK or 404 Not Found. In the recursive routing process, a peer forwards messages in a proxy-like behavior to the closest known node on its own. The response is also sent to each former peer in the forwarding chain. Semi-recursive routing is almost identical as messages are also forwarded by peers on their own. In contrast to recursive routing, the response is sent directly to the requesting peer. On the basis of the contact information given in the 200 OK message in case of successful discovery, messages, e.g., for session establishment, are directly sent to the target end-terminal. Initial registration at the network requires two successive steps: basic regis- tration of the peer for integration into the P2P network and registration of the SIP contact information in order to be available f