equired. Additional DHTs can be added and supported. These will be discussed in the next subsection. The details of the Chord algorithm for dSIP are described in [20] and an alternate DHT algorithm for dSIP based on Bamboo is provided in [20]. 9.5.2.1 Peer Functions and Behavior in dSIP dSIP peers provide many functions. A participating peer must be an active member of the overlay and must provide some SIP "server-like" behaviors well. The code that implements the additional server-like and DHT behavior can be located in several places in the network. The simplest is an endpoint peer. These peers provide the basic functionality of any SIP endpoint, but additionally implement some more operations described in [17] to enable self- organization and provide SIP server-like functionality. The behavior can also be located in an adapter peer, which allows one or more non-P2P aware SIP UAs to interact with the P2P overlay network. The adapters perform the additional self-organizing and SIP server-like behavior on behalf of the UAs they support. In this case, only the adapter peer is a peer in the overlay, the UAs are not. The adaptors speak the P2P SIP peer protocol, while the UAs speak conventional SIP. All interaction with the P2P overlay is carried out by the adapter peer. 9.5.2.2 P2P Overlay Structure As described in Section 9.4, the P2P overlay in dSIP consists of peers, which collectively serve as a directory service for locating resources. Peers are orga- nized using a supported DHT P2P structure. dSIP allows for pluggable DHT algorithms, the exact form of which is defined in the DHT algorithm definition. Each peer is assigned a peer-ID, and each resource that is stored in the overlay is assigned a resource-ID. These values must map to the same name space. dSIP provides for various algorithms to be used to produce these values, but all members of the overlay must use the same algorithm. In the Chord DHT implementation, SHA-1 is used to produce 160 bit values for both the peer-ID and resource-ID. The peer-ID assign