SIP Research at Columbia University Henning Schulzrinne (with Kundan Singh, Jonathan Lennox and other members of the IRT lab) Dept. of Computer Science Columbia University (IBM Research, Feb. 15, 2005)

Overview What’s different? SIPstone Server profiling Service creation Future plans

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 Unlike PSTN, call stateless proxies. DNS Routing (BGP, OSPF) Link connection Software failure QoS

Basic SIP message flow

What’s different? SIP header format ~ HTTP but: not single request-response provisional responses forking insignificant (constant) body sizes multiple transports: UDP, TCP, SCTP possibly encrypted body (S/MIME) database-backed translation script execution still rare

Architecture differences bob@a.com  128.59.16.5 bob@x.a.com bob@y.a.com parse TCP parse UDP TCP SCTP lookup update map fork & wait log

SIP network architecture Scalability requirement depends on role Cybercafe ISP IP network IP phones GW ISP MG SIP/MGC MG SIP/PSTN GW SIP/MGC Carrier network MG Mention about requirements in #customers. GW IP PSTN PBX PSTN phones T1 PRI/BRI PSTN

SIPstone Model typical proxy usage Five tests: registration outbound proxy redirect proxy 480 proxy 200 Increase load until failure rate above threshold requires response within 2 seconds (for proxy 200) transaction failure probability 1% Combined metric: SIPstone-A see http://www.sipstone.org for details

SIPstone examples

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

Server redundancy The problem: failure or overload REGISTER INVITE REGISTER INVITE Replicate registration or search on call

Scalability Load sharing: redundant proxies and databases REGISTER Write to D1 & D2 INVITE Read from D1 or D2 Database write/ synchronization traffic becomes bottleneck P1 REGISTER D1 P2 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. INVITE P3

Scalability Load sharing: divide the user space Proxy and database on the same host Stateless proxy can become overloaded Use many Hashing Static vs dynamic P1 D1 a-h P2 D2 i-q Any study on dynamic hashing for web? What are the issues with dynamic hashing: transfer registrations to new DB. P3 D3 r-z

Scalability Comparison of the two designs a-h D1 D1 Low reliability High scale P2 P2 i-q D2 D2 P3 P3 r-z D2 Total time per DB ((tr/D)+1)TN = (A/D) + B ((tr+1)/D)TN = (A/D) + (B/D) How derived: (a) writes = NT, total read = rN.tT (b) total writes = NT, total read = rN.tT D = number of database servers N = number of writes (REGISTER) r = #reads/#writes = (INV+REG)/REG T = write latency t = read latency/write latency

Reliability and scalability Two stage architecture for CINEMA 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 s3 b1 One group can become backup for other group. 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 Request-rate = f(#stateless, #groups) Bottleneck: CPU, memory, bandwidth? Failover latency: ?

Reliability and scalability Analysis, simulation and measurement proposal Rp Mp a1 Master Rs Ms P=1+1 s1 a2 Slave S=3  = R + P REGISTER+ INVITE, etc B=2 s2 /B Master r, p s3 s b1 Slave ex b2 When is stateless proxy stage needed What are the optimal values for S,B,P for required scalability (1-10 million BHCA) and reliability (99.999%) using commodity hardware

High availability Failover in our test bed - CINEMA Web scripts Web scripts D1 D2 Master/ slave Slave/ master replication P1 P2 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. 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. 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

Service creation Tailor a shared infrastructure to individual users traditionally, only vendors (and sometimes carriers) learn from web models programmer, carrier end user network servers SIP servlets, sip-cgi CPL end system VoiceXML VoiceXML (voice), LESS

sip-cgi web common gateway interface (cgi): oldest (and still most commonly used) interface for dynamic content generation web server invokes process and passes HTTP request via stdin (POST body) environment variables  HTTP headers, URL arguments as POST body or GET headers (?arg1=var1&arg2=var2) new process for each request  not very efficient but easy to learn, robust (no state) support from just about any programming language (C, Perl, Tcl, Python, VisualBasic, ...) Adapt cgi model to SIP  sip-cgi RFC 3050

sip-cgi examples Block *@vinylsiding.com: Make calls from boss urgent: if (defined $ENV{SIP_FROM} && $ENV{SIP_FROM} =~ "sip:*@vinylsiding.com") { print "SIP/2.0 600 I can't talk right now\n\n"; } Make calls from boss urgent: 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 Servlets Direct Application of HTTP servlet Model to SIP Car File Direct Application of HTTP servlet Model to SIP Java-based API Telecommunications application is a set of SIP (and HTTP!) servlets SIP servlets process a particular SIP request or response Lifecycle managed by container SIP servlets can create and access session data, call data, transaction data SIP servlet container provides same functions as http container CAR file equivalent of WAR file Developer SIP Server J. Rosenberg, SIP Summit 2001

What is a SIP Servlet? Servlet engine handles the messy details of SIP Java interface Defines methods that are callbacks when certain events occur doInvte() doBYE() doResponse() Application writer implements servlet class, fills in methods with own code Servlets don’t store state – domain objects are used (later) Servlet can instruction container to Proxy a request Initiate a new request Forward a response Generate a response Servlet engine handles the messy details of SIP Call-Ids, tags, retransmissions, record-routes, vias… Servlet has access to important fields of SIP messages To, From, Request-URI, Contact, body J. Rosenberg, SIP Summit 2001

Example SIP Servlet public class MyServlet implements SipServlet { public void doInvite(SipServletRequest req, SipServletResponse res) { req.getProxy(true).proxy(“sip:user@host”; } J. Rosenberg, SIP Summit 2001

Definition of Servlet Mappings Single server supports many applications When a SIP INVITE arrives, which one (or ones) process the request?? Servlet mappings are rules that create bindings from SIP messages to servlet classes Based on expression matching in fields of message Servlet mappings can be Set up by application deployer Set by application writer Class 1 Rule Match INVITE Class 2 Class 3 Class 4 Rule DB J. Rosenberg, SIP Summit 2001

Deployment Descriptors Third party model requires information to be conveyed from writer to deployer beyond just code Deployment descriptor fills this need Descriptive names and usage of classes Name and usage of entire application Servlet mappings Context parameters References to resources needed by applications EJB Homes JNDI contexts Session timeouts Converged Archive (CAR) File JAR file with specific structure Used to package entire application into one bundle Contains Servlet classes Deployment descriptor Static content HTTP Servlets use WAR file (Web Archive) CAR file is superset of WAR J. Rosenberg, SIP Summit 2001

Relationship to JAIN SIP JAIN SIP is a generic, low-level interface for accessing SIP services Can be used in Clients Servers Gateways Focuses purely on the protocol Complete access to SIP capabilities Supports transactions only SIP Servlet Container is a particular application of JAIN SIP Servlet Servlet SIP Servlet API SIP Servlet Container JAIN SIP SIP Protocol J. Rosenberg, SIP Summit 2001

Relationship to JAIN SIP Servlets focus on high volume carrier grade servers Add significant, non-SIP protocol functions Lifecycle management Domain objects Context and configuration Deployment descriptors Archive files Synchronization primitives Security Add significant SIP protocol functions Construction of requests and responses from domain objects Hide many parts of JAIN SIP Direct access to many headers is not provided Write access to most everything is often restricted Servlets should be defined to allow a SIP container to be built using JAIN SIP SIP Objects in Servlet API defined with interfaces that match JAIN SIP signatures Cannot directly expose JAIN SIP objects, though

Call Processing Language (CPL) XML-based “language” for processing requests intentionally restricted to branching and subroutines no variables (may change), no loops thus, easily represented graphically and most bugs can be detected statically termination assured mostly used for SIP, but protocol-independent integrates notion of calendaring (time ranges) structured tree describing actions performed on call setup event top-level events: incoming and outgoing

CPL Location set stored as implicit global variable Switches: operations can add, filter and delete entries Switches: address language time, using CALSCH notation (e.g., exported from Outlook) priority Proxy node proxies request and then branches on response (busy, redirection, noanswer, ...) Reject and redirect perform corresponding protocol actions Supports abstract logging and email operation

CPL example

CPL example <?xml version="1.0" ?> <!DOCTYPE call SYSTEM "cpl.dtd"> <cpl> <incoming> <lookup source="http://www.example.com/cgi-bin/locate.cgi?user=jones" timeout="8"> <success> <proxy /> </success> <failure> <mail url="mailto:jones@example.com&Subject=lookup%20failed" /> </failure> </lookup> </incoming> </cpl>

CINEMA policy framework User-location services implemented in the Columbia InterNet Extensible Multimedia Architecture (CINEMA) SIP proxy server Supports CPL and SIP CGI and Java SIP servlets Service execution environments and default server behaviors are defined as policies. Separated into user policies (implement service execution environments) and transaction policies (implement default server behavior) User policies can defer handling to transaction policies Policies are defined (abstractly) as classes Methods called for requests, responses, or timeouts for at transaction Methods can invoke actions to proxy or cancel requests, generate or forward responses, or set timeouts

A sample policy invocation

Reactive systems: event model for CINEMA Through version 1.21, the CINEMA SIP proxy used one thread per transaction This is quite inefficient; most transactions spend most of their time waiting for responses and timeouts. New model— reactive systems—changes this reactive systems represent different server operations: policy transaction core, client proxy, response retransmission All operations are represented as sending and receiving messages, and setting and triggering timers As much as possible, operations do not block can block as necessary: e.g., DNS resolution, or SIP CGI invocation Improved performance of SIP proxy server by nearly a factor of 5

Memory management Old model: malloc/free for various data elements (+ valgrind) New model: transaction-based allocation allocate block on new transaction, free when completed Performance-neutral, but less likely to leak memory

Current server-related plans Performance impact of transport protocols UDP vs. TCP vs. TLS Parsing optimization for text protocols lazy parsing benefit of regularized syntax comparison to XML parsing Scaling impact of server architecture thread pool pure event dispatch Service creation impact SIP servlets vs. sip-cgi vs. CPL

Conclusion SIP servers are superficially similar to web servers but performance bottlenecks differ substantially Current emphasis: plain request handling Future problems: service creation presence impact of encryption and authentication