1. P2P-SIP Peer to peer Internet telephony using SIP (Session Initiation Protocol) Kundan Singh and Henning Schulzrinne Columbia University, New York June 2005 http://www.cs.columbia.edu/IRT/p2p-sip

2. 2 Agenda Introduction What is SIP? Why P2P-SIP? Architecture Design choices: SIP using P2P vs P2P over SIP; Components that can be P2P Implementation Choice of P2P algorithm (DHT); Node join, leave; message routing Conclusions and future work

3. 3 What is SIP? Why P2P-SIP? Bob’s host Alice’s host 128.59.19.194 REGISTER alice@columbia.edu =>128.59.19.194 INVITE alice@columbia.edu Contact: 128.59.19.194 columbia.edu Client-server=> maintenance, configuration, controlled infrastructure P2P overlay Alice 128.59.19.194 REGISTER INVITE alice 128.59.19.194 No central server, search latency

4. 4 How to combine SIP + P2P? SIP-using-P2P Replace SIP location service by a P2P protocol P2P-over-SIP Additionally, implement P2P using SIP messaging P2P network Alice 128.59.19.194 INSERT INVITE sip:alice@128.59.19.194 P2P-SIP overlay Alice 128.59.19.194 REGISTER INVITE alice FIND

5. 5 P2P-over-SIP P2P algorithm over SIP without change in semantics No dependence on external P2P network Reuse and interoperate with existing components, e.g., voicemail Built-in NAT/media relays Message overhead

6. 6 What else can be P2P? Rendezvous/signaling (SIP) Configuration storage Media storage (e.g., voice mail) Identity assertion (?) Gateway (?) NAT/media relay (find best one)

7. 7 What is our P2P-SIP? Unlike server-based SIP architecture Unlike proprietary Skype architecture Robust and efficient lookup using DHT Interoperability DHT algorithm uses SIP communication Hybrid architecture Lookup in SIP+P2P Unlike file-sharing applications Data storage, caching, delay, reliability Disadvantages Lookup delay and security

8. 8 Background: DHT (Chord) Identifier circle Keys assigned to successor Evenly distributed keys and nodes Finger table: logN i th finger points to first node that succeeds n by at least 2 i-1 1 8 14 21 32 38 58 47 10 24 30 54 38 42 Keynode 8+1 = 914 8+2 = 1014 8+4 = 1214 8+8 = 1621 8+16=2432 8+32=4042 Find Map key to node Join, Leave, or Failure Update the immediate neighbors Successor and predecessor Stabilize: eventually propagate the info Reliability Log(N) successors; data replication

9. 9 Design Alternatives 65a1fc d13da3 d4213f d462ba d467c4 d471f1 d46a1c Route(d46a1c) 1 8 14 21 32 38 58 47 10 24 30 54 38 42 Use DHT in server farm Use DHT for all clients; But some are resource limited Use DHT among super-nodes 1. Hierarchy 2. Dynamically adapt servers clients 1 10 24 30 54 38

10. 10 Architecture User interface (buddy list, etc.)SIPICERTP/RTCPCodecsAudio devicesDHT (Chord) On startup DiscoverUser location Multicast REGISTERPeer found/ Detect NAT REGISTER REGISTER, INVITE, MESSAGE Signup, Find buddies Join Find Leave On reset Signout, transfer IM, call SIP-over-P2P P2P-using-SIP

11. 11 Node Startup SIP REGISTER with SIP registrar DHT Discover peers: multicast REGISTER SLP, bootstrap, host cache Join DHT using node-key=Hash(ip) Query its position in DHT Update its neighbors Stabilization: repeat periodically User registers using user- key=Hash(alice@columbia.edu) alice@columbia.edu REGISTER DB sipd Detect peers columbia.edu 14 32 58 12 42 REGISTER alice=42 REGISTER bob=12

12. 12 Node Leaves Chord reliability Log(N) successors, replicate keys Graceful leave Un-REGISTER Transfer registrations Failure Attached nodes detect and re-REGISTER New REGISTER goes to new super-nodes Super-nodes adjust DHT accordingly DHT REGISTER key=42 OPTIONS 42 REGISTER

13. 13 Dialing Out (message routing) Call, instant message, etc. INVITE sip:hgs10@columbia.edu MESSAGE sip:alice@yahoo.com If existing buddy, use cache first If not found SIP-based lookup (DNS NAPTR, SRV,…) P2P lookup Use DHT to locate: proxy or redirect to next hop DHT Last seen INVITE key=42 302 42 INVITE

14. 14 Implementation sippeer : C++, Unix (Linux), Chord Node join and form the DHT Node failure is detected and DHT updated Registrations transferred on node shutdown 1 11 9 30 26 31 15 29 25 19 31 26

15. 15 Adaptor for existing phones Use P2P-SIP node as an outbound proxy ICE for NAT/firewall traversal STUN/TURN server in the node

16. 16 Hybrid architecture Cross register, or Locate during call setup DNS, or P2P-SIP hierarchy

17. 17 Advanced services Offline messages INVITE or MESSAGE fails: responsible node stores voicemail, instant message. Conferencing Three-party, full-mesh, multicast

18. 18 Performance prediction Scalability #messages = f(refresh-rate, call arrival, join/leave/failure rate) M={r s + r f (log(N)) 2 } + c.log(N) + (k/t)log(N) + (log(N)) 2 /N User availability f(failure, refresh-rate, replication) Call setup latency f(availability, retransmission timers) Known buddies; DHT optimizations

19. 19 More open issues (further study) Security Anonymity, encryption, Attack/DOS-resistant, SPAM-resistant Malicious node Protecting voicemails from storage nodes Optimization Locality, proximity, media routing Deployment SIP-P2P vs P2P-SIP, Intra-net, ISP servers Motivation Why should I run as super-node?

20. 20 Conclusions P2P useful for VoIP Scalable, reliable No configuration Not as fast as client/server P2P-SIP Basic operations easy Implementation sippeer : C++, Linux Interoperates Some potential issues Security Performance (?) C C C C C S P P P P P 427 763 135 365 123 324324 564564 364 65a1fc d13da3 d4213f d462ba d467c4 d471f1 d46a1c Route(d46a1c) http://www.cs.columbia.edu/IRT/p2p-sip

21. Backup slides

22. 22 What is P2P? Share the resources of individual peers CPU, disk, bandwidth, information, … C C C C C S P P P P P Computer systems CentralizedDistributed Client-server Peer-to-peer FlatHierarchicalPureHybrid mainframes workstations DNS mount RPC HTTP Gnutella Chord Napster Groove Kazaa File sharing Communication and collaboration Distributed computing SETI@Home folding@Home Napster Gnutella Kazaa Freenet Overnet Magi Groove Skype

23. 23 Naming and authentication SIP URI as node and user identifiers Known node: sip:15@192.2.1.3 Unknown node: sip:17@example.com User: sip:alice@columbia.edu User name is chosen randomly by the system, by the user, or as user’s email Email the randomly generated password TTL, security

24. 24 SIP messages DHT (Chord) maintenance Query the node at distance 2 k with node id 11 REGISTER To: From: SIP/2.0 200 OK To: Contact: ; predecessor=sip:10@128.59.15.55 Update my neighbor about me REGISTER To: Contact: ; predecessor=sip:1@128.59.15.60 1 10 15 22 Find(11) gives 15 7

25. 25 SIP messages User registration REGISTER To: sip:alice@columbia.edu Contact: sip:alice@128.59.19.194:8094 Call setup and instant messaging INVITE sip:bob@example.com To: sip:bob@example.com From: sip:alice@columbia.edu

26. 26 Distributed Hash Tables Types of search Central index (Napster) Distributed index with flooding (Gnutella) Distributed index with hashing (Chord) Basic operations find(key), insert(key, value), delete(key), no search(*) Properties/typesEvery peer has complete table Every peer has one key/value Search time or messages O(1)O(n) Join/leave messagesO(n)O(1)

27. 27 Chord Identifier circle Keys assigned to successor Evenly distributed keys and nodes 1 8 14 21 32 38 58 47 10 24 30 54 38 42 0 1 2 3 4 5 6 7 8

28. 28 Chord Finger table: logN i th finger points to first node that succeeds n by at least 2 i-1 Stabilization after join/leave 1 8 14 21 32 38 58 47 10 24 30 54 38 42 Keynode 8+1 = 914 8+2 = 1014 8+4 = 1214 8+8 = 1621 8+16=2432 8+32=4042

29. 29 Comparison Property/ scheme Un- structured CANChordTapestryPastryViceroy RoutingO(N) or no guarantee d x N 1/d log(N)log B N log(N) StateConstant2dlog(N)log B NB.log B Nlog(N) Join/leaveConstant2d(logN) 2 log B N log(N) Reliability and fault resilience Data at Multiple locations; Retry on failure; finding popular content is efficient Multiple peers for each data item; retry on failure; multiple paths to destination Replicate data on consecutive peers; retry on failure Replicate data on multiple peers; keep multiple paths to each peers Routing load is evenly distributed among participant lookup servers

30. 30 Server-based vs peer-to-peer Reliability, failover latency DNS-based. Depends on client retry timeout, DB replication latency, registration refresh interval DHT self organization and periodic registration refresh. Depends on client timeout, registration refresh interval. Scalability, number of users Depends on number of servers in the two stages. Depends on refresh rate, join/leave rate, uptime Call setup latency One or two steps.O(log(N)) steps. SecurityTLS, digest authentication, S/MIME Additionally needs a reputation system, working around spy nodes Maintenance, configuration Administrator: DNS, database, middle-box Automatic: one time bootstrap node addresses PSTN interoperability Gateways, TRIP, ENUMInteract with server-based infrastructure or co-locate peer node with the gateway

31. 31 Related work: Skype From the KaZaA community Host cache of some super nodes Bootstrap IP addresses Auto-detect NAT/firewall settings STUN and TURN Protocol among super nodes – ?? Allows searching a user (e.g., kun*) History of known buddies All communication is encrypted Promote to super node Based on availability, capacity Conferencing P P P P P P P P P PPP

32. 32 Reliability and scalability Two stage architecture for CINEMA MasterSlaveMasterSlave sip:bob@example.com sip:bob@b.example.com s1 s2 s3 a1 a2 b1 b2 a*@example.com b*@example.com example.com _sip._udp SRV 0 40 s1.example.com SRV 0 40 s2.example.com SRV 0 20 s3.example.com SRV 1 0 ex.backup.com a.example.com _sip._udp SRV 0 0 a1.example.com SRV 1 0 a2.example.com b.example.com _sip._udp SRV 0 0 b1.example.com SRV 1 0 b2.example.com Request-rate = f(#stateless, #groups) Bottleneck: CPU, memory, bandwidth? Failover latency: ? ex

33. 33 Related work P2P P2P networks Unstructured (Kazaa, Gnutella,…) Structured (DHT: Chord, CAN,…) Skype and related systems Flooding based chat, groove, Magi P2P-SIP telephony Proprietary: NimX, Peerio, File sharing: SIPShare

34. 34 Why we chose Chord? Chord can be replaced by another As long as it can map to SIP High node join/leave rates Provable probabilistic guarantees Easy to implement X proximity based routing X security, malicious nodes

35. 35 Related work JXTA vs Chord in P2P-SIP JXTA Protocol for communication (peers, groups, pipes, etc.) Stems from unstructured P2P P2P-SIP Instead of SIP, JXTA can also be used Separate search (JXTA) from signaling (SIP)

36. 36 Find(user) Option-1: No REGISTER Node computes key based on user ID Nodes join the overlay based on ID One node  one user Option-2: With REGISTER REGISTERs with nodes responsible for its key Refreshes periodically Allows offline messages (?) 12 24 42 14 32 58 12 24 56 42 REGISTER alice=42 REGISTER bob=12 alice=42 sam=24 bob=12

37. 37 P2P-SIP Security – open issues (threats, solutions, issues) More threats than server-based Privacy, confidentiality Malicious node Don’t forward all calls, log call history (spy),… “free riding”, motivation to become super-node Existing solutions Focus on file-sharing (non-real time) Centralized components (boot-strap, CA) Assume co-operating peers ( works for server farm in DHT Collusion Hide security algorithm (e.g., yahoo, skype) Chord Recommendations, design principles, …

38. 38 P2P so far… ApplejuiceApplejuice network Applejuice Client BitTorrentBitTorrent network ABC Azureus BitAnarch BitComet BitSpirit BitTornado BitTorrent BitTorrent++ BitTorrent.Net G3 Torrent mlMac MLDonkey QTorrent SimpleBT Shareaza TomatoTorrentTomatoTorrent (Mac OS X)Mac OS X TorrentStorm CAKECAKE network BirthdayCAKE Direct ConnectDirect Connect network BCDC++ CZDC++ DC++ NeoModus Direct Connect JavaDC DCGUI-QT GnutellaGnutella network AcquisitionxAcquisitionx (Mac OS X)Mac OS X BearShare BetBug Cabos CocoGnutCocoGnut (RISC OS)RISC OS Gnucleus Grokster iMesh Light gtk-gnutellagtk-gnutella (Unix)Unix LimeWireLimeWire (Java)Java MLDonkey mlMac Morpheus Phex Poisoned Swapper Shareaza XoloX Gnutella2Gnutella2 network Adagio Caribou Gnucleus iMesh Light MLDonkey mlMac Morpheus Shareaza TrustyFiles HyperCast Joltid PeerEnabler Altnet Bullguard Joltid KazaaKazaa, Kazaa LiteKazaa Lite eDonkeyeDonkey network aMuleaMule (Linux)Linux eDonkey client (no longer supported) eMule LMule MindGem MLDonkey mlMac Shareaza xMule iMesh Light ed2ked2k (eDonkey 2000 protocol) eDonkey eMule xMule aMule Shareaza FastTrackFastTrack protocol giFT Grokster iMeshiMesh, iMesh LightiMesh Light KazaaKazaa, Kazaa Lite, K++, Diet Kaza, CleanKazaaKazaa LiteK++Diet KazaCleanKazaa Mammoth MLDonkey mlMac Poisoned FreenetFreenet network Entropy Freenet Frost KademliaKademlia protocol eMule MindGem MLDonkey MANOLITOMANOLITO/MP2P network Blubster Piolet RockItNet NapsterNapster network Napigator OpenNap WinMX PeercastingPeercasting type networks PeerCast IceShare Freecast WPNPWPNP network WinMX other networks Akamai Alpine ANts P2P Ares Galaxy AudiogalaxyAudiogalaxy network Carracho Chord The Circle Coral[5]Coral[5] Dexter Diet-Agents EarthStation 5EarthStation 5 network Evernet FileTopia GNUnet Grapevine Groove Hotwire iFolder[6] konspire2b Madster/Aimster MUTE Napshare OpenFT Poisoned P-Grid[7] IRCIRC @find XDCC@findXDCC JXTA PeersitesPeersites [8][8] MojoNation Mnet OvernetOvernet network Scour Scribe Skype Solipsis SongSpySongSpy network Soulseek SPIN SpinXpress SquidCamSquidCam [9][9] Swarmcast WASTE Warez P2P Winny