SIP Research at Columbia University

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

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

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

4. Basic SIP message flow

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

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

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

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

9. SIPstone examples

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

11. INVITE REGISTER INVITE REGISTER INVITE REGISTER Replicate registration or search on call Server redundancyThe problem: failure or overload

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

13. ScalabilityLoad 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 P3 D3 r-z

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

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

16. Slave Master Slave Master Reliability and scalabilityAnalysis, simulation and measurement proposal Rp Mp • 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 a1 Rs Ms P=1+1 s1 a2 S=3  = R + P REGISTER+ INVITE, etc B=2 s2 /B r, p s3 s b1 b2 ex

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

18. Service creation • Tailor a shared infrastructure to individual users • traditionally, only vendors (and sometimes carriers) • learn from web models

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

20. sip-cgi examples • Block *@vinylsiding.com: 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"; } }

21. 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 SIP Servlets SIP Servlets Car File Developer SIP Server J. Rosenberg, SIP Summit 2001

22. 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 What is a SIP Servlet? J. Rosenberg, SIP Summit 2001

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

24. 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 Definition of Servlet Mappings Class 1 Rule Match Class 2 INVITE Class 3 Class 4 Rule DB J. Rosenberg, SIP Summit 2001

25. 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 Deployment Descriptors J. Rosenberg, SIP Summit 2001

26. 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 Relationship to JAIN SIP Servlet Servlet SIP Servlet API SIP Servlet Container JAIN SIP SIP Protocol J. Rosenberg, SIP Summit 2001

27. 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 Relationship to JAIN SIP

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

29. CPL • Location set stored as implicit global variable • 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

30. CPL example

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

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

33. A sample policy invocation

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

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

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

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