1 / 30

P2P-SIP Peer to peer Internet telephony using SIP

P2P-SIP Peer to peer Internet telephony using SIP. Kundan Singh and Henning Schulzrinne Columbia University, New York June 2005 http://www.cs.columbia.edu/IRT/p2p-sip. Introduction What is P2P? and SIP? Why P2P-SIP? Architecture SIP using P2P vs P2P over SIP; Components that can be P2P

jgreenberg
Download Presentation

P2P-SIP Peer to peer Internet telephony using SIP

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 Kundan Singh and Henning Schulzrinne Columbia University, New York June 2005 http://www.cs.columbia.edu/IRT/p2p-sip

  2. Introduction What is P2P? and SIP? Why P2P-SIP? Architecture SIP using P2P vs P2P over SIP; Components that can be P2P Implementation Choice of P2P (DHT); Node join, leave; message routing Conclusions and future work Overview Total 33 slides

  3. 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, …

  4. Resource aggregation - CPU, disk, … Cost sharing/reduction Improved scalability/reliability Interoperability - heterogeneous peers Increased autonomy at the network edge Anonymity/privacy Dynamic (join, leave), self organizing Ad hoc communication and collaboration Definition fuzzy both client and server? true for proxy no need for central server true for SIP-based media SIP can be e2e proxy functions distributed among end systems P2P goals

  5. Distributed Hash Table (DHT) • 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), but no search(*)

  6. REGISTER INVITE alice P2P overlay Alice 128.59.19.194 128.59.19.194 No central server, search latency 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

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

  8. SIP-using-P2P • Reuse optimized and well-defined external P2P network • Define P2P location service interface to be used in SIP • Extends to other signaling protocols

  9. 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

  10. What else can be P2P? • Rendezvous/signaling • Configuration storage • Media storage • Identity assertion (?) • Gateway (?) • NAT/media relay (find best one)

  11. Our P2P-SIP approach • 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

  12. 0 1 2 3 4 5 6 7 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 • Stabilization for join/leave 1 54 8 58 10 14 47 21 42 38 32 38 24 30

  13. 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

  14. Discover DHT (Chord) User location Audio devices User interface (buddy list, etc.) ICE RTP/RTCP Codecs SIP Architecture of prototype 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

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

  22. Hybrid (federated) architecture • Cross register, or • Locate during call setup • DNS, or • P2P-SIP hierarchy

  23. Evaluationscalability • #messages depends on • Keep-alive and finger table refresh rate • Call arrival distribution • User registration refresh interval • Node join, leave, failure rates M={rs+ rf(log(N))2} + c.log(N) + (k/t)log(N) + (log(N))2/N • #nodes = f(capacity,rates) • CPU, memory, bandwidth • Verify by measurement and profiling

  24. Evaluationreliability and call setup latency • User availability depends on • Super-node failure distribution • Node keep-alive and finger refresh rate • User registration refresh rate • Replicate user registration • Measure effect of each • Call setup latency • Same as DHT lookup latency: O(log(N)) • Calls to known locations (“buddies”) is direct • DHT optimization can further reduce latency • User availability and retransmission timers • Measure effect of each

  25. P2P vs. server-based SIP • Prediction: • P2P for smaller & quick setup scenarios • Server-based for corporate and carrier • Need federated system • multiple p2p systems, identified by DNS domain name • with gateway nodes 2000 requests/second ≈7 million registered users

  26. Explosive growth (further study) • Cache replacement at super-nodes • Last seen many days ago • Cap on local disk usage (automatic) • Forcing a node to become super node • Graceful denial of service if overloaded • Switching between flooding, CAN, Chord, … • . . .

  27. 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?

  28. Comparison of P2P and server-based systems

  29. Catastrophic failure • Server redundancy is well-understood  can handle single-server failures • Catastrophic (system-wide) failure occurs when common element fails • Both server-based and P2P: • all servers crash based on client stimulus (e.g., common parser bug) • Traditional server-based system: • servers share same facility, power, OS, … • P2P system • less likely • share same OS?

  30. 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.p2psip.org/ http://www.cs.columbia.edu/IRT/p2p-sip

More Related