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. Internet telephony (SIP: Session Initiation Protocol)
yahoo.com
example.com
REGISTER
INVITE
DNS DB
Unlike PSTN, call stateless proxies.
DNS
Routing (BGP, OSPF)
Link connection
Software failure
QoS

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
parse
TCP
parse
UDP
TCP
SCTP
lookup
update
map
fork & wait
log

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

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 for details

9. SIPstone examples

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

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

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

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

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

15. Reliability and scalability Two stage architecture for CINEMA a1
Master
a.example.com
_sip._udp
SRV 0 0 a1.example.com
SRV 1 0 a2.example.com s1 a2
Slave s2
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: ?

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

17. 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, 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 phone.cs.columbia.edu
SRV 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 (?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: Make calls from boss urgent:
if (defined $ENV{SIP_FROM} && $ENV{SIP_FROM} =~ {
print "SIP/ I can't talk right now\n\n"; }
Make calls from boss urgent:
if (defined $ENV{SIP_FROM} && $ENV{SIP_FROM} =~ {
foreach $reg (get_regs()) {
print "CGI-PROXY-REQUEST $reg SIP/2.0\n";
print "Priority: urgent\n\n";

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

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

23. Example SIP Servlet public class MyServlet implements SipServlet {
public void doInvite(SipServletRequest
req,
SipServletResponse
res) { }
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
INVITE
Class 2
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 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 operation

30. CPL example

31. CPL example <?xml version="1.0" ?>
<!DOCTYPE call SYSTEM "cpl.dtd">
<cpl>
<incoming>
<lookup source="
timeout="8">
<success>
<proxy />
</success>
<failure>
<mail />
</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