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

Overview Introduction Architecture Implementation 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 Total 33 slides

What is P2P? Share the resources of individual peers CPU, disk, bandwidth, information, … Computer systems Centralized Distributed Client-server Peer-to-peer Flat Hierarchical Pure Hybrid 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 Another category in the system is the infrastructure component, which defines what routing mechanism to use: Chord, CAN, etc. What are Groove and Magi? Groove: P2P system for office collaboration. Not clear how the user is detected, perhaps statically added by peers. Every peer in the group sees the same user space. Synchronized across all peers. All communications are signed. Proprietary. Magi: goal was to make it standards based such as HTTP, XML, WebDAV to provide document sharing and communication mechanism on the Internet. It uses dynamic DNS to register the Magi nodes/instances. All communications are signed. C S P

P2P goals Definition fuzzy both client and server? 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

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(*) Properties/types Every peer has complete table Chord Every peer has one key/value Search time or messages O(1) O(log(N)) O(n) Join/leave messages O(log(N)2)

Why P2P-SIP? P2P overlay Alice’s host 128.59.19.194 Bob’s host Alice 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 P2P overlay Alice 128.59.19.194 REGISTER INVITE alice No central server, search latency What we gain: Reliability, scalability. What we lose: bounds on INVITE. Search feature.

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

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

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

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

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

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 Key node 8+1 = 9 14 8+2 = 10 8+4 = 12 8+8 = 16 21 8+16=24 32 8+32=40 42 1 54 8 58 10 14 47 21 Lookup in finger table for the furthest node that precedes the key In a system with N nodes and K keys, with high probability, each node receives at most K/N keys each node maintains information about O(logN) other nodes lookups resolved with O(logN) hops No network locality. Replicas need to have explicit consistency. Optimizations: location: weight neighbor nodes by RTT. When routing choose the neighbor who is closer to destination with lowest RTT from me. Reduce path latency. Multiple physical nodes per virtual node. What if a node leaves? 42 38 0 1 2 3 4 5 6 7 8 32 38 24 30

Design alternatives Use DHT in server farm 1 8 14 21 32 38 58 47 10 24 30 54 42 65a1fc d13da3 d4213f d462ba d467c4 d471f1 d46a1c Route(d46a1c) 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

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

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

SIP messages DHT (Chord) maintenance 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 Contact: <sip:15@128.59.15.48>; predecessor=sip:10@128.59.15.55 Update my neighbor about me 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

SIP messages User registration Call setup and instant messaging 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

Node startup SIP DHT REGISTER with SIP registrar columbia.edu DB sipd 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 42 58 12 14 REGISTER bob=12 32

Node leaves Chord reliability Graceful leave Failure 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 DHT OPTIONS 42 42

Implementation sippeer: C++, Unix (Linux), Chord 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 1 31 30 25 26 26 9 19 11 15

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

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

Evaluation scalability #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

Evaluation reliability 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 Advanced services also possible. the ConChord system for certificate storage, the Tarzan system for anonymous communications, and the proposal to use Chord as replacement of standard DNS hierarchies by Cox, Muthitacharoen, and Morris -- this last proposal is most similar in spirit to your work

P2P vs. server-based SIP Prediction: Need federated system 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

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

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?

Comparison of P2P and server-based systems scaling server count  scales with user count, but limited by supernode count efficiency most efficient DHT maintenance = O((log N)2) security trust server provider; binary trust most supernodes; probabilistic reliability server redundancy; catastrophic failure possible unreliable supernodes; catastrophic failure unlikely

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?

Conclusions P2P useful for VoIP P2P-SIP 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 S P 427 763 135 365 123 324 564 364 65a1fc d13da3 d4213f d462ba d467c4 d471f1 d46a1c Route(d46a1c) http://www.p2psip.org/ http://www.cs.columbia.edu/IRT/p2p-sip