 (comparable to SIPPEER) or directly into the user agent (P2P-UA). The P2P-PROXY should run on the user agent's machine for allowing local communication with the user agent for reducing network traffic. In both systems, REGISTER messages result in publishing resources in the particular P2P network. Contact information (e.g., IP address and port) is stored according the corresponding SIP URI, which acts as the key. SIP messages, which require routing, lead to a P2P network discovery process: corresponding resources with the given SIP URI as key have to be discovered. Then, this contact information is used to directly send the SIP message to the target (see Figure 1.4). However, there are differences between both systems as well. In contrast to SIPPEER, which is based on OpenDHT, the P2P-LOC of Schmidt et al. uses JXTA. JXTA provides the ability to integrate arbitrary P2P mecha- nisms in order to support a variety of application scenarios. For instance, in some mobile scenarios it is not feasible to use DHTs because of the mainte- nance overhead [14]. Additionally, Schmidt et al. seamlessly integrated ser- vice location into their P2P-LOC concept, which is especially important for dynamic networks. Therefore, the P2P SIP proxy is able to interpret extended SIP methods [15]. The standard SIP message REGISTER with an arbitrary attachment is used for service registration. Thus, it can be combined with stan- dard SIP registration, which leads to reduced network traffic. An OPTIONS message with a query as attachment can be used for services discovery. Both requests lead to the P2P-LOC either storing or discovering service information within the JXTA network. In contrast to the work of Schmidt et al., SIPPEER allows the use of the SIP extension as presented in Section 1.3.1 as well. P2P-LOC P2P Network P2P-LOC SIP-UA SIP-UA Proxy Proxy P2P-LOC P2P Network P2P-LOC SIP-UA SIP-UA SIP-UA SIP-UA Terminal Terminal Terminal Domain A Domain B Domain A Domain B (a) Integration into proxy server (b) Integration into user agent FIG