P2P-SIP Using an External P2P network (DHT) Data model Treat DHT as database Service model Join DHT to provide service [5] bob 192.1.2.3 bob [3] [1] [2] [1] [3] DHT DHT Service node (128.3.4.5) [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(128.3.4.5) [2] lookup(H(bob)) gives 128.3.4.5 [3] REGISTER sip:bob to 128.3.4.5 [4] lookup(H(bob)) gives 128.3.4.5 [5] INVITE sip:bob to 128.3.4.5 [1] put(k,192.1.2.3), k is H(bob) [2] get(k) gives 192.1.2.3 [3] INVITE sip:bob to 192.1.2.3

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.

P2P-SIP Implementation in SIPc OpenDHT Trusted nodes Robust Fast enough (<1s) Identity protection Certificate-based SIP id == email 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 email address, so that the user can securely use her email 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.

P2P-SIP What is OpenDHT? Service model, unlike earlier library of Chord/CAN DHT accessed on SunRPC & XML-RPC Easy deployment and maintenance 200-300 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.