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

SIP Research at SIP Research at Columbia UniversityColumbia 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)

OverviewOverview

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

DB

Internet telephonyInternet telephony(SIP: Session Initiation Protocol)(SIP: Session Initiation Protocol)

[email protected]@yahoo.com yahoo.com example.comREGISTER

INVITE

INVITE 192.1.2.4129.1.2.3

DNS

Basic SIP message flowBasic SIP message flow

What’s different?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 differencesArchitecture differences

parse

map

log

TCP parse

lookupupdate

fork & wait

UDPTCPSCTP

[email protected] [email protected]@y.a.com

SIP network architectureSIP network architectureScalability requirement depends on roleScalability requirement depends on role

GW

GW

MG

MG

MG

IP network

PSTN

SIP/PSTNSIP/MGC

SIP/MGC

Carrier network

ISP

ISP

Cybercafe

IP

PSTNGW

PBX

IP phones

PSTN phones T1 PRI/BRI

SIPstoneSIPstone 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 examplesSIPstone examples

Server redundancyServer redundancyKnown techniquesKnown techniques

Client-based Cisco phones: primary and backup

proxy DNS

NAPTR, SRV IP address takeover Database redundancy

Server redundancyServer redundancyThe problem: failure or overloadThe problem: failure or overload

REGISTERINVITE

REGISTERINVITEREGISTERINVITE

Replicate registration or search on call

ScalabilityScalabilityLoad sharing: redundant proxies and Load sharing: redundant proxies and databasesdatabases

REGISTER Write to D1 & D2

INVITE Read from D1 or

D2 Database write/

synchronization traffic becomes bottleneck

D1

D2

P1

P2

P3

REGISTER

INVITE

ScalabilityScalabilityLoad sharing: divide the user spaceLoad sharing: divide the user space

Proxy and database on the same host

Stateless proxy can become overloaded Use many

Hashing Static vs dynamic

D1

D2

P1

P2

P3

D3

a-h

i-q

r-z

ScalabilityScalabilityComparison of the two designsComparison of the two designs

((tr/D)+1)TN= (A/D) + B

((tr+1)/D)TN= (A/D) + (B/D)

D1

D2

P1

P2

P3

D1

D2

P1

P2

P3

D2

a-h

i-q

r-z

Total time per DB

D = number of database serversN = number of writes (REGISTER)r = #reads/#writes = (INV+REG)/REGT = write latencyt = read latency/write latency

Low reliabilityHigh scale

Reliability and scalabilityReliability and scalabilityTwo stage architecture for CINEMATwo stage architecture for CINEMA

Master

Slave

Master

Slave

sip:[email protected]:[email protected]

s1

s2

s3

a1

a2

b1

b2

a*@example.com

b*@example.com

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

a.example.com_sip._udp SRV 0 0 a1.example.com SRV 1 0 a2.example.com

b.example.com_sip._udp SRV 0 0 b1.example.com SRV 1 0 b2.example.com

Request-rate = f(#stateless, #groups)

Bottleneck: CPU, memory, bandwidth?Failover latency: ?

ex

Reliability and scalabilityReliability and scalabilityAnalysis, simulation and measurement Analysis, simulation and measurement proposalproposal

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

Master

Slave

Master

Slave

s1

s2

s3

a1

a2

b1

b2

S=3

B=2

P=1+1

ex

= R + P

REGISTER+INVITE, etc

r, p s

/B

Rs Ms

Rp Mp

High availabilityHigh availabilityFailover in our test bed - CINEMAFailover in our test bed - CINEMA

Slave/master

Webscripts

D2

P2

Master/slave

Webscripts

D1

P1

phone.cs.columbia.edu sip2.cs.columbia.edu

REGISTER

proxy1 = phone.csbackup = sip2.cs

_sip._udp SRV 0 0 5060 phone.cs.columbia.edu SRV 1 0 5060 sip2.cs.columbia.edu

replication

Service creationService creation

programmer, carrier

end user

network servers

SIP servlets, sip-cgi

CPL

end system VoiceXML VoiceXML (voice),LESS

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

sip-cgisip-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 examplessip-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:[email protected]/) { foreach $reg (get_regs()) { print "CGI-PROXY-REQUEST $reg SIP/2.0\n"; print "Priority: urgent\n\n"; }}

SIP ServletsSIP Servlets 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 Car File

SIP Server

Developer

J. Rosenberg, SIP Summit 2001

What is a SIP Servlet?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 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 ServletExample SIP Servletpublic 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 Definition of Servlet MappingsMappings 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

RuleMatch

Class 1

Class 2

Class 3

Class 4

Rule DB

INVITE

J. Rosenberg, SIP Summit 2001

Deployment DescriptorsDeployment 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 SIPRelationship 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

SIP Protocol

SIP ServletContainer

Ser

vlet

JAIN SIP

SIP Servlet API

Ser

vlet

J. Rosenberg, SIP Summit 2001

Relationship to JAIN SIPRelationship 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 Call Processing Language (CPL)(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

CPLCPL 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

CPL exampleCPL example

String-switchfield: from

match:*@example.com

otherwise

proxytimeout: 10s

locationurl: sip:jones@

example.comvoicemail.

merge: clear

locationurl: sip:jones@

example.com

redirect

Call

busy

timeout

failure

CPL exampleCPL 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:[email protected]&Subject=lookup%20failed" /> </failure> </lookup> </incoming></cpl>

CINEMA policy frameworkCINEMA 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 invocationA sample policy invocation

Reactive systems: event Reactive systems: event model for CINEMAmodel 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 managementMemory 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 Current server-related plansplans 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

ConclusionConclusion 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