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 Dec 15, 2005 http://www.cs.columbia.edu/IRT/p2p-sip. Introduction What is P2P? and SIP? Why P2P-SIP? Architecture

darice
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 Dec 15, 2005 http://www.cs.columbia.edu/IRT/p2p-sip

  2. Introduction What is P2P? and SIP? Why P2P-SIP? Architecture Design choices: SIP using P2P vs P2P over SIP; Components that can be P2P Implementation Choice of P2P (DHT); Naming; adaptor; SIP message Conclusions Agenda

  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. (1) REGISTER (2) INVITE alice P2P overlay Alice 128.59.19.194 (3) 128.59.19.194 No central server, search latency What is SIP? Why P2P-SIP? (1) REGISTER alice@columbia.edu =>128.59.19.194 (2) INVITE alice@columbia.edu (3) Contact: 128.59.19.194 Alice’s host 128.59.19.194 Bob’s host columbia.edu Client-server=> maintenance, configuration, controlled infrastructure

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

  6. Deployment scenarios? P P P P P P P P P P P P P P P P2P database P2P proxies P2P clients Zero-conf server farm; Trusted servers and user identities Global OpenDHT; Clients or proxies can use; Trusted peers (?) Plug and play; May use adaptors; Untrusted peers Interoperate among these!

  7. What else can be P2P? • Rendezvous/signaling (SIP) • Configuration storage • Media storage (e.g., voice mail) • Identity assertion (?) • PSTN gateway (?) • NAT/media relay (find best one) Trust models are different for different components!

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

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

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

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

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

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

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

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

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

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

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

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

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

  21. P2P vs server-based

  22. 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 (C++, Linux) • Interoperates • Some potential issues • Security • Robustness • Performance (?) http://www.cs.columbia.edu/IRT/p2p-sip

  23. Backup slides

  24. Server-based vs peer-to-peer

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

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

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

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

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

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

More Related