1. P2P-SIP Using an External P2P network (DHT)
Data model
Treat DHT as database
Service model
Join DHT to provide service
[5]
bob
bob
[3]
[1]
[2]
[1]
[3]
DHT
DHT
Service
node
( )
[4]
There are two approaches to do the P2P-SIP operations. In the data model, the DHT is treated as a database with put, get, remove API, and performs all operations using this. In the service model, the every P2P-SIP node joins the DHT as a service node and serves as registrar, proxy, presence agent and STUN/TURN server for other nodes. It uses lookup, join and leave API.
It is possible to layer them on one another: data model on top of service model is straight forward. Additionally OpenDHT shows that service model on top of data model is also possible using the ReDiR interface.
[2]
[5]
alice
alice
[1] join( )
[2] lookup(H(bob)) gives
[3] REGISTER sip:bob to
[4] lookup(H(bob)) gives
[5] INVITE sip:bob to
[1] put(k, ), k is H(bob)
[2] get(k) gives
[3] INVITE sip:bob to

2. P2P-SIP Logical Operations
Contact management
put (user id, signed contact)
Key storage
User certificates and private configurations
Presence
put (subscribee id, signed encrypted subscriber id)
Composition needs service model
Offline message
put (recipient, signed encrypted message)
NAT and firewall traversal
STUN and TURN server discovery needs service model
P2P-SIP design consists of many logical operations. The contact management deals with storing and retrieving user contacts as in SIP location service. The contacts are signed by the user on put and verified on get before making a call. Key storage deals with storing the certificate and encrypted private key of the user. The caller uses this certificate to verify. Presence deals with the subscribers updating the watcher list of the given subscribee such that only he can read the identifiers of the subscribers. Similarly, offline message deals with putting the signed and encrypted messages for the recipient such that only he can read and delete it. For NAT and firewall traversal, it provides P2P service discovery of a STUN or TURN server.

3. P2P-SIP Implementation in SIPc
OpenDHT
Trusted nodes
Robust
Fast enough (<1s)
Identity protection
Certificate-based
SIP id ==
P2P for
Calls, IM, presence, offline message, STUN server discovery and name search
We have implemented P2P-SIP in our multimedia collaboration client, sipc, using OpenDHT running on Planetlab with about 200 nodes. The advantage of using an externally managed DHT is that we can trust to some extent that the nodes are not malicious and perform the DHT operations (get/put) correctly. Thus the security problem is mostly avoided. The identity protection is provided using a well known CA such as ours which gives out the certificate to the user for her address, so that the user can securely use her address as the SIP identifier in P2P-SIP. The implementation includes the P2P modes for calls, IM, presence, offline message storage, STUN server discovery and name search (find the user identifier for “Firstname Lastname”)
OpenDHT is robust and fast enough for our needs. Lookups on an average take less than a second. We implemented redundancy and failover so that if one OpenDHT node is unavailable it uses another randomly choosen closer node.

4. P2P-SIP What is OpenDHT?
Service model, unlike earlier library of Chord/CAN
DHT accessed on SunRPC & XML-RPC
Easy deployment and maintenance
Bamboo DHT nodes on PlanetLab
Public DHT service running since April 2004
Many existing applications: i3, CFS, Ostream, HIP,…
DHT API (server side on Bamboo nodes)
Put(key,value,H(secret),ttl) where H is SHA1
Get(key)=>(value,H(secret),remaining-ttl)
Remove(key,H(value),secret,ttl)
ReDiR API (client side for lookup/join/leave)
Can build anycast, multicast, range search using this
Fair resource (disk) allocation among clients (IP addr)
OpenDHT.org and Sean Rhea’s SIGCOMM paper has more information. OpenDHT is a public DHT service developed by MIT. Unlike earlier approaches of application building which incorporated various DHTs such as Chord/CAN/Pastry as a library in the application, they provide a separate DHT service. The service is accessed using RPC and avoids maintenance by the application as the DHT maintenance is done independently. The community of developers using OpenDHT is continuously growing with about 12 applications deployed by Aug 2005.
Providing a DHT service involves (1) writing a DHT with generic and flexible interface (get/put/anycast/multicast) (2) sharing among public applications and clients means need to be fair in terms of CPU and disk. OpenDHT has a client side API for lookup/join so that application and provide any service beyond using get/put for data storage. Fair allocation requires use of a TTL, and quota per client (IP address). Their novel approach makes sure that disk is always available for new put. One problem is that DHCP users with new IP address get more share whereas NAT users with single IP have lower share.