PeertoPeer Internet Telephony using SIP Kundan Singh and

Peer-to-Peer Internet Telephony using SIP Kundan Singh and Henning Schulzrinne Columbia University, New York Sep 10, 2004

Agenda n Introduction n P 2 P-SIP architecture n n Design alternatives DHT (Chord) and SIP Node startup, peer discovery, node failure Advanced services n n n Client-server vs P 2 P for Vo. IP Related work: Skype Offline messages Conferencing Conclusions and future work Total 18 slides 2

SIP: Session Initiation Protocol REGISTER alice@columbia. edu =>128. 59. 194 INVITE alice@columbia. edu Contact: 128. 59. 194 Alice’s host 128. 59. 194 columbia. edu Bob’s host Client-server=> maintenance, configuration, controlled infrastructure FIND alice P 2 P overlay 128. 59. 194 JOIN Alice 128. 59. 194 No central server 3

P 2 P Advantages n n n n 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 4

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

We propose: P 2 P-SIP n n Unlike server-based SIP architecture Unlike proprietary Skype architecture n n Robust and efficient lookup using DHT Interoperability n n Hybrid architecture n n Lookup in SIP+P 2 P Unlike file-sharing applications n n DHT algorithm uses SIP communication Data storage, caching, delay, reliability Disadvantages n Lookup delay and security 6

Background: DHT (Chord) 1 54 8 58 10 14 47 21 32 38 14 8+2 = 10 14 8+4 = 12 14 8+8 = 16 21 8+16=24 32 8+32=40 42 n Finger table: log. N n 24 8+1 = 9 n n 38 node Identifier circle Keys assigned to successor Evenly distributed keys and nodes n 42 Key 30 n ith finger points to first node that succeeds n by at least 2 i-1 Stabilization for join/leave 7

Design Alternatives 1 54 58 servers 47 42 38 38 8 d 471 f 1 14 10 d 46 a 1 c 21 d 467 c 4 d 462 ba 1 54 d 4213 f 10 32 24 30 Route(d 46 a 1 c) d 13 da 3 65 a 1 fc 38 24 30 clients Use DHT in server farm Use DHT for all clients; But some are resource limited Use DHT among super-nodes 1. 2. Hierarchy Dynamically adapt 8

Architecture User interface (buddy list, etc. ) On reset Signout, transfer On startup Leave Discover Peer found/ Detect NAT ICE n Join Multicast REG Signup, Find buddies IM, call User location Find Audio devices DHT (Chord) REG SIP REG, INVITE, MESSAGE Codecs RTP/RTCP DHT communication using SIP REGISTER n n n Known node: sip: 15@192. 2. 1. 3 Unknown node: sip: 17@sippeer. net User: sip: alice@example. com 9

Node Startup columbia. edu sipd n REGISTER SIP n DB n alice@columbia. edu DHT n Detect peers n n REGISTER alice=42 42 REGISTER with SIP registrar Discover peers: multicast REGISTER Join DHT using node-key=Hash(ip) REGISTER with DHT using userkey=Hash(alice@columbia. edu) 58 12 14 REGISTER bob=12 32 10

Super-nodes n Initial bootstrap super-nodes n n When to become super-node n REGISTER key=42 n n REGISTER n n Local decision; can be influenced by existing peer If REGISTER received n DHT Never allow capacity to exceed Local key => store locally Else, forward REGISTER to appropriate nodes Super-node refreshes REGISTER on behalf Should be in “public” address space (? ) 42 11

Node Leaves n Graceful leave n REGISTER key=42 n n REGISTER 42 Failure n OPTIONS DHT n n 42 Un-REGISTER Transfer registrations Attached nodes detect and re-REGISTER New REGISTER goes to new super-nodes Super-nodes adjust DHT accordingly 12

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

Offline messages n INVITE or MESSAGE fails n n n Responsible node stores voicemail, instant message. Delivered using MWI or when online detected Replicate the message at redundant nodes Sequence number prevents duplicates Security: How to avoid spies? How to recover if all responsible nodes leave? 14

Conferencing (further study) n One member becomes mixer n n n Fully distributed n n Centralized conferencing What if mixer leaves? Many to many signaling and media Application level multicast n Small number of senders 15

Explosive growth (further study) n Cache replacement at super-nodes n n n 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, …. . . 16

More open issues (further study) n Security n n n Optimization n n Anonymity, encryption, Attack/DOS-resistant, SPAM-resistant Malicious node Protecting voicemails from storage nodes Locality, proximity Motivation n Why should I run as super-node? 17

Conclusions C C S C C P P n 763 d 46 a 1 c 364 Route(d 46 a 1 c) 365 d 471 f 1 d 467 c 4 d 462 ba d 4213 f 324 135 n P 123 P 2 P useful for Vo. IP n C 427 n n Scalable, reliable No configuration Not as fast as client/server P 2 P-SIP n Basic operations easy n d 13 da 3 65 a 1 fc Implementation n 564 n n sippeer: C++, Linux Interoperates Some potential issues n n Security Performance 18