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

• Whats different?
• SIPstone
• Server profiling
• Service creation
• Future plans

3
Internet telephony(SIP Session Initiation
Protocol)
alice_at_yahoo.com
bob_at_example.com
yahoo.com
example.com
192.1.2.4
129.1.2.3
DB
4
Basic SIP message flow
5
Whats 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_at_a.com ? 128.59.16.5 bob_at_x.a.com bob_at_y.a.com
parse
parse
TCP
UDP TCP SCTP
lookup update
map
fork wait
log
7
SIP network architectureScalability requirement
depends on role
Cybercafe
ISP
IP network
IP phones
GW
ISP
MG
MG
SIP/MGC
GW
SIP/PSTN
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
Server redundancyThe problem failure or overload
12
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
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

• ((tr/D)1)TN
• (A/D) B

• ((tr1)/D)TN
• (A/D) (B/D)

D number of database servers N number of
writes (REGISTER) r reads/writes
(INVREG)/REG T write latency t read
latency/write latency
15
Reliability and scalabilityTwo stage
architecture for CINEMA
a_at_example.com
a.example.com _sip._udp SRV 0 0 a1.example.com
SRV 1 0 a2.example.com
a1
s1
a2
sipbob_at_example.com
s2
sipbob_at_b.example.com
b_at_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
Reliability and scalabilityAnalysis, simulation
and measurement proposal
Rp Mp
a1
Rs Ms
P11
s1
a2
S3
? ?R ?P REGISTER INVITE, etc
B2
s2
?/B
?r, ?p
s3
b1
?s
b2
ex

• 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

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

programmer, carrier end user
network servers SIP servlets, sip-cgi CPL
end system VoiceXML VoiceXML (voice), LESS
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
  (?arg1var1arg2var2)
• 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 _at_vinylsiding.com
• if (defined ENVSIP_FROM ENVSIP_FROM
  "sip_at_vinylsiding.com")
• print "SIP/2.0 600 I can't talk right
  now\n\n"
• Make calls from boss urgent
• if (defined ENVSIP_FROM ENVSIP_FROM
  /sipboss_at_mycompany.com/)
• foreach reg (get_regs())
• print "CGI-PROXY-REQUEST reg SIP/2.0\n"
• print "Priority urgent\n\n"

21
SIP Servlets
SIP Servlets
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
22
What is a SIP Servlet?

• 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 dont 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
23
Example SIP Servlet
public class MyServlet implements SipServlet
public void doInvite(SipServletRequest
req,

SipServletResponse res)
req.getProxy(true).proxy(sipuser_at_host

J. Rosenberg, SIP Summit 2001
24
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
Class 2
INVITE
Class 3
Class 4
Rule DB
J. Rosenberg, SIP Summit 2001
25
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
26
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
27
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

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

• lt?xml version"1.0" ?gt
• lt!DOCTYPE call SYSTEM "cpl.dtd"gt
• ltcplgt
• ltincominggt
• ltlookup source"http//www.example.com/cgi-bin
  /locate.cgi?userjones"
• timeout"8"gt
• ltsuccessgt
• ltproxy /gt
• lt/successgt
• ltfailuregt
• ltmail url"mailtojones_at_example.comSubjec
  tlookup20failed" /gt
• lt/failuregt
• lt/lookupgt
• lt/incominggt
• lt/cplgt

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 systemschanges 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