1 / 29

Reliable and Scalable Internet Telephony

Reliable and Scalable Internet Telephony. Kundan Singh and Henning Schulzrinne Internet Real Time Lab – Internal Talk Sept 24, 2004. database (SCP) 10 million customers 2 million lookups/hour. database (SCP) for freephone, calling card, ….

umed
Download Presentation

Reliable and Scalable Internet Telephony

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. Reliable and Scalable Internet Telephony Kundan Singh and Henning Schulzrinne Internet Real Time Lab – Internal Talk Sept 24, 2004

  2. database (SCP)10 million customers 2 million lookups/hour database (SCP)for freephone, calling card, … local telephone switch(class 5 switch)10,000 customers 20,000 calls/hour signaling router (STP)1 million customers 1.5 million calls/hour signaling network (SS7) signaling router(STP) regional telephone switch(class 4 switch)100,000 customers 150,000 calls/hour Telephone reliability(PSTN: Public Switched Telephone Network) “bearer” network telephone switch(SSP)

  3. REGISTER INVITE INVITE DNS Internet telephony(SIP: Session Initiation Protocol) alice@yahoo.com yahoo.com example.com bob@example.com 129.1.2.3 192.1.2.4 DB

  4. IP PSTN SIP network architectureScalability requirement depends on role Cybercafe ISP IP network IP phones GW ISP MG MG SIP/MGC SIP/PSTN GW SIP/MGC Carrier network MG GW PBX T1 PRI/BRI PSTN phones PSTN

  5. Reliability and scalabilityfor call routing, registration, conferencing, voicemails • Requirements • Reliable • Mean Time Between Failures (MTBF), Mean Time To Recover (MTTR) • Scalable • Registration rate, call rate, #requests/s • Proposed solutions • Server redundancy • Apply existing web-redundancy designs • Evaluate quantitatively (future work) • Peer-to-peer • Novel P2P-SIP architecture • Evaluate quantitatively (future work)

  6. Server redundancyThe problem: failure or overload INVITE REGISTER

  7. Server redundancyReplicate registration or search on call INVITE REGISTER INVITE REGISTER

  8. Server redundancyKnown techniques • Client-based • Cisco phones: primary and backup proxy • DNS • NAPTR, SRV • IP address takeover • Database redundancy • . . .

  9. High availabilityFailover in CINEMA Web scripts Web scripts D1 D2 Master/ slave Slave/ master replication P1 P2 phone.cs.columbia.edu sip2.cs.columbia.edu REGISTER _sip._udp SRV 0 0 5060 phone.cs.columbia.edu SRV 1 0 5060 sip2.cs.columbia.edu proxy1 = phone.cs backup = sip2.cs

  10. High availabilityTime to recover • Client re-sends INVITE to P2 • Immediately on ICMP error • Or after 10s otherwise • sipd has in-memory cache • Refresh registration much before expiry • Registrations are additive • Measurement of recovery time • Optimal #servers

  11. REGISTER INVITE ScalabilityLoad sharing: redundant proxies and databases • REGISTER • Write to D1 & D2 • INVITE • Read from D1 or D2 • Database write/ synchronization traffic becomes bottleneck P1 D1 P2 D2 P3

  12. ScalabilityLoad sharing: divide the user space • Proxy and database on the same host • Stateless proxy can become overloaded • Hashing • Static vs dynamic P1 D1 a-h P2 D2 i-q P3 D3 r-z

  13. ((tr/D)+1)TN = (A/D) + B ((tr+1)/D)TN = (A/D) + (B/D) ScalabilityComparison of the two designs P1 P1 a-h D1 D1 P2 P2 i-q D2 D2 P3 P3 D2 r-z Total time per DB D = number of database servers N = number of writes (REGISTER) r = #reads/#writes = (INV+REG)/REG ~ 2 T = write latency t = read latency/write latency

  14. Master Slave Master Slave Reliability and scalabilityTwo stage architecture for CINEMA a*@example.com a.example.com _sip._udp SRV 0 0 a1.example.com SRV 1 0 a2.example.com a1 s1 a2 sip:bob@example.com s2 sip:bob@b.example.com b*@example.com b.example.com _sip._udp SRV 0 0 b1.example.com SRV 1 0 b2.example.com s3 b1 b2 example.com _sip._udp SRV 0 0 s1.example.com SRV 0 0 s2.example.com SRV 0 0 s3.example.com SRV 1 0 ex.backup.com Request-rate = f(#stateless, #groups) Bottleneck: CPU, memory, bandwidth? Failover latency: ?

  15. C C P P S C C P P C P Server-based vs peer-to-peer • Server-based • Cost: maintenance, configuration • Central points of failures • Controlled infrastructure (e.g., DNS) • Peer-to-peer • Robust: no central dependency • Self organizing, no configuration • Scalability ?

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

  17. We propose: 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

  18. P2P-SIPBackground: 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

  19. d471f1 1 d467c4 d46a1c 8 d462ba 58 54 d4213f 14 10 47 21 Route(d46a1c) d13da3 42 38 32 65a1fc 38 24 30 P2P-SIPDesign 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

  20. Discover DHT (Chord) User location Audio devices User interface (buddy list, etc.) ICE RTP/RTCP Codecs SIP P2P-SIPNode architecture: registrar, proxy, user agent • DHT communication using SIP REGISTER • Known node: sip:15@192.2.1.3 • Unknown node: sip:17@sippeer.net • User: sip:alice@example.com Signup, Find buddies IM, call On reset Signout, transfer On startup Leave Find Join REG, INVITE, MESSAGE Peer found/ Detect NAT Multicast REG REG

  21. sipd DB P2P-SIPNode Startup columbia.edu • SIP • REGISTER with SIP registrar • DHT • Discover peers: multicast REGISTER • Join DHT using node-key=Hash(ip) • REGISTER with DHT using user-key=Hash(alice@columbia.edu) • Dialing out • Call, instant message, etc. INVITE sip:hgs10@columbia.edu MESSAGE sip:alice@example.com • Last seen, SIP NAPTR/SRV, DHT REGISTER alice@columbia.edu Detect peers REGISTER alice=42 58 42 12 14 REGISTER bob=12 32

  22. P2P-SIPNode Leaves • 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

  23. 1 30 26 9 19 11 P2P-SIPImplementation 31 • sippeer: C++, Unix (Linux), Chord • Node join and form the DHT • Node failure is detected and DHT updated • Registrations transferred on node shutdown • Co-located sipc can use sippeer service 29 31 25 26 15

  24. P2P-SIPEvaluation • #super-nodes needed depends on • Registration refresh rate, replication • Join/leave rate, uptime • Call arrival rate • CPU, memory, bandwidth limits • Other metrics • Call setup latency • Recovery time after super-node failure

  25. P2P-SIPAdvanced services and open issues • Offline messages • INVITE or MESSAGE fails => Responsible node stores voicemail, instant message. • Conferencing • Mixer, full mesh, multicast • Open issues • P2P reputation system • Motivation to become super node • Security (SPAM, DOS, spy, …) • . . .

  26. Server-based vs peer-to-peer

  27. Summary • Motivation • PSTN is reliable and scalable • Can IP telephony do better? • Server-based • DNS, stateless, DB replication, two stage • Peer-to-peer • SIP, DHT, soft state, self organizing

  28. SIP VXML Web server Beyond proxy/registrarCINEMA: Columbia InterNet Extensible Multimedia Architecture CINEMA servers Telephone switch rtspd: media server Local/long distance 1-212-5551212 sipconf: Conference server Quicktime RTSP PSTN RTSP clients Department PBX sipum: Unified messaging sipd: Proxy, redirect, Registrar server Internal Telephone Extn: 7040 713x SQL database cgi SIP/PSTN Gateway vxml Web based configuration H.323 siph323: SIP-H.323 translator NetMeeting

  29. Communication to collaboration • Synchronous (tightly coupled) • Video conference, IM, screen sharing, … • Asynchronous (loosely coupled) • File sharing, message board, … • Messaging and notifications • Personalized view • Per-user calendar, access control, address book Goal: provide personalized access, alternate between synchronous and asynchronous communication, and access from different devices and clients.

More Related