echnologies into SIP As already mentioned in the introduction, there are several ways to integrate P2P mechanisms into SIP in order to eliminate the need of central servers. These are either an extension of standard SIP or an extension of the SIP entity regarding endpoint location, i.e., the SIP location service. Both mechanisms are described in detail in the next two sections. 1.3.1 Extension of SIP Bryan et al. developed a SIP extension called dSIP, which uses P2P mech- anisms [5]. The idea is to maintain a P2P overlay on the basis of extended SIP messages serving as a distributed registrar server for resource location. The protocol extension allows publishing and querying contact information, which is required for routing SIP messages without the need of any central server entities. Therefore, additional SIP headers are introduced but no new SIP methods (i.e., message types) are needed. dSIP is designed to support various DHT protocols. In order to guarantee minimal compatibility between potential participants at least Chord has to be supported [7, 8]. dSIP peers (i.e., terminals that are compatible with dSIP) have to provide server-like as well as infrastructure-maintaining functionality, i.e., they have to act like registrar and proxy servers at the same time. © 2009 by Taylor & Francis Group, LLC SIP in Peer-to-Peer Networks In general, P2P infrastructures require mechanisms to store and to retrieve resource information. dSIP uses the SIP REGISTER message for binding SIP resource names (i.e., SIP URIs) to particular contact details. Therefore, each peer and resource has a globally unique identifier (GUID) within the dSIP infrastructure. Resources are stored and located according to the DHT algorithm mapping their GUID onto a specific node GUID that is closest according to the given metric. In order to send a message, e.g., for session establishment, a peer has to dis- cover the resource location first. dSIP uses REGISTER messages for resource discovery: a REGISTER message without a contact header implements