1 / 38

P2P-SIP Peer to peer Internet telephony using SIP (Session Initiation Protocol)

This article discusses the use of SIP (Session Initiation Protocol) in a peer-to-peer (P2P) architecture for internet telephony. It explores the architecture, design choices, implementation, and benefits of P2P-SIP. The article also covers the use of P2P algorithms and messaging in conjunction with SIP.

vincentv
Download Presentation

P2P-SIP Peer to peer Internet telephony using SIP (Session Initiation Protocol)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. P2P-SIPPeer 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. 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 Agenda

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

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

  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. 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. 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. Background: DHT (Chord) • Identifier circle • Keys assigned to successor • Evenly distributed keys and nodes • Finger table: logN • ith finger points to first node that succeeds n by at least 2i-1 1 54 8 58 10 14 47 21 • 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 42 38 32 38 24 30

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

  10. Discover DHT (Chord) User location Audio devices User interface (buddy list, etc.) ICE RTP/RTCP Codecs SIP Architecture Signup, Find buddies IM, call On reset Signout, transfer On startup Leave Find Join REGISTER, INVITE, MESSAGE Peer found/ Detect NAT Multicast REGISTER REGISTER SIP-over-P2P P2P-using-SIP

  11. sipd DB Node Startup columbia.edu • 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) REGISTER alice@columbia.edu Detect peers REGISTER alice=42 58 42 12 14 REGISTER bob=12 32

  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 REGISTER key=42 REGISTER OPTIONS DHT 42 42

  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 INVITE key=42 Last seen 302 INVITE DHT 42

  14. 1 30 26 9 19 11 Implementation 31 • sippeer: C++, Unix (Linux), Chord • Node join and form the DHT • Node failure is detected and DHT updated • Registrations transferred on node shutdown 29 31 25 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. Hybrid architecture • Cross register, or • Locate during call setup • DNS, or • P2P-SIP hierarchy

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

  18. Performance prediction • Scalability • #messages = f(refresh-rate, call arrival, join/leave/failure rate) M={rs+ rf(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. 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. d471f1 d467c4 d46a1c d462ba d4213f 763 427 C C P P S 364 123 Route(d46a1c) d13da3 324 C C P P 365 135 564 65a1fc C P 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 (?) http://www.cs.columbia.edu/IRT/p2p-sip

  21. Backup slides

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

  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. SIP messages 1 • DHT (Chord) maintenance • Query the node at distance 2k with node id 11 REGISTER To: <sip:11@example.invalid> From: <sip:7@128.59.15.56> SIP/2.0 200 OK To: <sip:11@example.invalid> Contact: <sip:15@128.59.15.48>; predecessor=sip:10@128.59.15.55 • Update my neighbor about me REGISTER To: <sip:1@128.59.15.60> Contact: <sip:7@128.59.15.56>; predecessor=sip:1@128.59.15.60 10 22 7 15 Find(11) gives 15

  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. 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(*)

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

  28. Chord • Finger table: logN • ith finger points to first node that succeeds n by at least 2i-1 • Stabilization after join/leave 1 54 8 58 10 14 47 21 42 38 32 38 24 30

  29. Comparison

  30. Server-based vs peer-to-peer

  31. P P P P P P P P P P P P 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

  32. Master Slave Master Slave Reliability and scalabilityTwo stage architecture for CINEMA a*@example.com a.example.com _sip._udp SRV 0 0 a1.example.com SRV 1 0 a2.example.com a1 s1 a2 sip:bob@example.com s2 sip:bob@b.example.com b*@example.com b.example.com _sip._udp SRV 0 0 b1.example.com SRV 1 0 b2.example.com s3 b1 b2 ex 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 Request-rate = f(#stateless, #groups) Bottleneck: CPU, memory, bandwidth? Failover latency: ?

  33. Related workP2P • 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. 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. Related workJXTA 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. 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 (?) Find(user) 56 REGISTER alice=42 58 42 alice=42 12 bob=12 42 14 12 REGISTER bob=12 32 24 24 sam=24

  37. P2P-SIPSecurity – 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. Applejuice network Applejuice Client BitTorrent network ABC Azureus BitAnarch BitComet BitSpirit BitTornado BitTorrent BitTorrent++ BitTorrent.Net G3 Torrent mlMac MLDonkey QTorrent SimpleBT Shareaza TomatoTorrent (Mac OS X) TorrentStorm CAKE network BirthdayCAKE Direct Connect network BCDC++ CZDC++ DC++ NeoModus Direct Connect JavaDC DCGUI-QT Gnutella network Acquisitionx (Mac OS X) BearShare BetBug Cabos CocoGnut (RISC OS) Gnucleus Grokster iMesh Light gtk-gnutella (Unix) LimeWire (Java) MLDonkey mlMac Morpheus Phex Poisoned Swapper Shareaza XoloX Gnutella2 network Adagio Caribou Gnucleus iMesh Light MLDonkey mlMac Morpheus Shareaza TrustyFiles HyperCast Joltid PeerEnabler Altnet Bullguard Joltid Kazaa, Kazaa Lite P2P so far… Kademlia protocol eMule MindGem MLDonkey MANOLITO/MP2P network Blubster Piolet RockItNet Napster network Napigator OpenNap WinMX Peercasting type networks PeerCast IceShare Freecast WPNP network WinMX other networks Akamai Alpine ANts P2P Ares Galaxy Audiogalaxy network Carracho Chord The Circle Coral[5] Dexter Diet-Agents EarthStation 5 network Evernet FileTopia GNUnet Grapevine Groove Hotwire iFolder[6] konspire2b Madster/Aimster MUTE Napshare OpenFT Poisoned P-Grid[7] IRC@findXDCC JXTA Peersites[8] MojoNation Mnet Overnet network Scour Scribe Skype Solipsis SongSpy network Soulseek SPIN SpinXpress SquidCam[9] Swarmcast WASTE Warez P2P Winny eDonkey network aMule (Linux) eDonkey client (no longer supported) eMule LMule MindGem MLDonkey mlMac Shareaza xMule iMesh Light ed2k (eDonkey 2000 protocol) eDonkey eMule xMule aMule Shareaza FastTrack protocol giFT Grokster iMesh, iMesh Light Kazaa , Kazaa Lite, K++, Diet Kaza, CleanKazaa Mammoth MLDonkey mlMac Poisoned Freenet network Entropy Freenet Frost

More Related