Transcript Services in CINEMA

Reliable and Scalable Internet
Telephony
by Kundan Singh
Advisor: Henning Schulzrinne
Computer Science Department,
Columbia University, New York
Feb 14, 2005
Agenda for the presentation





What is Internet telephony?
What is the problem?
Why is it important?
Results so far
Difference with related work
30 slides
2
Internet telephony

Multimedia calls over the Internet

Signaling



Media



SIP: Session Initiation Protocol
Where is [email protected] located?
Audio/video codecs
RTP: Real-time Transport Protocol
Elements (devices)

End system, server (proxy/registrar),
gateway, MCU, …
3
Internet telephony infrastructure
CINEMA: Columbia InterNet Extensible Multimedia Architecture
Telephone
switch
Local/long distance
1-212-5551212
CINEMA servers
rtspd: media server
sipconf:
RTSP
Conference server
PSTN
RTSP clients
Department
PBX
Internal
Telephone
Extn: 7040
SIP/PSTN Gateway
Quicktime
713x
sipum:
Unified
messaging
sipd:
Proxy, redirect,
Registrar server
SQL
database
cgi
vxml
Web
server
Web based
configuration
SIP
VXML
siph323:
SIP-H.323
translator
My work
H.323
NetMeeting
4
CINEMA
My contribution in design and implementation
CINEMA Applications
RTSP media
server
SIP/VoiceXML SIP/H.323
browser
gateway
rtspd
sipvxml
Flite
Xerces-C
SIP/RTP
conferencing
sip323
SIP/RTSP
unified messaging
sipconf
SIP proxy
server
sipum
sipd
Xerces-C
OpenH323
CINEMA Libraries
libsip
Basic
SIP
library
rtplib++
libcine
librtsp
RTP
library
Utilities
parsing
IPv6
RTSP
client
MySQL
PWLib
Resparse
libsipapi
SIP UA
library
libconf
RTP
audio
mixer
libmedia
Recordi
ng, files
… and web-based GUI
libNT
Win32
stub
libdict libdb++
Hash
table
mySQL
interface
libsnmp libcanon
SIP
MIB
canonic
alize
C/C++: 58K out of 187 KLOC
Tcl: 30 KLOC
5
My research background
PhD@columbia
MS@columbia
Work@motorola India
Undergrad@BITS India
1997
1999
2000
Reliability and
scalability
VoIP infrastructure
2001
2002
2003
2004
2005
6
Telephone reliability
(PSTN: Public Switched Telephone Network)
database (SCP)
for freephone,
calling card, …
signaling network
(SS7)
local telephone switch
(class 5 switch)
signaling
router
10,000
customers
(STP)
20,000 calls/hour
regional telephone switch
(class 4 switch)
100,000 customers
150,000 calls/hour
“bearer” network
database (SCP)
10 million customers
2 million lookups/hour
signaling router (STP)
1 million customers
1.5 million calls/hour
telephone switch
(SSP)
7
Internet telephony
(SIP: Session Initiation Protocol)
[email protected]
yahoo.com
example.com
INVITE
REGISTER
INVITE
129.1.2.3
[email protected]
192.1.2.4
DB
DNS
8
SIP network architecture
Scalability requirement depends on role
Cybercafe
ISP
IP network
IP phones
ISP
SIP/MGC
SIP/PSTN
Carrier network
GW
GW
MG
IP
PSTN
GW
MG
MG
PBX
PSTN phones
SIP/MGC
T1 PRI/BRI
PSTN
9
Reliability and scalability
for call routing, registration, conferencing, voicemails

Requirements

Reliable


Scalable



Mean Time Between Failures (MTBF), Mean Time To Recover
(MTTR), percentage availability
Registration rate, call rate, #requests/s
Server and network components
Proposed solutions

Server redundancy



Apply existing web-redundancy designs
Evaluate quantitatively
Peer-to-peer


Novel P2P-SIP architecture
Evaluate quantitatively
10
Server redundancy
The problem: failure or overload
INVITE
INVITE
REGISTER
INVITE
REGISTER
Replicate registration
or
search on call
REGISTER
11
Server redundancy
Known techniques

Client-based


DNS



Cisco phones: primary and backup proxy
NAPTR, SRV
IP address takeover
Database redundancy
12
High availability
Failover in our test bed - CINEMA
Web
scripts
D1
Master/
slave
P1
phone.cs.columbia.edu
_sip._udp
SRV 0 0 5060 phone.cs.columbia.edu
SRV 1 0 5060 sip2.cs.columbia.edu
Web
scripts
replication
D2
Slave/
master
P2
sip2.cs.columbia.edu
REGISTER
proxy1 = phone.cs
backup = sip2.cs
13
High availability
More issues

Client re-sends INVITE to P2



Immediately on ICMP error
Or after 10s otherwise
sipd has in-memory cache



Refresh registration much before expiry
Cisco phone registers to P1 and P2
Web access gets delayed information
14
High availability
Master/
slave
Measurements on failover





Caller
P2
P1
User unavailability


Client retry timeout
(T1), DNS TTL
D2
D1
DNS
Call setup latency
Slave/
master
None (refresh; double
register)
Registration refresh
interval (Tr), cache
refresh interval (Tc),
client retry timeout
(T2), DB replication
delay, DNS TTL
Web access latency
#servers

Tradeoff: reliability vs
capacity
T1
P1
Tc
P2
D1
D2
Callee
Td
A
Tc
Tr
T2
A
Tc
15
Scalability
Load sharing: redundant proxies and databases
P1

REGISTER

D1


D2
P3
Write to D1 & D2
INVITE

P2
INVITE
REGISTER
Read from D1 or D2
Database write/
synchronization
traffic becomes
bottleneck
16
Scalability
Load sharing: divide the user space
P1
a-h

D1

P2
i-q

D2

Use many
Hashing

P3
r-z
Proxy and database
on the same host
Stateless proxy can
become overloaded
Static vs dynamic
D3
17
Scalability
Comparison of the two designs
P1
P1
a-h
D1
D1
P2
P3
P2
i-q
D2
D2
High scale
Low reliability
P3
r-z
D2
Total time per DB
((tr/D)+1)TN
((tr+1)/D)TN
= (A/D) + B
= (A/D) + (B/D)
D
N
r
T
t
=
=
=
=
=
number of database servers
number of writes (REGISTER)
#reads/#writes = (INV+REG)/REG
write latency
read latency/write latency
18
Reliability and scalability
Two stage architecture for CINEMA
a*@example.com
a1
s1
Master
a2
a.example.com
_sip._udp
SRV 0 0 a1.example.com
SRV 1 0 a2.example.com
Slave
sip:[email protected]
s2
sip:[email protected]
b*@example.com
s3
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
b1
Master
b2
Slave
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?
19
Failover latency: ?
Reliability and scalability
Future work: analysis and measurement
Rp Mp
a1
Master
Rs M s
s1
 =  R + P
REGISTER+
INVITE, etc
ex

S=3
s2
s3

P=1+1
a2
Slave
B=2
/B
s
b1
Master
b2
Slave
r, p
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
20
Server-based vs peer-to-peer
C
C
S
C

Server-based

C

C

P
P

Peer-to-peer

P
P
P
Cost: maintenance, configuration
Central points of failures
Controlled infrastructure (e.g., DNS)


Robust: no central dependency
Self organizing, no configuration
Scalability ?
21
We propose: P2P-SIP


Unlike server-based SIP architecture
Unlike proprietary Skype architecture


Robust and efficient lookup using DHT
Interoperability


Hybrid architecture


Lookup in SIP+P2P
Unlike file-sharing applications


DHT algorithm uses SIP communication
Data storage, caching, delay, reliability
Disadvantages

Lookup delay and security
22
P2P-SIP
Background: DHT (Chord)
1
54
8
58
10
14
47
21
32
38
14
8+2 = 10
14
8+4 = 12
14
8+8 = 16
21
8+16=24
32
8+32=40
42

Finger table: logN

24
8+1 = 9


38
node
Identifier circle
Keys assigned to successor
Evenly distributed keys and nodes

42
Key
30

ith finger points to first node
that succeeds n by at least 2i-1
Stabilization for join/leave
23
P2P-SIP
Design Alternatives
1
54
58
servers
47
42
38
38
8
d471f1
14 10
d46a1c
21
d467c4
d462ba
d4213f
1
54
10
32
24 30
Route(d46a1c)
d13da3
65a1fc
38
24 30
clients
Use DHT in
server farm
Use DHT for all
clients; But some
are resource limited
Use DHT among super-nodes
24
P2P-SIP
Node architecture: registrar, proxy, user agent
User interface (buddy list, etc.)
On reset Signout,
transfer
On startup
Leave
Discover
Peer found/
Detect NAT
ICE

Join
Multicast REG
Signup,
Find buddies
IM,
call
User location
Find
Audio devices
DHT (Chord)
REG
SIP
REG, INVITE,
MESSAGE
Codecs
RTP/RTCP
DHT communication using SIP REGISTER



Known node: sip:[email protected]
Unknown node: sip:[email protected]
User: sip:[email protected]
25
P2P-SIP
Problems


Mapping node identifier to SIP URI
Node startup







Discovery, join, maintenance
Node shutdown or failure
Adaptor for existing phones
NAT/firewall traversal
Offline messages
Multi-party conferencing
Security
26
P2P-SIP
Implementation
31
29
1

31
30
sippeer: C++,
Linux, Chord

25
26
26

9

19
15
11

Node join and form
the DHT
Node failure is
detected and DHT
updated
Registrations
transferred on node
shutdown
Co-located sipc can
use sippeer service
27
P2P-SIP
Future work: scalability evaluation

#messages depends on




Keep-alive and finger table refresh rate
Call arrival distribution
User registration refresh interval
Node join, leave, failure rates
M={rs+ rf(log(N))2} + c.log(N) + (k/t)log(N) + (log(N))2/N

#nodes = f(capacity,rates)


CPU, memory, bandwidth
Verify by measurement and profiling
28
P2P-SIP
Future work: reliability and call setup latency evaluation

User availability depends on






Super-node failure distribution
Node keep-alive and finger refresh rate
User registration refresh rate
Replicate user registration
Measure effect of each
Call setup latency

Same as DHT lookup latency: O(log(N))




Calls to known locations (“buddies”) is direct
DHT optimization can further reduce latency
User availability and retransmission timers
Measure effect of each
29
Summary and future work


Internet telephony infrastructure
Server redundancy


Two stage architecture evaluation
Server-less/peer-to-peer VoIP



Quantitative evaluation
Multi-domain deployment
PSTN interworking
30
Publications
Conference, workshop, technical report, magazine
1.
2.
H. Schulzrinne, K. Singh and X. Wu, "Programmable Conference Server", Columbia University Technical Report CUCS-040-04, NY, Oct 2004.
K. Singh and H. Schulzrinne, "Peer-to-peer Internet Telephony using SIP", New York Metro Area Networking Workshop, CUNY, NY, Sep 2004.
K. Singh and H. Schulzrinne, "Peer-to-peer Internet Telephony using SIP", Columbia University Technical Report CUCS-044-04, NY, Oct 2004.
3.
4.
K. Singh and H. Schulzrinne, "Failover and Load Sharing in SIP Telephony", Columbia University Technical Report CUCS-011-04, NY, May 2004.
K. Singh, Xiaotao Wu, J. Lennox and H. Schulzrinne, "Comprehensive Multi-platform Collaboration", MMCN 2004 - SPIE Conference on
Multimedia Computing and Networking, Santa Clara, CA, Jan 2004.
K. Singh, Xiaotao Wu, J. Lennox and H. Schulzrinne, "Comprehensive Multi-platform Collaboration", Columbia University Technical Report CUCS-027-03,
NY, Nov 2003.
5.
6.
M. Buddhikot, A. Hari, K. Singh and S. Miller, "MobileNAT: A new Technique for Mobility across Heterogeneous Address Spaces", WMASH
2003 - ACM International Workshop on Wireless Mobile Applications and Services on WLAN Hotspots, San Diego, CA, Sep 2003.
K. Singh, A. Nambi and H. Schulzrinne, "Integrating VoiceXML with SIP services", ICC 2003 - Global Services and Infrastructure for Next
Generation Networks, Anchorage, Alaska, May 2003.
K. Singh, A. Nambi and H. Schulzrinne, "Integrating VoiceXML with SIP services", Second New York Metro Area Networking Workshop, Columbia
University, NY, Sep 2002.
7.
K. Singh, W. Jiang, J. Lennox, S. Narayanan and H. Schulzrinne, "CINEMA: Columbia InterNet Extensible Multimedia Architecture", Columbia
University Technical Report CUCS-011-02, NY, May 2002.
W. Jiang, J. Lennox, H. Schulzrinne and K. Singh, "Towards Junking the PBX: Deploying IP Telephony", NOSSDAV 2001.
W. Jiang, J. Lennox, S. Narayanan, H. Schulzrinne, K. Singh and X. Wu, "Integrating Internet Telephony Services", IEEE Internet Computing (magazine),
May/June 2002 (Vol. 6, No. 3).
8.
9.
K. Singh, Gautam Nair and H. Schulzrinne, "Centralized Conferencing using SIP", 2nd IP-Telephony Workshop (IPTel'2001), April 2001.
K. Singh and H. Schulzrinne, "Unified Messaging using SIP and RTSP", IP Telecom Services Workshop 2000, Atlanta, Georgia, U.S.A, Sept 2000.
K. Singh and H. Schulzrinne, "Unified Messaging using SIP and RTSP", Columbia University Technical Report CUCS-020-00, NY, Oct 2000.
10. K. Singh, H.Schulzrinne, "Interworking Between SIP/SDP and H.323", 1st IP-Telephony Workshop (IPTel'2000), April 2000.
K. Singh and H. Schulzrinne, "Interworking Between SIP/SDP and H.323", Columbia University Technical Report CUCS-015-00, NY, May 2000.
31
Backup slides
32
MobileNAT
Architecture
128.59.16.149
135.180.32.4
80
1733

Two IP addresses

CN

128.59.16.149

Virtual IP (fixed host-id)
Actual IP (routable; changes)
DHCP, NAT, mobility manager
Application
Socket
TCP/UDP
IP
V=135.180.32.4
Anchor node (AN)
MN
moves
Addr “V”
MN
Shim Layer
135.180.32.6
A=135.180.54.7
135.180.32.4
128.59.16.149
1733 80
135.180.32.4
128.59.16.149
1733 80
Actual IP
Virtual IP
Addr “A”
Net IF
33
MobileNAT
Comparison with other work
CIP
Hawaii HMIP
(RR)
IDMP
TeleMIP
MIP
LR
MIP
RO
SIP
IPv Mobile Virtual
NAT
6
NAT
MIP messaging Y
N
Y
Y
Y
-
-
N
Y
N
N
Inter-tunnel
Y
Y
Y
Y
Y
N
Y
N
O
O
N
Intra-tunnel
-
N
N
Y
Y
-
-
-
O
O
N
Paging
O
Y
Y
Y
Y
-
-
N
Y
UD
N
Host ID
HA
HA
CoA
CoA
LCoA
-
-
SIP
HA CoA
virtual
signaling
Y
Data
Y
Y
Y
Y
Y
Y
Y
DHCP/
MM
Y
CN modify?
N
N
N
N
N
Y
Y
-
N
N
Y
MN modify?
Y
Y
Y
Y
Y
Y
Y
-
Y
Y
Y
Router modify? FA
Y
Y
FA
FA
-
-
-
O
N
N
NAT support
Y1
Y
Y
Y
Y
IN
IN
Y
IN Y
IN
Non-mobile IP
nodes
Y
N
Y
Y
Y
-
-
-
Y
Y
IN
Triangular route Y
Y
Y
Y
Y
N
N
N
N
N/Y
N
MIP
Y: yes N: no - :N/A O: optional IN:independent UD: Under Development
1: We assume Mobile IP with UDP tunneling for NAT
34
Related work
IP telephony and multimedia communication

Unlike low cost VoIP: Vonage, AT&T


There are enterprise IPtel: Cisco, Nortel


But redundancy architecture, interoperability,
distributed components model differ
Collaboration: CSCW, SIGGROUP



We provide enterprise infrastructure
Unlike web-centric, or application specific
We provide standard-based multimedia
collaboration platform
Multimedia conferencing: Mbone, H.323

Ours is SIP-based infrastructure, reuse existing
tools and protocols such as RTSP, media server
35
Related work
Comprehensive multi-platform collaboration
Goal: Alternate between
synchronous and
asynchronous
communication, and access
from different devices and
clients.

Asynchronous (loosely coupled)



Video conference, IM, screen
sharing, floor control, …
File sharing, message board, …
Messaging and notifications
Personalized view

We try to incorporate…

Long lived groups




Design teams, committees,
college classes
Asymmetric events

Synchronous (tightly coupled)



Lecture and lecture series
Short-lived spontaneous
interaction
Current practice



Email, teleconference
Vendor specific tools,
platform dependence
Application specific

E.g., collaborative software
development
Per-user calendar, access
control, address book
36
Multi-party collaboration
What is done, and what is left.

Sipconf: conference server




Cascaded conference mixer


Audio, video, IM, screen, shared browsing,
floor control
No XCON yet: use web interface
Small to medium size conferences
#participants, audio delay
Failover

State sharing between servers
37
Related work
Availability for (web) servers

Availability = f(reliability,maintainability)



Reliability: time to failure pdf
Maintainability: time to recover pdf
Existing work on failover




TCP connection migration
IP address takeover
MAC address takeover
Reliable server pooling



Requires new protocol support in clients
Reliability analysis tools (www.relexsoftware.com)
Availability in the face of (DoS) attacks
38
Related work
Scalability for (web) servers

Existing work




HTTP vs SIP


Connection dispatcher
Content/session-based redirection
DNS-based load sharing
UDP+TCP, signaling not bandwidth intensive, no
caching of response, read/write ratio is
comparable for DB
SIP scalability bottleneck


Signaling (chapter 4), real-time media data,
gateway
302 redirect to less loaded server, REFER session
to another location, signal upstream to reduce 39
Related work
SIPStone: SIP server performance metric

Steady state rate for


successful registration, forwarding and unsuccessful call attempts
measured using 15 min test runs.
Measure: #requests/s with given delay constraint.



Performance=f(#user,#DNS,UDP/TCP,g(request),L) where g=type
and arrival pdf (#request/s), L=logging?
For register, outbound proxy, redirect, proxy480, proxy200.
Parameters


Measurement interval, transaction response time, register/s, calls/s,
transaction failure probability<5%,
Shortcomings:

does not consider forking, scripting, Via header, packet size,
different call rates, SSL. Is there linear combination of results?
40
Related work
3GPP (release 5)’s IP Multimedia core network Subsystem uses SIP

Proxy-CSCF (call session control function)


Interrogating-CSCF



First contact in operator’s network.
Locate S-CSCF for register
Serving-CSCF



First contact in visited network. 911 lookup. Dialplan.
User policy and privileges, session control service
Registrar
Connection to PSTN

MGCF and MGW
41
Related work: Skype
From the KaZaA community
P
P
P

P
P
P
P

P

P
Host cache of some super nodes
Bootstrap IP addresses
Auto-detect NAT/firewall settings

P
P
P





Protocol among super nodes – ??
Allows searching a user (e.g., kun*)
History of known buddies
All communication is encrypted
Promote to super node



Similar to STUN and TURN
Based on availability, capacity
Conferencing
Problems:

Proprietary, single service, centralized login
42
Related work
P2P

P2P networks



Skype and related systems


Unstructured (Kazaa, Gnutella,…)
Structured (DHT: Chord, CAN,…)
Flooding based chat, groove, Magi
P2P-SIP telephony


Proprietary: NimX, Peerio, damaka
File sharing: SIPShare
43
Why we chose Chord?

Chord can be replaced by another






As long as it can map to SIP
High node join/leave rates
Provable probabilistic guarantees
Easy to implement
X proximity based routing
X security, malicious nodes
44
Related work
JXTA vs Chord in P2P-SIP

JXTA



Protocol for communication (peers, groups,
pipes, etc.)
Stems from unstructured P2P
P2P-SIP

Instead of SIP, JXTA can also be used

Separate search (JXTA) from signaling (SIP)
45
P2P-SIP
Node Startup
columbia.edu
sipd

REGISTER
SIP

DB

[email protected]
DHT

Detect peers


REGISTER alice=42
42
58
12
14

REGISTER with SIP registrar
Discover peers: multicast REGISTER
Join DHT using node-key=Hash(ip)
REGISTER with DHT using userkey=Hash([email protected])
Dialing out

Call, instant message, etc.
INVITE sip:[email protected]
MESSAGE sip:[email protected]
REGISTER bob=12

Last seen, SIP NAPTR/SRV, DHT
32
46
P2P-SIP
Node Leaves

Graceful leave

REGISTER key=42


Failure
REGISTER

42
OPTIONS
DHT


42
Un-REGISTER
Transfer registrations
Attached nodes detect and
re-REGISTER
New REGISTER goes to new
super-nodes
Super-nodes adjust DHT
accordingly
47
P2P-SIP
Advanced services

Offline messages


INVITE or MESSAGE fails => Responsible
node stores voicemail, instant message.
Conferencing

Mixer, full mesh, multicast
48
P2P-SIP
Security – open issues (threats, solutions, issues)

More threats than server-based


Privacy, confidentiality
Malicious node



“free riding”, motivation to become super-node
Existing solutions



Focus on file-sharing (non-real time)
Centralized components (boot-strap, CA)
Assume co-operating peers




Don’t forward all calls, log call history (spy),…
works for server farm in DHT
Collusion
Hide security algorithm (e.g., yahoo, skype)
Chord

Recommendations, design principles, …
49
Server-based vs peer-to-peer
Reliability,
failover latency
DNS-based. Depends on client
retry timeout, DB replication
latency, registration refresh
interval
DHT self organization and
periodic registration refresh.
Depends on client timeout,
registration refresh interval.
Scalability,
number of users
Depends on number of servers
in the two stages.
Depends on refresh rate,
join/leave rate, uptime
Call setup
latency
One or two steps.
O(log(N)) steps.
Security
TLS, digest authentication,
S/MIME
Additionally needs a reputation
system, working around spy nodes
Maintenance,
configuration
Administrator: DNS, database,
middle-box
Automatic: one time bootstrap
node addresses
PSTN
interoperability
Gateways, TRIP, ENUM
Interact with server-based
infrastructure or co-locate peer node
with the gateway
50
My contribution in CINEMA
Sip-h323: signaling translator

Background: ITU-T’s H.323



Binary ASN.1 PER, collection of protocols (H.245, H.225.0, Q.931, RAS,
H.450.x)
H.323 gatekeeper similar but not same as SIP server
Problems in interworking

Multi-stage dialing in H.323v1


User registration



Both SIP and H.323 users should be reachable
Session description is more complex


Fast start in v2 is optional
End system should select the codecs
Security and QoS: end-to-end or not?
Solution




List different scenarios
No modification in SIP or H.323
Direct RTP traffic if possible
Implementation
51
My contribution in CINEMA
Sipum: Unified messaging using SIP and RTSP

Problem



Existing systems have voicemail with PBX or phone, or send voice
attachments in email
Downloading the whole message is not desirable
Solution






Using existing standards (RTSP, SIP) and tools (web, media player)
Distributed components for different architectures (PBX, phone,
service provider)
Many ways to retrieve your message (RTSP, SIP, phone, web)
Message deletion issues
Call reclaiming
Implementation
52
My contribution in CINEMA
Sipconf: Centralized conferencing using SIP/RTP

Problem



Multicast is not available and ad hoc conference is useful for small
number of users
Heterogeneous clients (some have video also; or different audio
codecs)
Solution







Audio mixer, video forwarder
IM, VNC screen sharing, shared web browsing
Playout delay adjustments
Web based configuration, floor control
G.711 A/Mu, G.721, DVI, ADPCM, G.722, …
Modular: libconf, libmedia, rtplib++
Implementation and performance evaluation
53
My contribution in CINEMA
Sipvxml: SIP-based VoiceXML browser

Background



Problem


VoiceXML for touch tone-based service programming
Backend scripts (CGI) or servlets
Then existing solutions were PSTN based
Solution



First SIP-VoiceXML implementation
SIP interface (works with PSTN via a gateway)
Example cgi scripts





Calling card service
Joining a conference (Ajay)
Accessing voice mail (Ajay)
Email by phone (Pimrampai)
Auto attendant (Sean)
54
My contribution in CINEMA
libsip++: SIP user agent library in C++

All the applications (sipum, sipconf, siph323, sipvxml) use a
common underlying library


Unlike JAIN-SIP or SIP servlet, libsip++ is more high level with
facility to access low level features




Similar API for H.323 defined using wrapper around openH323
Dialog, call, endpoint, registration are defined as objects (JAIN-SIP
1.1 added dialog as object)
Uses underlying transaction and parsing library shared with sipd
Test user agent (sipua) is used as tools, e.g., for sipconf testing
Documentation is at
http://www.cs.columbia.edu/~kns10/software/siplib
55
My contribution in CINEMA
GUI: web-based user interface


Configuration, user profile, etc., stored in SQL DB
Front end as web-based GUI




User friendly (beginner vs advanced, context help)
Asynchronous collaboration


CGI scripts in Tcl
About 100 pages for various configuration
Voicemail, file sharing, IM archive, groups, address book, calendar
Undergone three iterations

See current version at http://phone.cs.columbia.edu/cinema/
56