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

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

3. 3 What is P2P? Share the resources of individual peers CPU, disk, bandwidth, information, … C C C C C S P P P P P Computer systems CentralizedDistributed Client-server Peer-to-peer FlatHierarchicalPureHybrid 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

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

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

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

7. 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. 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. 9 Background: DHT (Chord) Identifier circle Keys assigned to successor Evenly distributed keys and nodes Finger table: logN i th finger points to first node that succeeds n by at least 2 i-1 1 8 14 21 32 38 58 47 10 24 30 54 38 42 Keynode 8+1 = 914 8+2 = 1014 8+4 = 1214 8+8 = 1621 8+16=2432 8+32=4042 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

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

11. 11 Architecture User interface (buddy list, etc.)SIPICERTP/RTCPCodecsAudio devicesDHT (Chord) On startup DiscoverUser location Multicast REGISTERPeer found/ Detect NAT REGISTER REGISTER, INVITE, MESSAGE Signup, Find buddies Join Find Leave On reset Signout, transfer IM, call SIP-over-P2P P2P-using-SIP

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

14. 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. 15 Implementation sippeer : C++, Unix (Linux), Chord Node join and form the DHT Node failure is detected and DHT updated Registrations transferred on node shutdown 1 11 9 30 26 31 15 29 25 19 31 26

16. 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. 17 Hybrid architecture Cross register, or Locate during call setup DNS, or P2P-SIP hierarchy

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

19. 19 Performance prediction Scalability #messages = f(refresh-rate, call arrival, join/leave/failure rate) M={r s + r f (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. 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. 21 P2P vs server-based server-basedP2P scalingserver count  scales with user count, but limited by supernode count efficiencymost efficientDHT maintenance = O((log N) 2 ), lookup = O(logN) securitytrust server provider; binary trust most supernodes; probabilistic reliabilityserver redundancy; catastrophic failure possible unreliable supernodes; catastrophic failure unlikely

22. 22 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 (?) C C C C C S P P P P P 427 763 135 365 123 324324 564564 364 65a1fc d13da3 d4213f d462ba d467c4 d471f1 d46a1c Route(d46a1c) http://www.cs.columbia.edu/IRT/p2p-sip

23. Backup slides

24. 24 Server-based vs peer-to-peer Reliability, failover latency DNS-based. Depends on client retry timeout, DB replication latency, registration refresh interval DHT self organization and periodic registration refresh. Depends on client timeout, registration refresh interval. Scalability, number of users Depends on number of servers in the two stages. Depends on refresh rate, join/leave rate, uptime Call setup latency One or two steps.O(log(N)) steps. SecurityTLS, digest authentication, S/MIME Additionally needs a reputation system, working around spy nodes Maintenance, configuration Administrator: DNS, database, middle-box Automatic: one time bootstrap node addresses PSTN interoperability Gateways, TRIP, ENUMInteract with server-based infrastructure or co-locate peer node with the gateway

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

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

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

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

30. 30 P2P-SIP Security – 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, …