Reliable, Scalable and Interoperable Internet Telephony by Kundan Singh Advisor: Henning Schulzrinne Computer Science Department, Columbia University, New York Oct 12, 2007, Job Talk at FXPAL

My research background/timeline 1997 1999 2000 2001 2002 2003 2004 2005 2006 2007 Undergrad @India MS@cs.columbia PhD@cs.columbia Work@ Motorola H.323 client gateway SIP-H.323 translator SIP-RTSP voice mail SIP conferencing Libsip++ (SIP library) P2P VoIP using SIP SIP Failover/load sharing Enterprise VoIP infrastructure Interactive voice response CINEMA user interface Multimedia collaboration Mobile NAT Reliability & scalability VoIP infrastructure Conference evaluation Bell Labs, Adobe

Outline of the presentation Introduction What is the problem? Why important? Server redundancy Load sharing and failover in SIP telephony Peer-to-peer (P2P) P2P telephony using SIP Enterprise IP telephony Multi-platform collaboration using SIP Scalable centralized conferencing architecture Other interesting projects Conclusion

Telephone reliability & scalability (PSTN: Public Switched Telephone Network) database (SCP) for freephone, calling card, … signaling network (SS7) signaling router (STP) local telephone switch (class 5 switch) 10,000 customers 20,000 calls/hour database (SCP) 10 million customers 2 million lookups/hour signaling router (STP) 1 million customers 1.5 million calls/hour regional telephone switch (class 4 switch) 100,000 customers 150,000 calls/hour 99.9994% availability for equipment. Long distance 3-4 nines (AT&T’97). Mobile about 98% (study in europe). Current VoIP: call success probability 99.5 and abortion due to poor quality 1.5%, giving 98% availability (wenyu’03). Cannot lose in-progress calls Preserving billing data is important Can lose calls during call-setup SCP: service control point; STP: signal transfer point “bearer” network telephone switch (SSP) Switches strive for 99.999% availability. Lucent’s 5E-XC supports 4 million BHCA.

Internet telephony (SIP: Session Initiation Protocol) alice@yahoo.com yahoo.com example.com bob@example.com REGISTER INVITE 129.1.2.3 DNS 192.1.2.4 DB Can SIP server provide carrier grade reliability and scalability using commodity hardware Unlike PSTN, call stateless proxies. DNS Routing (BGP, OSPF) Link connection Software failure QoS

What are the problems? Can SIP server provide carrier-grade reliability and scalability using commodity hardware? What affects the server performance? How can we build a server-less self-organizing peer-to-peer VoIP network? Can this be done in standards compliant way? Can communication be extended to multi-platform collaboration using existing protocols? How well multi-party conferencing scales? My contributions: Server redundancy Implemented failover using database replication Two-stage architecture for SIP load sharing Comparison of thread models for SIP server Peer-to-peer (P2P) SIP servers using external P2P network Additionally, P2P maintenance using SIP Enterprise IP telephony Multi-platform collaboration using SIP Scalable centralized conferencing architecture Interworking between SIP/SDP and H.323

Outline of the presentation Introduction What is the problem? Why important? Server redundancy Load sharing and failover in SIP telephony Peer-to-peer (P2P) P2P telephony using SIP Enterprise IP telephony Multi-platform collaboration using SIP Scalable centralized conferencing architecture Other interesting projects Conclusion

High availability Failover implementation and analysis Web scripts Web scripts D1 D2 Master/ slave Slave/ master replication P1 P2 Known techniques: Client-based (Cisco phones: primary and backup proxy); DNS (NAPTR, SRV); IP address takeover (Requires same subnet); Database redundancy Issues that were solved: MySQL 4.0 has no locking protocol between master and slave. They proposed for 5.0 but not done yet. So only master should be updated. But if slave is updated when master is running, there may be problem. Mostly not visible: SIP register are additive. If contact is added to D1 and removed from D2, race condition. But primary is preferred over secondary so all replication happens D1 to D2 unless D1 is down. Make sure DB are consistent before failed server is brought up. Sipd has in-memory cache: hence we need to refresh register much before expiry; web gets delayed data; not an issue with cisco phone as it can register with multiple proxies, and registrations are additive. The phone first sends INVITE to P1, and if there is ICMP error of after 10 s, can send INVITE to P2. MySQL Cluster has delivered five 9s—in other words, 99.999 percent—availability in testing, according to company officials. That works out to five minutes of downtime per year. The technology has been tested on as many as 48 nodes, with failover response times running between five and 10 milliseconds, according to MySQL Vice President of Marketing Zack Urlocker. Reducing refresh interval much before expiry makes user appear available when he is not (Phone dies without un-registering) e.g., refresh interval = (Expires/2)-e Database replication causes problem for Redundant voicemail: different vmail contacts for P1 and P2=>don’t replicate. Or use DNS NAPTR/SRV. conference server: must be tied with conference server state replication also. Replication performance: http://dev.mysql.com/books/hpmysql-excerpts/ch07.html indicates a simple experiment that does best case analysis on lightly loaded servers, where 95% times the record is available at slave on first attempt, and 99.3% on first two attempts. For analysis, refer to the thesis: System reliability individual component reliability Call setup latency DNS TTL, time-to-repair, retry timeout User unavailability Most registers are refreshes Retry timeout, replication interval, register refresh interval 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

Scalability Comparison of the two designs a-h i-q r-z D1 D2 P1 P2 P3 How derived: (a) writes = NT, total read = rN.tT (b) total writes = NT, total read = rN.tT Reliability (failover using redundant proxies and databases): On register, write to D1 and D2. On invite, read from D1 or D2. With MySQL 4.0 not possible to do database replication since write can happen to any. So each SIP server must write to all Ds. Database write and synchronization traffic becomes bottleneck. Scalability (load sharing by dividing the user space and using load balancing proxy): Proxy and database can run on the same host, reducing traffic and improving performance. However, stateless front end can become a bottleneck. Dynamic hashing versus static hashing also affect the performance. Low Scalability High Reliability High Scalability Low Reliability

Scalability (and reliability) Two stage architecture I stage II stage a*@example.com a1 Master a.example.com _sip._udp SRV 0 0 a1.example.com SRV 1 0 a2.example.com s1 a2 Slave sip:bob@example.com s2 sip:bob@b.example.com b*@example.com Master b.example.com _sip._udp SRV 0 0 b1.example.com SRV 1 0 b2.example.com One group can become backup for other group. s3 b1 Slave example.com _sip._udp SRV 0 40 s1.example.com SRV 0 40 s2.example.com SRV 0 20 s3.example.com SRV 1 0 ex.backup.com ex b2 Capacity = f(#stateless, #groups)

Load Sharing Performance result: calls/second Using 3+3 servers gives carrier-grade performance (10 million busy hour call attempts) Registration test: supports 10 million subscribers On commodity hardware: 3 GHz, Pentium 4, 1 GB memory Test with UDP, stateless, no DNS and no mempool

Server performance What happens inside a server Server performance What happens inside a server? What thread/event models possible? Web server (Blocking) I/O Critical section (lock) Critical section (r/w lock) accept recv File read send recvfrom Match transaction Modify response Update DB Lookup DB Build Request DNS sendto parse Response Stateless proxy Found stateful REGISTER other Redirect/reject Proxy SIP server Event-based performs 30% better than existing thread-pool architecture on single-CPU Two stage thread-pool architecture gives better performance on multi-CPU 60% more on 4xPentium Both Pentium and Sparc took 2 MHz of CPU cycles per call/s on single-CPU Earlier memory pool gave 30% improvement Stateless: 1550 CPS, i.e., S3P3 16m BHCA Stateful: 1150 CPS Pure event-based (one thread) Thread-per-msg or transaction Pool-thread per msg (sipd) Two stage thread pool

Problem with servers Server-based Peer-to-peer Cost: maintenance, configuration Central points of failures, catastrophic failures Controlled infrastructure (e.g., DNS) Peer-to-peer Robust: no central dependency Self organizing, no configuration Inherent scalability C S P IETF Zeroconf: without DHCP/DNS, do IPv4 address allocation, DNS resolution, service discovery (SRV), Multicast address allocation. 169.254/16 (169.254.1.0-254.255) can be used for other devices in local network. Not simultaneously.

We built: P2P-SIP Unlike proprietary Skype architecture Robust and efficient lookup using DHT Interoperability DHT algorithm uses SIP communication Hybrid architecture Lookup in SIP+P2P Inter-domain P2P-SIP Unlike file-sharing applications Data storage, caching, delay, reliability Data model and service model Disadvantages Lookup delay and security Problems with skype: proprietary architecture, single service, centralized component. Event-based performs 30% better than existing thread-pool architecture on single-CPU Two stage thread-pool architecture gives better performance on multi-CPU 60% more on 4xPentium Both Pentium and Sparc took 2 MHz of CPU cycles per call/s on single-CPU Zipf: straight line on double log axes.

SIP-using-P2P Implementation in SIPc with the help of Xiaotao Wu OpenDHT Using Data model Identity protection Certificate-based SIP id == email P2P for Calls, IM, presence, offline message and name lookup There are two ways in which SIP and P2P can be combined: A SIP implementation can use an external P2P for lookup (SIP-using-P2P) and additionally the P2P network itself can be built using SIP messages (P2P-over-SIP). There are a number of logical operations such as contact storage, key storage, presence, offline messages and NAT/firewall relay discovery service, that can be delegated to the P2P overlay. We have implemented P2P-SIP in our multimedia collaboration client, sipc, using OpenDHT running on Planetlab with about 200 nodes. The advantage of using an externally managed DHT is that we can trust to some extent that the nodes are not malicious and perform the DHT operations (get/put) correctly. Thus the security problem is mostly avoided. The identity protection is provided using a well known CA such as ours which gives out the certificate to the user for her email address, so that the user can securely use her email address as the SIP identifier in P2P-SIP. The implementation includes the P2P modes for calls, IM, presence, offline message storage, STUN server discovery and name search (find the user identifier for “Firstname Lastname”) OpenDHT is robust and fast enough for our needs. Lookups on an average take less than a second. We implemented redundancy and failover so that if one OpenDHT node is unavailable it uses another randomly choosen closer node.

Distributed Hash Table (DHT) Chord background 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? 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 42 38 32 38 24 30

P2P-over-SIP: SIPpeer: implementation in C++ DHT maintenance using SIP sippeer: C++, Linux, Chord, failover Server farm vs super-peer vs all peers Adaptor for existing phones Use P2P-SIP node as an outbound proxy NAT/firewall traversal Analysis: scalability and availability Advanced: Offline messages, conferencing, Inter-domain overlay My P2P-SIP work at Adobe A hybrid architecture is also described in which the peer either cross-register to all the domains, or local the destination domain during call setup. Again, we can use DNS or a hierarchical P2P network to achieve this. Analysis: Computed message load as function of 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) 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. Scalability of chord: load balancing: 99th percentile in 10^4 nodes, 10^6 keys, is 4.6xmean. Max is 10x. Keys per node is linear in number of keys. PDF looks exponential. Path length: 10^4 node network. Average 6, 99th percentile 11. Looks Poisson distribution. Analysis: scalability: Number of messages depends on 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 Number of nodes = f(node-capacity) Nmax  min[2M/(r+c),2M/r] for large N Measured M = 800 reg/s and assuming aggressive refresh and call rate of 1/min, it gives 2219 nodes >> 2160. Even for a conservative 10 req/s capacity, it gives more than 16 million nodes (super nodes) in the network. Analysis: availability and call setup latency: To increase user availability: Increase keep-alive rate (fast failure detection) Increase user registration refresh rate (reduce unavailability) Replicate user and node registrations Call setup latency: Same as DHT lookup latency: O(log(N)) Calls to known locations (“buddies”) is direct DHT optimization further reduces latency Chord: 10000 nodes => 6 hops At most a few seconds User availability and retransmission timers

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. Security TLS, 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, ENUM Interact with server-based infrastructure or co-locate peer node with the gateway SIP-using-P2P: Not SIP-specific, hence no implementation overhead for non-VoIP but P2P applications Low transport and transaction overhead No P2P security burden on SIP No dependency on single DHT implementation P2P-over-SIP: Reuse SIP naming, routing, security, NAT/firewall traversal Easily reuse existing SIP components without change voicemail, conference Single DHT implementation Readily supports service model

Outline of the presentation Introduction What is the problem? Why important? Server redundancy Load sharing and failover in SIP telephony Peer-to-peer (P2P) P2P telephony using SIP Enterprise IP telephony Multi-platform collaboration using SIP Scalable centralized conferencing architecture Other interesting projects Conclusion

Internet telephony infrastructure CINEMA: Columbia InterNet Extensible Multimedia Architecture CINEMA servers Telephone switch Local/long distance 1-212-5551212 sipconf: Conference server rtspd: media server Quicktime RTSP PSTN RTSP clients Department PBX sipum: Unified messaging sipd: Proxy, redirect, Registrar server Internal Telephone Extn: 7040 713x SQL database cgi Web server SIP/PSTN Gateway vxml Web based configuration SIP VXML My work Built many components in a complete system for enterprise IP telephony and multimedia collaboration H.323 siph323: SIP-H.323 translator NetMeeting

Goal of my work 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, … Program Call routing SIP SAP RSVP RTCP RTP Media G.711 MPEG RTSP Signaling Quality of service Media transport Internet Telephony Radio/TV Messaging and Presence Interactive voice response Unified messaging Video conferencing Physical layer Link layer Network (IPv4, IPv6) Transport (TCP, UDP) Application layer Voice XML DTMF Mixing Speech/ text SDP

Communication to collaboration Comprehensive Personalized view Calendar, address book, groups and access control Synchronous (tightly-coupled) collaboration Conferencing: audio, video, IM, white-board, screen sharing, shared web browsing Asynchronous (loosely-coupled) collaboration Unified messaging, shared files, discussion forum, notification Multi-platform (device) Telephone: touch tone input and audio (IVR) PC: multimedia client, email, IM Reuse existing protocols and tools Unified messaging The gaps among different media (audio, video, text), devices (PC, phone) and means of communications (Email, SIP, IM) disappear for messaging Current practice is to use email and telephone conference, or use vendor specific or platform dependent tools, or use application specific collaboration. Our goal is to provide synchronous and asynchronous collaboration and alternate between the two, and access from variety of devices such as telephone and PC using tools such as email, IM, PC client or audio client.

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

Conference

Conference server Performance evaluation of audio mixer and cascaded architecture SIP REFER message is used to create cascading       On commodity PC 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 Commodity PC: 3 GHz, Pentium 4, with 1 GB memory Memory: 20 kB/participant Delay: less than 20 ms Packetization interval of 40 ms gives 700 participants, but increases delay N.(N-1) participants Higher delay N2/4 participants Lower delay I measured the CPU usage for two cascaded servers: supports about 1000 participants

Presence/event notification office.com bob@office.com Presence server PUA PA alice@home.com REGISTER SUBSCRIBE PUA + PA NOTIFY PUA registrar General event notification method for Internet presence, conferencing, device control Instant messaging MESSAGE with text body

Columbia IM and presence

Network call control SIP-CGI CPL SIP servlets SIP proxy Urgent Priority.pl SIP_FROM SIP_TO stdin CGI-PROXY-REQUEST stdout SIP-CGI CPL SIP servlets SIP proxy Urgent Low-priority Voicemail Phone if (defined $ENV{SIP_FROM} && $ENV{SIP_FROM} =~ /sip:boss@mycompany.com/) { foreach $reg (get_regs()) print "CGI-PROXY-REQUEST $reg SIP/2.0\n"; print "Priority: urgent\n\n"; } SIP-CGI: Programming language independent. Maintains state via an opaque token. For SIP proxies and endpoints: call routing, controlling forking, call rejection, call modification (Priority, Call-Info). RFC 3050. Upload via web or REGISTER

Voicemail Design alternatives Issues Endpoint redirects Proxy controls Redirect after 10s alice@vmail.yahoo.com Proxy controls Voicemail acts like a phone vmail.pl CFB=call forward busy Problems in PSTN: Voice mail system tied to PBX or phone company Integration of video, fax, whiteboard? How to integrate with Internet telephony? How to integrate with email, web and other user applications? Existing solutions Voice Profile for Internet Messaging (VPIM) Web-based unified messaging systems with personalized PSTN voice mail number Issues Call reclaiming Deleting voice/video mail Integration with PSTN phone Integration with VPIM, IMAP, POP3 SIP_FROM SIP_TO stdin CGI-PROXY-REQUEST stdout If no response accept after 15s

Web interface Retrieval Configuration Web interface rtsp://server/alice /inbox/1677.au, sip:alice-1677-retrieve@server press 1 to listen… Configuration Folders Options Email Retrieval or deletion Retrieval using RTSP clients (Quicktime), SIP user agent (e*phone) or Web browser. Features Integration with web/email for more control over voicemail configuration (e.g., folder management, email notification.) Web based voice mail accounts for users (Similar to Hotmail)

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

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

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

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

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

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

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

Outline of the presentation Introduction What is the problem? Why important? Server redundancy Load sharing and failover in SIP telephony Peer-to-peer (P2P) P2P telephony in SIP Enterprise IP telephony Multi-platform collaboration using SIP Scalable centralized conferencing architecture Other interesting projects Conclusion

Revisiting the problems Developed a two stage scalable and reliable SIP server architecture: linear scaling. Use event-based. Can SIP server provide carrier-grade reliability and scalability using commodity hardware? What affects the server performance? How can we build a server-less self-organizing peer-to-peer VoIP network? Can this be done in standards compliant way? Can communication be extended to multi-platform collaboration using existing protocols? How well multi-party conferencing scales? How to interoperate between SIP and H.323? Developed P2P-SIP architecture: SIP-using-P2P and P2P-over-SIP 100 requests/s, 1hr=3600s refresh interval =>360000 users. Complicated by mobility (higher registration rate), authentication Our proxy server does 300 registrations and 90 calls/s. Same infrastructure can be used for generic multimedia communication on the Internet. Multi-platform collaboration using existing protocols and tools, unified messaging, centralized conferencing (cascaded), SIP-H.323 interworking.

Conclusions Impact: “So what” (Implications): Commercialized by SIPquest (now FirstHandTech.com) and sold to many customers. CINEMA was deployed in our department for a brief period of time. Used in various other projects at IRT: NG911, firewall controller, presence scalability, TCP/TLS measurements,… P2P-SIP is a “hot” topic in industry and IETF now – client desktop, hardware phone as well as server vendors are pursuing this. SIP-H.323 requirements eventually became an RFC Worked on SIP stack and P2P-SIP implementation at Adobe; the SIP implementation is announced already and planned to be beta-released this year, and hopefully P2P-SIP will make it to consumers some day “So what” (Implications): Replacing PSTN – better features, quality and performance at lower cost and maintenance; zero cost VoIP using P2P-SIP Distributed, multi-provider, component architecture for telephony and collaboration Lessons learned: Network-based distribution is better Modular architecture: component = one function Better understanding of SIP-like systems software

My publications Conference, workshop, technical report, magazine/journal K. Singh and H. Schulzrinne, “Using an external DHT as a SIP location service", Columbia University Technical Report CUCS-007-06, NY, Feb’06. K. Singh and H. Schulzrinne, “Peer-to-peer Internet telephony using SIP", NOSSDAV, Skamania, Washington, Jun 2005.. K. Singh and H. Schulzrinne, "Peer-to-peer Internet Telephony using SIP", New York Metro Area Networking Workshop, CUNY, NY, Sep 2004. K. Singh and H. Schulzrinne, "Peer-to-peer Internet Telephony using SIP", Columbia University Technical Report CUCS-044-04, NY, Oct 2004. K. Singh and H. Schulzrinne, “Failover, load sharing and server architecture in SIP telephony”, Elsevier Computer Communication Journal. To appear. Aug 2006. “K. Singh and H. Schulzrinne, “Failover and load sharing in SIP telephony", SPECTS (Symposium on performance evaluation of computer and telecommunication systems). Philadelphia, PA, Jul 2005. K. Singh and H. Schulzrinne, "Failover and Load Sharing in SIP Telephony", Columbia University Technical Report CUCS-011-04, NY, May 2004. H. Schulzrinne, K. Singh and X. Wu, "Programmable Conference Server", Columbia University Technical Report CUCS-040-04, NY, Oct 2004. K. Singh, Xiaotao Wu, J. Lennox and H. Schulzrinne, "Comprehensive Multi-platform Collaboration", MMCN 2004 - SPIE Conference on Multimedia Computing and Networking, Santa Clara, CA, Jan 2004. K. Singh, Xiaotao Wu, J. Lennox and H. Schulzrinne, "Comprehensive Multi-platform Collaboration", Columbia University Technical Report CUCS-027-03, NY, Nov 2003. M. Buddhikot, A. Hari, K. Singh and S. Miller, "MobileNAT: A new Technique for Mobility across Heterogeneous Address Spaces", ACM MONET journal, March 2005. M. Buddhikot, A. Hari, K. Singh and S. Miller, "MobileNAT: A new Technique for Mobility across Heterogeneous Address Spaces", WMASH 2003 - ACM International Workshop on Wireless Mobile Applications and Services on WLAN Hotspots, San Diego, CA, Sep 2003. K. Singh, A. Nambi and H. Schulzrinne, "Integrating VoiceXML with SIP services", ICC 2003 - Global Services and Infrastructure for Next Generation Networks, Anchorage, Alaska, May 2003. K. Singh, A. Nambi and H. Schulzrinne, "Integrating VoiceXML with SIP services", Second New York Metro Area Networking Workshop, Columbia University, NY, Sep 2002. K. Singh, W. Jiang, J. Lennox, S. Narayanan and H. Schulzrinne, "CINEMA: Columbia InterNet Extensible Multimedia Architecture", Columbia University Technical Report CUCS-011-02, NY, May 2002. W. Jiang, J. Lennox, H. Schulzrinne and K. Singh, "Towards Junking the PBX: Deploying IP Telephony", NOSSDAV 2001. W. Jiang, J. Lennox, S. Narayanan, H. Schulzrinne, K. Singh and X. Wu, "Integrating Internet Telephony Services", IEEE Internet Computing (magazine), May/June 2002 (Vol. 6, No. 3). K. Singh, Gautam Nair and H. Schulzrinne, "Centralized Conferencing using SIP", 2nd IP-Telephony Workshop (IPTel'2001), April 2001. K. Singh and H. Schulzrinne, "Unified Messaging using SIP and RTSP", IP Telecom Services Workshop 2000, Atlanta, Georgia, U.S.A, Sept 2000. K. Singh and H. Schulzrinne, "Unified Messaging using SIP and RTSP", Columbia University Technical Report CUCS-020-00, NY, Oct 2000. K. Singh, H.Schulzrinne, "Interworking Between SIP/SDP and H.323", 1st IP-Telephony Workshop (IPTel'2000), April 2000. K. Singh and H. Schulzrinne, "Interworking Between SIP/SDP and H.323", Columbia University Technical Report CUCS-015-00, NY, May 2000.

30 second version 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 multi-platform multimedia collaboration system using existing standards and showed that it can scale to large number of simultaneous participants.

Scientific contribution 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.