Backup slides My contributions n Server redundancy n

Backup slides

My contributions n Server redundancy n n Peer-to-peer (P 2 P) n n n Implemented failover using database replication Two-stage architecture for SIP load sharing Comparison of thread models for SIP servers using external P 2 P network Additionally, P 2 P maintenance using SIP Enterprise IP telephony n n n Multi-platform collaboration using SIP Scalable centralized conferencing architecture Interworking between SIP/SDP and H. 323 New architecture, New algorithm or approach, Implementation, Evaluation 2

Server redundancy The problem: failure or overload INVITE REGISTER 3

Scalability Load sharing: redundant proxies and databases P 1 n REGISTER n D 1 n n D 2 P 3 Write to D 1 & D 2 INVITE n P 2 INVITE REGISTER Read from D 1 or D 2 Database write/ synchronization traffic becomes bottleneck 4

Scalability Load sharing: divide the user space P 1 a-h n D 1 n P 2 i-q D 2 Proxy and database on the same host Stateless proxy can become overloaded n Use many P 3 r-z D 3 5

Server performance Results of my measurement n n Event-based performs 30% better than existing thread-pool architecture on single-CPU Two stage thread-pool architecture gives better performance on multi-CPU n n 60% more on 4 x. Pentium Both Pentium and Sparc took 2 MHz of CPU cycles per call/s on single-CPU 6

How to combine SIP + P 2 P? n SIP-using-P 2 P n n Replace SIP location service by a P 2 P protocol P 2 P-over-SIP n Additionally, implement P 2 P using SIP messaging SIP-using-P 2 P SIP proxies P 2 P-over-SIP Maintenance P 2 P SIP Lookup P 2 P SIP P 2 P network FIND INSERT INVITE sip: alice@128. 59. 194 INVITE alice P 2 P-SIP overlay REGISTER Alice 128. 59. 19. 194 7

SIP-using-P 2 P Logical Operations n Contact management n n Key storage n n n put (subscribee id, signed encrypted subscriber id) Composition needs service model Offline message n n User certificates and private configurations Presence n n put (user id, signed contact) put (recipient, signed encrypted message) NAT and firewall traversal n STUN and TURN server discovery needs service model XML-based data format 8

P 2 P-over-SIP Architecture and implementation n n DHT (Chord) algorithm using SIP messages with query and update semantics of REGISTER Has SIP registrar, proxy, user agent Other: discovery, NAT traversal, failover Adaptor: allows existing SIP devices to become P 2 P 9

P 2 P-over-SIP Analysis: scalability n Computed message load as function of n n Refresh rate (keep-alive, finger table, user registration), call arrival rate, churn (join, leave, failure), scale (number of peer nodes and users) Number of nodes = f(individual node capacity) n n Measured performance: 800 register/s. Assuming a conservative 10 reqister/s capacity, and aggressive refresh and call rate of 1/min, it gives more than 16 million peers (super nodes) in the network. 10

P 2 P-over-SIP Analysis: availability and call setup latency n To increase user availability: n n Fast failure detection: increase keep-alive rate Reduce unavailability: frequent registration refresh Replicate: user and node registrations Call setup latency: n Same as DHT lookup latency: O(log(N)) n n Calls to known locations (“buddies”) is direct Chord: 10000 nodes => 6 hops n n At most a few seconds User availability and retransmission timers 11

SIP-using-P 2 P vs P 2 P-over-SIP n n Not SIP-specific, hence no implementation overhead for non-Vo. IP but P 2 P applications Low transport and transaction overhead No P 2 P security burden on SIP No dependency on single DHT implementation n n Reuse SIP naming, routing, security, NAT/firewall traversal Easily reuse existing SIP components without change n n n voicemail, conference Single DHT implementation Readily supports service model 12

Conference server Performance evaluation of audio mixer n On commodity PC n n n About 480 participants in a single conference with one active speaker About 80 four-party conferences, with one speaker each Both Pentium and Sparc took 6 MHz per participant 13

SIP network architecture Scalability requirement depends on role Cybercafe ISP IP network IP phones ISP SIP/MGC SIP/PSTN GW GW Carrier network MG IP PSTN GW MG MG PBX PSTN phones SIP/MGC T 1 PRI/BRI PSTN A mobile service provider in 3 GPP with millions of subscribers 14

Reliability of DNS, network, web n n [Wenyu’ 03]: Vo. IP network 98% (. 5+1. 5) [Pang’ 04]: local DNS: 98%; auth DNS: 99% n n [Sohar’ 00]: overall 99. 57% availability n n Minor correlation to load MTBF: order of days, weeks or longer (1%: 10 days) MTTR: order of hours (60%: 5 hr; 90%: 15) Main: 99. 6%, Backbone: 99. 8%, Cisco switches: 99. 98%, PC server: 99. 7%, DB server: 99. 96%, Solaris OS: 99. 99% Hosted web portals: n Usually give 99. 5% in SLA; but achieve 99. 9% except for scheduled downtime 15

Availability and “nines” Availability Downtime Per month PC, Vo. IP calls IP-PBX software (guess) PSTN, network US Power, Solaris OS Switches Per year 98% 14 hrs 7. 3 days 99% 7 hr 3 days, 15 hrs 99. 5% 3. 5 hr 1 day, 19 hr 99. 9% 44 m 8 h, 46 min 99. 95% 22 m 4 h, 23 min 99. 99% 4. 4 m 52 m, 36 s 99. 999% 26 s 5 m, 15 s 99. 9999% 2. 7 s 32 s 16

Related work: web server reliability n Dispatcher or stateful NAT n n IP address takeover (linux-ha) or MAC takeover n n n Dynamic: load; caching problem; not every impl respects TTL NAPTR, SRV Rserpool: to maintain server pool and name server pool n n Cisco phones: primary and backup proxy; implementation dependent; what is servers IP change. DNS n n Probably closer/faster server Client-based n n Requires servers on same subnet; reachability Can’t use for scalability for stateful proxy IP anycast n n Not data dominated so becomes bottleneck Requires new protocol support; local network; Database redundancy TCP connection migration/process migration 17

Related work: SIP server reliability n n n Cisco: proprietary protocol; same subnet Dynamicsoft (bought by cisco): backend database replication Ubiquity: load balancer Vovida: some kind of SIP replication; sync problem after recovery Iptel: IP anycast with state replication n Requires transaction state sharing among servers because replication is not visible to the client 18

High availability Failover implementation in our test-bed - CINEMA My. SQL: No locking protocol Web scripts D 1 Master/ slave replication P 1 between master and slave. Race if insert into D 1 and remove from D 2 Slave/ master P 2 phone. cs. columbia. edu _sip. _udp SRV 0 0 5060 phone. cs. columbia. edu SRV 1 0 5060 sip 2. cs. columbia. edu sipd has in-memory cache: REGISTER refresh much before expiry; web gets delayed data; not an sip 2. cs. columbia. edu issue for cisco phones REGISTER INVITE to P 2 either on ICMP error or after 10 s proxy 1 = phone. cs backup = sip 2. cs 19

High availability Master/ slave Analysis n (1 -(1 -R)2) n Call setup latency TR (1 -R) P[t. M<TD] where TD is DNS TTL, t. M is time-to-repair, and P[t. M<TD] = 1 – e-TD/TM n Caller User unavailability Redundant servers Tradeoff: reliability vs capacity P 2 P 1 TR None (refresh; double register) For first time registration, probability that the server goes down before replication is: 1 – e-(Td/+Tc)/TF where TF is mean-time-to-failure n D 2 D 1 DNS System reliability Slave/ master P 1 Tc P 2 D 1 D 2 Callee Td A Tc Tr TR A Tc 20

Bulk arrival n What if all servers come up immediately after power recovery? n n Carrier (gradually) vs enterprise (all at once) Wait timer in SIP configuration based server capacity n n Don’t query the server for config on reboot Not a problem if server gracefully drops requests without degrading the performance n Clients retry – and succeed over an hour 21

What does scalability depend on? Depends on traffic type n Registration (uniform) n n Call routing (Poisson) n n Instant message, presence (including sensors), device control Stateful calls (Poisson arrival, exponential call duration) n n stateful vs stateless proxy, redirect, programmable scripts Beyond telephony (Don’t know) n n Authentication, mobile users Firewall, conference, voicemail Transport type n UDP/TCP/TLS (cost of security) 22

Related work: web server scalability n Existing work n n n HTTP vs SIP n n Connection dispatcher (NAT) Same IP address Content/session-based redirection DNS-based load sharing UDP+TCP, signaling not bandwidth intensive, no caching of response, read/write ratio is comparable for DB SIP scalability bottleneck n n Signaling, real-time media data, gateway 302 redirect to less loaded server, REFER session to another location, signal upstream to reduce 23

SIP vs HTTP server n Signaling (vs data) bound n n n Transactions n n DNS, SQL database Transport n n Stateful wait for response Depends on external entities n n No File I/O (exception: scripts, logging) No caching; DB read and write frequency are comparable UDP in addition to TCP/TLS; may not need TCP state Goals n n Carrier class scaling using commodity hardware Try not to customize/recompile OS or implement (parts of) server in kernel (khttpd, AFPA) 24

What is SIPstone? SIP server performance metrics SQL database n Steady state rate for n Server n Measure: #requests/s with given delay constraint. n Loader Handler n REGISTER 200 OK R 1 successful registration, forwarding and unsuccessful call attempts measured using 15 min test runs. n Performance=f(#user, #DNS, UDP/TCP, g(request), L) where g=type and arrival pdf (#request/s), L=logging? For register, outbound proxy, redirect, proxy 480, proxy 200. Parameters n INVITE 100 Trying R 2 180 Ringing 200 OK ACK BYE 200 OK n INVITE 180 Ringing n 200 OK ACK 200 OK n n Delay budget: R 1 < 500 ms, R 2 < 2000 ms Shortcomings: n BYE Measurement interval, transaction response time, RPS (registers/s), CPS (calls/s), transaction failure probability<5%, does not consider forking, scripting, Via header, packet size, different call rates, SSL. Is there linear combination of results? Whitebox measurements: turnaround time Extend to SIMPLEstone 25

Comparison of two designs P 1 a-h D 1 P 2 P 3 P 2 i-q D 2 P 3 r-z D 2 Total time per DB =((tr/D)+1)TN =((tr+1)/D)TN =(A/D) + B =(A/D) + (B/D) System reliability =(1 -(1 -Rp)P). (1 -(1 -Rd)D) =R 0. (RP)D. (Rd)D D = number of database servers High Scalability Low Scalability N = number of writes (REGISTER) Low Reliability High Reliability r = #reads/#writes = (INV+REG)/REG T = write latency t = read latency/write latency P = number of proxy servers Rp = reliability of the proxy server Rd = reliability of the database server 26

Two stage architecture Rp M p a 1 Master Rs M s s 1 = R + P REGISTER+ INVITE, etc ex n S=3 s 2 s 3 n P=1+1 a 2 Slave B=2 /B s b 1 Master b 2 Slave r, p When is stateless proxy stage needed What are the optimal values for S, B, P n n for required scalability (1 -10 million BHCA) and reliability (99. 999%) using commodity hardware 27

Performance evaluation This means 10 million BHCA (busy hour call attempts) using S 3 P 3. Scalability result (UDP, stateless, no DNS, no mempool ) I(s) II(p) calls/s Stateful proxy gave similar graphs with 650 CPS for single server. Line segments due to nonuniform distribution in II stage; I have verified uniform distribution also. Regitration test also gave similar graphs with about 2400 RPS (no auth). This means 10 million subscribers using S 3 P 3. 3 3 2800 2 3 2100 2 2 1800 1 2 1050 0 1 900 On commodity hardware: 3 GHz, Pentium 4, 1 GB memory 28

User diversity on incoming calls Is uniform hashing an issue? n Didn’t find any existing evaluation n Related results: n n n Adaptive load balancing for identifier-based distribution. issue – transfer registrations to new DB File popularity is Zipf; user is more uniform (poisson) Dynamic load balancing in web is useful if service time range is more than two orders. (but all servers have same pages) Intuitive: n With 100, 000 subscribers per server, you need to be very unlucky that one of those is equivalent to thousands of subscribers 29

User diversity on incoming calls Is uniform hashing an issue? n My argument (not sure): n n n Assume user popularity for calls is Poisson with mean L. (independent calls for users) X is a random variable indicating number of calls a user receives If there are two servers, and assuming the user population gets uniformly distributed, each server gets roughly half the user population for each call rank. So user popularity again is Poisson with mean L. Thus mean (and variance) remains the same However if user popularity is Zipf, then it is different; variance can be high Alternative: n n If you plot number of calls vs users in decreasing order. Assume this is exponential. (analogy: calls/time to calls/users) Having two servers basically shrinks the x-axis to half. So each server has exponential graph with mean L/2 30

Reliability of two-stage n n If S=P=B=3, each server is 99% available Total: n n (1 -(1 -R)S). (1 -(1 -R)B)P = 99. 9996% P doesn’t have to be 1+1 for each group, but can be N+1 for N groups. n One backup keeps all records in memory, but gets only updates in contact rather than each refresh. Doesn’t have to survive reboots. Clones itself to another DB when failure occurs. 31

What is the best architecture? n Event-based Reactive system n n n 1. Process pool 2. Each pool process receives and processes to the end (SER) n stateful Response recvfrom or accept/recv parse Request Thread pool 3. Receive and hand-over to pool thread (sipd) Each pool thread receives and processes to the end Staged event-driven: each stage has a thread pool Match transaction Modify response Stateless proxy Update DB Found Match transaction Stateless proxy REGISTER other Lookup DB sendto, send or sendmsg Redirect/reject Build response Proxy Modify Request DNS 32

Stateless proxy UDP, no DNS, six messages per call stateful Response recvfrom or accept/recv parse Request Match transaction Modify response Stateless proxy Found Match transaction Stateless proxy Update DB REGISTER other sendto, send or sendmsg Redirect/reject Lookup DB Build response Proxy Modify Request DNS 33

Stateful proxy UDP, no DNS, eight messages per call n Event-based n n Thread-per-message n n n single thread: socket listener + scheduler/timer pool_schedule => pthread_create Thread-pool 1 (sipd) Thread-pool 2 n N event-based threads n n Each handles specific subset of requests (hash(call-id)) Receive & hand over to the correct thread poll in multiple threads => bad on multi-CPU Process pool n Not finished yet 34

Server performance Results of my measurements; effect of. Pentium multi-processor Both and Sparc took approx 2 MHz CPU cycles per Calls/s for stateless proxy, UDP, call/s no DNS, 6 msg/call on single-processor Architecture /Hardware 1 Pentium. IV 3 GHz, 1 GB, Linux 2. 4. 20 (1 x. P) 4 pentium, 450 MHz, 512 MB, Linux 2. 4. 20 (4 x. P) 1 ultra. Sparc-IIi, 300 MHz, 64 MB, Solaris (1 x. S) 2 ultra. Sparc-II, 300 MHz, 256 MB, Solaris (2 x. S) Event-based 1550 400 150 600 Thread per msg 1300 500 100 500 Pool-thread per msg 1400 850 110 600 Thread-pool 1500 1300 152 750 Process-pool 1600 1350 160 1000 Better performance as Calls/s this includesfor stateful mempool changes Architecture /Hardware Event-based proxy, UDP, no DNS, 8 msg/call 1 Pentium. IV 3 GHz, 1 GB, Linux 2. 4. 20 (1 x. P) 1150 Software architecture further 4 pentium, 450 MHz, 1 ultra. Sparc-IIi, 2 ultra. Sparc-II, 300 improves performance: 512 MB, Linux 2. 4. 20 360 MHz, 256 MB, S 3 P 3 can support 16 Solaris 5. 9 (1 x. S) Solaris 5. 8 (2 x. S) (4 x. P) million BHCA 300 160 400 Thread per msg 600 175 90 300 Thread-pool 850 340 120 300 1100 550 155 500 2 stage thread-pool 35

Not much concurrency in stateful mode: needs more investigation 36

What is the best architecture? Stateless n n n n CPU is bottleneck Memory is constant Process pool is the best Event-based not good for multi-CPU Thread/msg and thread-pool similar Thread-pool 2 close to process-poll n Stateful n n n Memory can become bottle-neck Thread-pool 2 is good n But not N x CPU n Not good if P CPU Process pool may be better (? ) 37

In memory database in sipd n Call routing involves ( 1) contact lookups n n Cache (Fast. SQL) n n n 10 ms per query (approx) Loading entire database is easy Periodic refresh Potentially useful for DNS lookups Web config SQL database Periodic Refresh Cache < 1 ms [2002: Narayanan] Single CPU Sun Ultra 10 Turnaround time vs RPS 38

Thread-per request doesn’t scale One thread per message n Doesn’t scale n Thread pool + queue n Too many threads over a short timescale n n Stateless: 2 -4 threads per transaction Stateful: 30 s holding time n n Overload management n n Thread overhead less; more useful processing Pre-fork processes for SIP-CGI Graceful failure, drop requests over responses Not enough if holding time is high n Each request holds (blocks) a thread Incoming Requests R 1 -4 R 1 R 2 R 3 R 4 Throughput Thread pool with overload control Incoming Requests R 1 -4 Thread per request Load Fixed number of threads 39

Avoid blocking calls in sipd n DNS n n 10 -25 ms (29 queries) Cache n n Lazy logger as a separate thread Date formatter n non-blocking Logger n n 110 to 900 CPS Internal vs external Logger: while (1) { lock; writeall; unlock; sleep; } Strftime() 10% REG processing Update variable every second random 32() n Cache gethostid()- 37 s 40

Resource management in sipd n Socket management n n Problems: OS limit (1024), “liveness” detection, retransmission One socket per transaction does not scale n n n Socket buffer size n n Global socket if downstream server is alive, soft state – works for UDP Hard for TCP/TLS – apply connection reuse 64 KB to 128 KB; Tradeoff: memory per socket vs number of sockets Memory management n Problems: too many malloc/free, leaks Stateless processing INV 180 200 ACK BYE 200 REG n Memory pool time ( s) n Transaction specific memory, free once; also, less memcpy W/o mempool n About 155 67 67 gain 95 139 62 237 30% performance W/ mempool Improvement (%) n Stateful: 650 to 800 CPS; Stateless: 900 to 1200 CPS 200 70 111 49 48 64 106 41 202 48 28 27 28 33 24 34 15 31 41

Optimized processing in SER n Reduce copying and string operations n n Reduce URI comparison to local n n Data lumps, counted strings (+5 -10%) User part as a keyword, use r 2 parameters Parser n n Lazy parsing (2 -6 x), incremental parsing 32 -bit header parser (2 -3. 5 x) n n n Case compare n n Use padding to align Fast for general case (canonicalized) Hash-table, sixth bit Database n Cache is divided into domains for locking [2003: Janak] SIP proxy server effectiveness, Master’s thesis, Czech Technical University 42

Bottlenecks and other scalability concerns addressed in SER n Protocol bottlenecks n Parsing n n n Authentication n n Reuse credentials in subsequent requests TCP n n Order of headers Host names vs IP address Line folding Scattered headers (Via, Route) Message length unknown until Content-Length Other scalability concerns n Configuration: n n broken digest client, wrong password, wrong expires Overuse of features n n n Use stateless instead of stateful if possible Record route only when needed Avoid outbound proxy if possible 43

Comparison of sipd and SER n sipd n n Thread pool Events (reactive system) Memory pool Pentium. IV 3 GHz, 1 GB, 1200 CPS, 2400 RPS (no auth) n SER n n n Process pool Custom memory management Pentium. III 850 MHz, 512 MB => 2000 CPS, 1800 RPS 44

Results of our measurement n Stateless proxy n n n Stateful proxy n n S=800, P=650 CPS Registration (no auth) n n n S=1050, P=900 CPS S 3 P 3 => 10 million BHCA (busy hour call attempts) S=2500, P=2400 RPS S 3 P 3 => 10 million subscribers (1 hour refresh) Memory pool and thread-pool 2/event-based further increase the capacity (approx 1. 8 x) 45

3 GPP’s IMS 3 GPP (release 5)’s IP Multimedia core network Subsystem uses SIP n Proxy-CSCF (call session control function) n n Interrogating-CSCF n n n First contact in operator’s network. Locate S-CSCF for register Serving-CSCF n n n First contact in visited network. 911 lookup. Dialplan. User policy and privileges, session control service Registrar Connection to PSTN n MGCF and MGW 46

Peer-to-peer Internet telephony

Comparison: Server-based, structured and unstructured P 2 P Architecture Server-based (twostage) Structure P 2 P (Chord/log(N)) Unstructured P 2 P (blind search) Reliability (or user record availability) (1 -(1 -R)P) Upper bound No guarantee Performance (delay) Low Log(N) No guarantee; Implementation dependent Scalability (number of users) Linear with number of servers Exponential with per node capacity If constant degree, then no limit 48

P 2 P vs server-based P 2 P scaling server count scales with user count, but limited by supernode count efficiency most efficient DHT maintenance = O((log N)2), lookup = O(log. N) security trust server provider; binary trust most supernodes; probabilistic reliability server redundancy; catastrophic failure possible unreliable supernodes; catastrophic failure unlikely 49

Structured vs. unstructured P 2 PSIP n Unstructured P 2 P alone is not good n n No guarantee (upper bound) in lookup Fall back to server; has central dependency Caching is not much useful as contacts change often; caching good for non-mutable data (e. g. , certificates) because replication and caching of mutable data don’t go together well. Skype works: n n n Few super nodes are too burdened Node: supernode ~ 400: 1 Probably some kind of structure (user name prefix) among super nodes, and falls back to central server 50

NAT traversal and P 2 P-SIP n Joining a DHT from behind a NAT: open issue n n NATed nodes acts as users of DHT Media traversal n n STUN (not symmetric: 18%? ), TURN, ICE Hole punching – works with 60% symmetric 51

Security open issues (threats, solutions, issues) n More threats than server-based n n Privacy, confidentiality Malicious node n n n “free riding”, motivation to become super-node Existing solutions n n n Focus on file-sharing (non-real time) Centralized components (boot-strap, CA) Assume co-operating peers n n Don’t forward all calls, log call history (spy), … works for server farm in DHT Collusion Hide security algorithm (e. g. , yahoo, skype) Chord n Recommendations, design principles, … 52

Security Random thoughts n Un-trusted peers: n n n Problems: n n Misrouting: easy to detect No-routing: hard (redundancy, reputation, “call itself”) Malicious program, copyright violation, stolen identity, privacy, free riding, sybil, programmable scripts, aliases Separate DHT from application n Managed DHT: more trusted 53

Why P 2 P-SIP? What is our P 2 P-SIP? n Server-based n n Peer-to-peer n n Maintenance and configuration cost: dedicated administrator Central point of failures: catastrophic failures Depends on controlled infrastructure (e. g. , DNS) Self adjusting, robust against catastrophic failures, highly scalable, and no configurations Call setup and user search latency is higher: O(log(N)) Security: how to handle malicious peers? Identity protection? Our P 2 P-SIP n n Hybrid architecture: works with both P 2 P and server-based Built-in P 2 P network: acts as a service node for proxy, registrar, presence, offline storage, and media relay External P 2 P network: managed and trusted peer nodes Identity protection: Email identifier == SIP identifier 54

Deployment scenarios P P P P P 2 P clients Plug and play; May use adaptors; Untrusted peers; Super-nodes P P 2 P proxies Zero-conf server farm; Trusted servers and user identities Interoperate among these! 55

SIP-using-P 2 P Using an External P 2 P network (distributed hash table - DHT) n Data model n n Treat DHT as database Service model n Join DHT to provide service [5] bob 192. 1. 2. 3 bob [3] [1] [2] [3] DHT [4] [2] [5] alice [1] put(k, 192. 1. 2. 3), k is H(bob) [2] get(k) gives 192. 1. 2. 3 [3] INVITE sip: bob to 192. 1. 2. 3 [1] Service node (128. 3. 4. 5) alice [1] [2] [3] [4] [5] join(128. 3. 4. 5) lookup(H(bob)) gives 128. 3. 4. 5 REGISTER sip: bob to 128. 3. 4. 5 lookup(H(bob)) gives 128. 3. 4. 5 INVITE sip: bob to 128. 3. 4. 5 56

SIP-using-P 2 P Implementation in SIPc with the help of Xiaotao Wu n Open. DHT n n Identity protection n Trusted nodes Robust Fast enough (<1 s) Certificate-based SIP id == email P 2 P for Calls, IM, presence, offline message, STUN server discovery and name search n P 2 P clients better than proxies: n n Less DHT calls Open. DHT quota per client limits put by proxies 57

P 2 P-over-SIP Node architecture: registrar, proxy, user agent User interface (buddy list, etc. ) On reset Signout, transfer On startup Leave Discover Peer found/ Detect NAT ICE Signup, Find buddies User location Find Join DHT (Chord) Multicast REGISTER Audio devices REGISTER, INVITE, MESSAGE SIP P 2 P-using-SIP n IM, call Codecs RTP/RTCP SIP-over-P 2 P 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 58

P 2 P-over-SIP Implementation 31 29 1 n 31 30 sippeer: C++, Linux, Chord n 25 26 26 n 9 n 19 15 11 n 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 59

Chord background 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 60

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 d 4213 f 1 54 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 61

SIP messages n 1 DHT (Chord) maintenance n Query the node at distance 2 k with node id 11 REGISTER To: <sip: 11@example. invalid> From: <sip: 7@128. 59. 15. 56> 10 22 7 15 Find(11) gives 15 SIP/2. 0 200 OK To: <sip: 11@example. invalid> Contact: <sip: 15@128. 59. 15. 48>; predecessor=sip: 10@128. 59. 15. 55 n 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 62

SIP messages n User registration REGISTER To: sip: alice@columbia. edu Contact: sip: alice@128. 59. 194: 8094 n Call setup and instant messaging INVITE sip: bob@example. com To: sip: bob@example. com From: sip: alice@columbia. edu 63

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

Hybrid architecture n n Cross register, or Locate during call setup n n DNS, or P 2 P-SIP hierarchy 65

P 2 P-over-SIP Analysis: scalability n Number of messages depends on n n n Number of peer nodes (N) Keep-alive (rs) and finger table refresh rate (rf) Call arrival distribution (c) Node join, leave, failure rates ( ) Number of users (k. N) User registration refresh rate (t) M={rs+ rf(log(N))2} + c. log(N) + (k/t)log(N) + (log(N))2/N n Number of nodes = f(node-capacity) Nmax min[2 M/(r+c), 2 M/r] for large N n Measured M = 800 reg/s and assuming aggressive refresh and call rate of 1/min, it gives 2219 nodes >> 2160. n Even for a conservative 10 req/s capacity, it gives more than 16 million nodes (super nodes) in the network. 66

P 2 P-over-SIP Analysis: availability and call setup latency n To increase user availability: n n Increase keep-alive rate (fast failure detection) Increase user registration refresh rate (reduce unavailability) Replicate user and node registrations Call setup latency: n Same as DHT lookup latency: O(log(N)) n n n Calls to known locations (“buddies”) is direct DHT optimization further reduces latency Chord: 10000 nodes => 6 hops n n At most a few seconds User availability and retransmission timers 67

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 n Similar to STUN and TURN Based on availability, capacity Conferencing Problems: n Proprietary, single service, centralized login 68

Related work n P 2 P networks n n n Skype and related systems n n n Unstructured (Kazaa, Gnutella, …) Structured (DHT: Chord, CAN, …) Flooding based chat, groove, Magi Skype-in/out uses SIP P 2 P-SIP telephony n n n Proprietary: Nim. X, Peerio, File sharing: SIPShare Now in IETF: W&M, Avaya, Panasonic, … 69

Why we chose Chord? Just as a simple example DHT n Chord can be replaced by another n n n As long as it can map to SIP High node join/leave rates Provable probabilistic guarantees Easy to implement X proximity based routing X security, malicious nodes 70

Why we chose Chord? Reliability of Chord under churn n n If 50% nodes fail, only 3% lookups fail If successor list length is O(log. N) and node failure probability is 50% in a stable network, then still works in O(log. N) lookup hops. Becomes strongly stable after O(N 2) rounds of strong stabilization If failures happen atmost N/2 in Log. N steps, then becomes stable in O(N 3) 71

Chord stabilization vs availability Increasing message rate to 1. 25 msg/sec/node allows < 0. 4% failed lookups http: //www. eecs. harvard. edu/~jonathan/sigops 02. html 72

JXTA vs Chord in P 2 P-SIP n JXTA n n n Protocol for communication (peers, groups, pipes, etc. ) Stems from unstructured P 2 P-SIP n Instead of SIP, JXTA can also be used n Separate search (JXTA) from signaling (SIP) 73

Node startup columbia. edu sipd n REGISTER SIP n DB n alice@columbia. edu DHT n Detect peers n n REGISTER alice=42 42 58 12 14 n REGISTER with SIP registrar Discover peers: multicast REGISTER Join DHT using node-key=Hash(ip) REGISTER with DHT using userkey=Hash(alice@columbia. edu) Dialing out n Call, instant message, etc. INVITE sip: hgs 10@columbia. edu MESSAGE sip: alice@example. com REGISTER bob=12 n Last seen, SIP NAPTR/SRV, DHT 32 74

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 75

Advanced services n Offline messages n n Conferencing n n INVITE or MESSAGE fails => Responsible node stores voicemail, instant message. Mixer, full mesh, multicast Inter-domain n Local DHT; connected by DNS or global DHT 76

Enterprise IP telephony

Goal of my work n n n Beyond voice: video, text, IM, presence, screen sharing, shared web browsing, … Beyond SIP phone: regular telephone, email, web, … Beyond synchronous communication: offline mails, discussion forum, file sharing, … Internet Telephony Interactive voice response Internet Radio/TV Messaging and Presence Unified messaging Video conferencing Media G. 711 MPEG SIP RTSP SAP RSVP RTCP Application layer RTP Transport (TCP, UDP) Network (IPv 4, IPv 6) Quality of service Signaling Media transport Link layer Physical layer Program Call routing Voice XML DTMF Mixing Speech/ text SDP 78

Related work IP telephony and multimedia communication n Unlike low cost Vo. IP: Vonage, AT&T n n There are enterprise IPtel: Cisco, Nortel n n But redundancy architecture, interoperability, distributed components model differ Collaboration: CSCW, SIGGROUP, Breeze n n n We provide enterprise infrastructure Unlike web-centric, or application specific We provide standard-based multimedia collaboration platform Multimedia conferencing: Mbone, H. 323 n Ours is SIP-based infrastructure, reuse existing tools and protocols such as RTSP, media server 79

Related work Comprehensive multi-platform collaboration Goal: Alternate between synchronous and asynchronous communication, and access from different devices and clients. n Asynchronous (loosely coupled) n n n Video conference, IM, screen sharing, floor control, … File sharing, message board, … Messaging and notifications Personalized view n We try to incorporate… n Long lived groups n n Design teams, committees, college classes Asymmetric events n Synchronous (tightly coupled) n n n Lecture and lecture series Short-lived spontaneous interaction Current practice n n n Email, teleconference Vendor specific tools, platform dependence Application specific n E. g. , collaborative software development Per-user calendar, access control, address book 80

Multi-party collaboration What is done, and what is left. n Sipconf: conference server n n Cascaded conference mixer n n Audio, video, IM, screen, shared browsing, floor control No XCON yet: use web interface Small to medium size conferences #participants, audio delay Failover n State sharing between servers 81

Communication to collaboration n Comprehensive n Personalized view n n Synchronous (tightly-coupled) collaboration n n Unified messaging, shared files, discussion forum, notification Multi-platform (device) n n Conferencing: audio, video, IM, white-board, screen sharing, shared web browsing Asynchronous (loosely-coupled) collaboration n n Calendar, address book, groups and access control Telephone: touch tone input and audio (IVR) PC: multimedia client, email, IM Reuse existing protocols and tools Unified messaging n The gaps among different media (audio, video, text), devices (PC, phone) and means of communications (Email, SIP, IM) disappear for messaging 82

What’s next? from multimedia communications to collaboration n Synchronous communications n n Asynchronous communications n n Voicemails, message board, file sharing Ubiquitous computing n n Conferencing, IM i-button, ID-card Service creation n User friendly, end-point/network kns 10@cs. columbia. edu http: //www. cs. columbia. edu/~kns 10/ http: //www. cs. columbia. edu/IRT/cinema 83

Voicemail n INVITE (1) INVITE n CANCEL OK Goals INVITE (3) OK n email (5) BYE n n (2) SETUP sipum (4) RTP Universal access Scalability Provider independent Why SIP and RTSP? n Reuse existing infrastructure and tools rtspd 84

Web interface n Retrieval n n n Web interface rtsp: //server/alice /inbox/1677. au, sip: alice-1677 retrieve@server press 1 to listen… Configuration n Folders Options Email 85

Conferencing models (non-multicast) A D A B+C+D A A+B+C B Topology star C B full-mesh Heterogeneous simple clients No central point of failure Disadvantages External server with high bandwidth link Complex endpoints Complex signaling Advantages D A+C+D D A+B+D B C C ad-hoc Typically only three party conferences 86

Conference 87

Conference Playout delay G 711 A DVI B Linear Periodic timer M - A=B+C E D Linear Mixed linear M-B D E G 711 DVI M=A+B+C GSM C Linear M-C D Receive n n n E G 711 Send G. 711, GSM, DVI, Speex, G. 722 mixing (decode-mix-encode) Video replication; IM; text; VNC screen sharing; floor control; IVR for joining Optimization possible for same codecs 88

Performance evaluation Increase in parameter value CPU Bandwidth Delay Packetization interval (T) Reduces Increases Codec bitrate (B) Increases N/A Codec complexity (M) Increases N/A Network jitter (J) N/A Increases n CPU usage = (. P + ). C = (Me+a. B’+b) and = (Md+c. B’+d) B’ = B + 320/T For C conferences, each with P participants. a, b, c, d are constants; b, d are comparatively insignificant n For G. 711 codec Me and Md are insignificant (5. 5 and 1. 7 s), thus CPU = C. (a. P+c). (B+320/T) n For GSM, G. 722, (or G. 723. 1), Me and Md are dominant (70 and 30/50 s), thus CPU = C. (Me. P+Md) 89

Performance evaluation About 480 participants in a single conference with one speaker About 80 four-party conferences Memory used 20 k. B per call or participant Delay less than 20 ms: increases from first to last participant in a conference Packetization interval of 40 ms gives better performance: 720, but increases delay too Both Pentium and Sparc took about 6 MHz/participant 90

CINEMA My contribution in design and implementation CINEMA Applications RTSP media server SIP/Voice. XML SIP/H. 323 browser gateway rtspd sipvxml Flite Xerces-C SIP/RTP conferencing sip 323 SIP/RTSP unified messaging sipconf SIP proxy server sipum sipd Xerces-C Open. H 323 CINEMA Libraries libsip Basic SIP library rtplib++ libcine librtsp RTP library Utilities parsing IPv 6 RTSP client My. SQL PWLib Resparse libsipapi SIP UA library libconf RTP audio mixer libmedia lib. NT Recordi ng, files Win 32 stub … and web-based GUI libdict libdb++ Hash table my. SQL interface libsnmp libcanon SIP MIB canonic alize C/C++: 60 K out of 187 KLOC Tcl: 30 KLOC 91

Contribution Sip-h 323: signaling translator n Background: ITU-T’s H. 323 n n n Binary ASN. 1 PER, collection of protocols (H. 245, H. 225. 0, Q. 931, RAS, H. 450. x) H. 323 gatekeeper similar but not same as SIP server Problems in interworking n Multi-stage dialing in H. 323 v 1 n n User registration n Both SIP and H. 323 users should be reachable Session description is more complex n n Fast start in v 2 is optional End system should select the codecs Security and Qo. S: end-to-end or not? Solution n n List different scenarios No modification in SIP or H. 323 Direct RTP traffic if possible Implementation 92

Contribution Sipum: Unified messaging using SIP and RTSP n Problem n n n Existing systems have voicemail with PBX or phone, or send voice attachments in email Downloading the whole message is not desirable Solution n n n Using existing standards (RTSP, SIP) and tools (web, media player) Distributed components for different architectures (PBX, phone, service provider) Many ways to retrieve your message (RTSP, SIP, phone, web) Message deletion issues Call reclaiming Implementation 93

Contribution Sipconf: Centralized conferencing using SIP/RTP n Problem n n n Multicast is not available and ad hoc conference is useful for small number of users Heterogeneous clients (some have video also; or different audio codecs) Solution n n n Audio mixer, video forwarder IM, VNC screen sharing, shared web browsing Playout delay adjustments Web based configuration, floor control G. 711 A/Mu, G. 721, DVI, ADPCM, G. 722, … Modular: libconf, libmedia, rtplib++ Implementation and performance evaluation 94

Contribution Sipvxml: SIP-based Voice. XML browser n Background n n n Problem n n Voice. XML for touch tone-based service programming Backend scripts (CGI) or servlets Then existing solutions were PSTN based Solution n First SIP-Voice. XML implementation SIP interface (works with PSTN via a gateway) Example cgi scripts n n n Calling card service Joining a conference (Ajay) Accessing voice mail (Ajay) Email by phone (Pimrampai) Auto attendant (Sean) 95

Contribution libsip++: SIP user agent library in C++ n All the applications (sipum, sipconf, siph 323, sipvxml) use a common underlying library n n Unlike JAIN-SIP or SIP servlet, libsip++ is more high level with facility to access low level features n n Similar API for H. 323 defined using wrapper around open. H 323 Dialog, call, endpoint, registration are defined as objects (JAIN-SIP 1. 1 added dialog as object) Uses underlying transaction and parsing library shared with sipd Test user agent (sipua) is used as tools, e. g. , for sipconf testing Documentation is at http: //www. cs. columbia. edu/~kns 10/software/siplib 96

Contribution GUI: web-based user interface n n Configuration, user profile, etc. , stored in SQL DB Front end as web-based GUI n n User friendly (beginner vs advanced, context help) Asynchronous collaboration n n CGI scripts in Tcl About 100 pages for various configuration Voicemail, file sharing, IM archive, groups, address book, calendar Undergone three iterations n See current version at http: //phone. cs. columbia. edu/cinema/ 97

Interworking between SIP and H. 323 Terminal Control/Devices Codecs SIP SDP RTCP Transport Layer Terminal Control/Devices Q. 931 H. 245 RAS RTCP TPKT TCP Codecs RTP UDP IP and lower layers Both use RTP for media thus allows scalable translator SDP is simple. H. 245 is very exhaustive and can represent inter-codec dependencies. H. 323 has multi-stage call setup. SIP has single stage. H. 323 single step fast connect is optional Basic calls are possible to translate. Complete interworking is not possible without modifying (conference, security). 98

SIP vs H. 323 n n n Text based request response SDP (media types and media transport address) Server roles: registrar, proxy, redirect n n n Binary ASN. 1 PER encoding Sub-protocols: H. 245, H. 225 (Q. 931, RAS, RTP/RTCP), H. 450. x. . . H. 323 Gatekeeper Both use RTP/RTCP over UDP/IP 99

Interworking Problems Call setup translation H. 323 Q. 931 SETUP Q. 931 CONNECT Terminal Capabilities Open Logical Channel Destination address (Bob@office. com) SIP INVITE 200 OK Media capabilities (audio/video) ACK Media transport address (RTP/RTCP receive) • Multi-stage dialing • H. 323 v 2 Fast-start is optional 100

Interworking Problems User Registration ? H. 323 Gatekeeper H. 323 terminal Alias: Henry E 164: 7040 SIP registrar SIP user agent sip: sam@home. com sip: 7063@gateway. com • Location independent user identifier ? • Use information from both networks 101

Interworking Problems Media Description SIP/SDP (dynamically choose from listed modes) List of alternative set of algorithms. audio G. 711 Mu law, G. 723. 1, G. 728 video H. 261 H. 323/H. 245 (declare your exact modes) Supports inter-media constraints { [G. 711 Mu law, G. 711 A law][H. 261 video]} { [G. 723. 1] [no video] } • Translation in both directions • Algorithm selection by end-systems 102

Interworking Problems Common subset of media capabilities D 1 D 2 D 1 ’ D 2’ {[a 1, a 2, a 3], [v 1, v 2]}{[a 1, a 4, a 5], [v 1]} {[a 1, a 4, a 2], [v 1, v 2, v 3]}{[a 1, a 2, a 5], [v 1, v 3]} S 1 S 2 S 1 ’ S 2’ D 1’: {[a 1, a 2, a 3], [v 1, v 2]}{[a 1, a 4, a 2], [v 1, v 2, v 3]} D 2 D 1’: {[a 1, a 4, a 5], [v 1]} S 1^S 1’, S 2^S 2’: {[a 1, a 2], [v 1, v 2]} S 1^S 2’, S 2^S 1’: {[ ], [ ]} {[a 1, a 4, a 2], [v 1, v 2, v 3]} D 1 D 2’: {[a 1, a 2, a 3], [v 1, v 2]}{[a 1, a 2, a 5], [v 1, v 3]} D 2’: {[a 1, a 4, a 5], [v 1]} {[a 1, a 2, a 5], [v 1, v 2, v 3]} {[a 1, a 4], [v 1]} {[ ], [ ]} {[a 1, a 2], [v 1]} {[ ], [ ]} {[a 1, a 5], [v 1]} {[ ], [ ]} Result: {[a 1, a 2], [v 1, v 2]} {[a 1, a 4], [v 1]} {[a 1, a 5], [v 1]} 103

Interworking Problems Call Services n n H. 323 Conferencing: centralized signaling control, MC (Multipoint Controller) Supplementary services, like call transfer: H. 450. x n n SIP Conferencing: centralized bridged + decentralized distributed REFER, 3 pcc 104

Interworking Problems Security and Qo. S n n H. 323 uses H. 235, whereas SIP uses Basic, Digest, TLS, S/MIME Media Traffic end-to-end; Qo. S ? 105

What we want ? n n Transparent translation Minimum modification in SIP or H. 323 Use features from both SIP and H. 323 Direct RTP/RTCP traffic; end-to-end 106

User registration Registration info to foreign network REGISTER henry@office. com Contact: pc 1 H. 323 Gatekeeper + SGW pc 1. office. com RRQ henry@office. com Contact: 128. 59. 19. 200 H. 323 terminal 128. 59. 19. 200 home. com SIP registrar server INVITE henry@office. com 3 xx Moved Contact: pc 1 SIP user agent sam@home. com use SIP REGISTER and/or H. 323 RRQ/RCF 107

User registration Registration info from foreign network LRQ/LCF H. 323 Gatekeeper home. com SIP registrar server + SGW INVITE henry@office. com pc 1. office. com RRQ henry@office. com Contact: 128. 59. 19. 200 H. 323 terminal 128. 59. 19. 200 OK SIP user agent sam@home. com use SIP OPTIONS and/or H. 323 LRQ/LCF 108

User registration Different Architectures • SGW co-located with H. 323 gatekeeper • SGW co-located with SIP registrar/proxy server • Independent SGW 109

Call Setup with H. 323 v 2 Fast Start (Almost) One-to-one mapping between SIP and H. 323 messages. H 323 SIP Setup/Fast. Start INVITE Connect/Fast. Start 200 OK. ACK RTP/RTCP Reverse direction is similar 110

Call Setup without Fast Start H. 323 Q. 931 SETUP Q. 931 CONNECT Terminal Capabilities Open Logical Channel SIP Destination address (Bob@office. com) INVITE 200 OK Media capabilities (audio/video) ACK Media transport address (RTP/RTCP receive) Accept the call from H. 323, forward to SIP after OLC ? Not desirable. 111

Call Setup without Fast Start, SIP to H. 323 H 323 SIP Setup/Q 931 Connect/Q 931 INVITE Signaling Gateway Capabilities/H 245. Open Logical Channel/ H 245 Acknowledgement Media Transport Address 200 OK. ACK Open Logical Channel / H 245 Acknowledgement RTP/RTCP 112

Call Setup without Fast Start, H. 323 to SIP H 323 SIP Setup/Q 931 Connect/Q 931 INVITE Signaling Gateway ACK Capability Exchange Open Logical Channel 200 OK Media Transport Address Re-INVITE/SIP+SDP Acknowledgement Open Logical Channel Acknowledgement RTP/RTCP 113

Media Capability • Modify SIP/SDP : multiple capability sets, or. . . • Let the SGW choose a sub-set of capabilities for SIP side • Re-INVITE or change in H. 323 mode or logical channels, whenever it changes 114

Y Session description INVITE alice@home. com I can support -law and G. 729 Send me audio at 202. 16. 49. 27: 6780 Bob Alice 128. 59. 194 202. 16. 49. 27 OK; I can support -law Send me audio at 128. 59. 194: 8000 RTP To port 8000 To port 6780 RTP 115

Y Presence/event notification office. com bob@office. com Presence server PA alice@home. com SUBSCRIBE PUA REGISTER NOTIFY registrar PUA + PA 116

Y Columbia IM and presence 117

Y Network call control n Priority. pl SIP_FROM SIP_TO stdin CGI-PROXY-REQUEST stdout n n SIP-CGI CPL SIP servlets Urgent if (defined $ENV{SIP_FROM} && $ENV{SIP_FROM} =~ /sip: boss@mycompany. com/) SIP proxy Phone { foreach $reg (get_regs()) { print "CGI-PROXY-REQUEST $ reg SIP/2. 0n"; print "Priority: urgentnn"; Low-priority } } Voicemail 118

O Call transfer B A n C active call REFER C Referred-By: B n REFER Blind/ consultation/ attended INVITE C Referred-By: B BYE A active call 119

O B 2 BUA and third-party call control n Back-to-back UA n n Incoming call triggers outgoing call Services n n Calling card Anonymizer B A SIP C SIP INVITE OK (SDP 1) ACK INVITE (SDP 1) OK (SDP 2) INVITE (SDP 2) ACK OK ACK 120

Y Voicemail n n n Endpoint redirects Problems in PSTN Design alternatives Issues Proxy controls Redirect after 10 s alice@vmail. yahoo. com Voicemail acts like a phone vmail. pl SIP_FROM SIP_TO stdin CGI-PROXY-REQUEST stdout If no response accept after 15 s 121

Y Voice. XML Gateway PSTN Telephone sipvxml Internet Voice gateway VXML • Voice and telephony functions • Voice. XML browser IVR platform • Voice and telephony functions (ASR, TTS, DTMF) • Service logic (application specific) HTML Internet user Web server • Service logic (CGI, servlet, JSP) 122

Y Voice. XML contd. <form action=“url”> Enter your Id: <input name=‘id’> <input type=‘submit’> </form> <field name=‘id’> <prompt> Your ID, please. </prompt> </field> <block> <submit next=“url”/> </block> </form> Telephony, speech synthesis or audio output, user input and grammar, program flow, variable and properties, error handling, … 123

Y Columbia sipvxml PSTN Telephone n n n Unified messaging access Email by phone Event notification and scheduling Audio volume control for conference Advanced conference control Internet SIP/PSTN gateway TTS, ASR, DTMF, XML, sipvxml HTTP, RTSP SIP phone Web server Media server rtspd Email. tcl 124

Y Email + phone Email by phone Email procmail important mails Email to IM Internet SIP Voice. XML browser HTTP JSP n n Login Email formatting Listen, reply, delete, compose, forward Navigation -next, previous, jump Email servlet DB SIP n n TTS IM Call n Inbox Email formatting SIP based Text-to-speech SIP Internet Inbox Email to phone 125

Y IM + voice call n Who can initiate? n SIP MESSAGE TTS ASR n n Call RTP Feedback n IM n SIP INVITE n n authentication, billing, … to voice user to IM user initial IM greeting Talk-spurt detection Speech recognition 126

O Notification n Calendar Events Conferences Schedule from a browser SIP call 2129397063 Web server Calendar. cgi “at 6: 00 pm” IM kundan@ Email Kns 10@… 127

Y Phone announcement server Text or audio Destinations n Input n n TTS PAS SIP n Example n n . . . n Range: 93970? ? List: A, B, C Announcement Emergency Issues n n Voicemail Failure detection 128

O RTSP + TTS + ASR TTS ASR Media server SETUP rtsp: //server/tts. cgi ? text=How+are+you. PLAY RTP SETUP rtsp: //server/asr. cgi RECORD RTP SET_PARAMETER Text=I am fine, thank you. 129

O Centralized conferencing n Conference as URL n n On the fly conferences n n staffmeet@office. com my. adhoc@server INVITE REFER Basic task: join/leave n n Dial in, Refer dial in Dial out, Refer dial out INVITE server REFER 130

Y Conference + Voice. XML sipvxml Caller 1. INVITE sipvxml 2. Call accepted 3. Enter your four digit PIN 4. Entered 4 -6 -8 -3 5. Authenticate user, 4683=>Alice 6. Enter the conference identifier 7. Entered 2 -3 -# 8. Permission to join, 23=>meet 9. REFER meet@conference 10. Terminate the old call 11. INVITE meet@conference Call transfer vs bridged mode sipconf 131

Y New conference applications The ease & flexibility of sipvxml enables us to build custom telephonic applications to suit our needs. e. g. , Volume Check Application sipvxml Caller sipconf 1. INVITE sipvxml 2. Menu 1. Vol Check 2. Mic Check 3. User enters 2 4. User speaks out a voice sample 5. Voice sample is analyzed 6. Sip. VXML: Vol level too high/low/… 7. User adjusts the vol level. 8. User now joins conference. 132

Y Conferencing n sipc SIP 323 n n n Recording in a media server SIP/PSTN Automatic volume adjustments Automatic load balancing Delay adjustments Conference recording n Local or RTSP 133

PSTN interworking sip: bob@home. com +1 212 9397063 Telephone network Telephone subscriber n n SIP server IP endpoint Translating audio (PCMU/PCMA) Translating signaling (PRI/T 1, ISUP) n n SIP/PSTN gateway Overlap signaling Advanced features in SIP are lost in PSTN Translating identifiers (phone number) Determining transition points 134

PSTN to IP n Gateway knows the SIP server n n <sip: 7063@conductor. cs. columbia. edu; user=phone> ENUM n n n DNS +1 212 9397042 => 2. 4. 0. 7. 9. 3. 9. 2. 1. e 164. arpa => sip: hgs@cs. columbia. edu Suitable for relatively “static” contacts 135

IP to PSTN n Static mapping n n ITGW information is dynamic: n n 1 -212 -939 xxxx => @itgw 1. cs. columbia. edu Overlapping networks Multiple providers Load balancing TRIP Route advertisement n Can be implemented in outbound proxy n Suitable for current hierarchical network +1 @service. mci. com at 4¢/min +1212 @nyc. gw. com at 1¢/min +1212939 @itgw 1. columbia. edu free n 136

30 second version n I developed reliability and scalability techniques for Internet telephony and showed that it is at par with the existing telephone system reliability and scalability at a much lower cost. I developed interoperable architecture to build self organizing network of Internet telephones, without depending on managed infrastructure or servers. I developed tools and components for a multiplatform multimedia collaboration system using existing standards and showed that it can scale to large number of simultaneous participants. 137

Scientific contribution n That linear cluster scalability can be observed in SIP servers. That we don’t need to depend on servers or managed infrastructure for Internet telephony. That we can build highly scalable and reliable Internet telephony systems using existing standards on commodity hardware. 138