ations session. If Alice is registering herself as a user within the overlay, the messages Alice's UA sent (1, 3, 5) are of type REGISTER. Node C appends a mapping key/value item of Alice's username and her IP address into its registration table and replies to the node of Alice with a 200 OK message (6). Alice is then registered with the system. If Alice is trying to call Bob, the messages Alice's UA sent (1, 3, 5) are either SIP INVITE messages to establish a VoIP call or SIP MESSAGE messages containing IM data. Node C looks in its registration table to see if Bob's registration is present. If it is not, a 404 Not Found is returned (6), indicating the user Bob is not in the system. Otherwise, node C sends a 302 moved temporarily reply, providing a contact directly for Bob (6). Finally, the call between Alice and Bob can be established directly between the nodes using conventional SIP mechanisms without involving the overlay (7). 9.3.2 A P2P Architecture for SIP-Based IP Telephony System The architecture for a P2P SIP-based IP telephony system is shown in Fig- ure 9.7 [5]. Some of the nodes with high capacity (bandwidth, CPU, memory) and availability (uptime, public IP address) are made super-nodes and form the DHT, whereas other nodes attached to one or more super-nodes without being part of the DHT are made ordinary nodes. Figure 9.8 shows the block diagram of components in the proposed P2P SIP node. When the node starts up and the user signs in with his identifier, the discover module is activated to initiate Network Address Translation (NAT) and firewall detection, peer discovery, and SIP registration. Multicast SIP registration, cached peer addresses from last boot cycle, and pre-configured bootstrap addresses may be used to discover an initial set of nodes. The user © 2009 by Taylor & Francis Group, LLC P2P SIP: Network Architecture and Resource Location Strategy Super-node in DHT Ordinary node FIGURE 9.7 P2P network architecture for SIP-based IP telephony system. Discover On Startup User interface (busy li