1. Reliable and Scalable Multimedia Communication
PhD thesis proposal
by Kundan Singh
Advisor: Henning Schulzrinne
Nov 29, 2004
Joined Columbia in Fall 1999
MS – Sep 1999 to Dec 2000
PhD – Jan 2001 onwards (fourth year)
Research interest
Internet telephony and multimedia communication

2. Agenda for the presentation
What is the problem?
Why is it important?
Results so far
Difference with related work
Plan for finishing
27 slides (plus backup)

3. Outline of the proposal document
publications
Nossdav’01 (Towards junking the PBX)
IEEE IC’02 (Integrating Internet telephony services)+detailed TR
Iptel’01 (Centralized conferencing using SIP)
IPTS’01 (Unified messaging using SIP and RTSP)+TR
Iptel’00 (Interworking between SIP/SDP and H.323)+TR+ID
ICC’03 (Integrating VoiceXML with SIP services)+NYMAN’02
WMASH’03 (MobileNAT)+pending journal
NYMAN’04 (P2P IP telephony) + TR
TR (Failover and load sharing in SIP)
MMCN’04 (Comprehensive multi-platform collaboration) + detailed TR
Table of content
Introduction
Related work
Internet telephony infrastructure
Architecture (unified messaging, conferencing, SIP-H.323 translator, IVR, GUI, security, NAT traversal),
interoperability
Request routing and user registration
Requirements, redundancy, P2P
Multi-party collaboration
Reliability and scalability
Research plan
I will focus my presentation on the redundancy and P2P topic (chapter 4).

4. Telephone reliability (PSTN: Public Switched Telephone Network)
database (SCP) for freephone, calling card, …
signaling network
(SS7)
signaling router (STP)
local telephone switch (class 5 switch) 10,000 customers
20,000 calls/hour
database (SCP) 10 million customers
2 million lookups/hour
signaling router (STP) 1 million customers
1.5 million calls/hour
regional telephone switch (class 4 switch) 100,000 customers
150,000 calls/hour
% availability
Cannot lose in-progress calls
Preserving billing data is important
Can lose calls during call-setup
“bearer” network
telephone switch (SSP)

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

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

7. Reliability and scalability for call routing, registration, conferencing, voicemails
Requirements
Reliable
Mean Time Between Failures (MTBF), Mean Time To Recover (MTTR), percentage availability
Scalable
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
MTTR depends on a number of components such as DNS TTL, ARP cache, DHCP timers, SIP registration and call setup latency depending on the failover architecture
100 requests/s, 1hr=3600s refresh interval => users.
Complicated by mobility (higher registration rate), authentication
Our proxy server does 300 registrations and 90 calls/s.
Same infrastructure can be used for generic multimedia communication on the Internet.

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

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

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

11. 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
Reducing refresh interval much before expiry makes user appear available when he is not (Phone dies without un-registering)
e.g., refresh interval = (Expires/2)-e
Database replication causes problem for
Redundant voic different vmail contacts for P1 and P2=>don’t replicate. Or use DNS NAPTR/SRV.
conference server: must be tied with conference server state replication also.

12. High availability Measurements on failover
Master/
slave
Slave/
master D1 D2
DNS
Call setup latency
Client retry timeout (T1), DNS TTL
User unavailability
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
Caller P1 P2 T1
Callee P1 D1 P2 D2 Tc Td Tc A Tr T2 A Tc

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

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

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

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

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

18. Server-based vs peer-to-peer
Cost: maintenance, configuration
Central points of failures
Controlled infrastructure (e.g., DNS)
Peer-to-peer
Robust: no central dependency
Self organizing, no configuration
Scalability ? C S P
IETF Zeroconf: without DHCP/DNS, do IPv4 address allocation, DNS resolution, service discovery (SRV), Multicast address allocation.
/16 ( ) can be used for other devices in local network. Not simultaneously.

19. We propose: P2P-SIP Unlike server-based SIP architecture
Unlike proprietary Skype architecture
Robust and efficient lookup using DHT
Interoperability
DHT algorithm uses SIP communication
Hybrid architecture
Lookup in SIP+P2P
Unlike file-sharing applications
Data storage, caching, delay, reliability
Disadvantages
Lookup delay and security
Problems with skype: proprietary architecture, single service, centralized component.
Zipf: straight line on double log axes.

20. P2P-SIP Background: DHT (Chord)
Key
node
8+1 = 9 14
8+2 = 10
8+4 = 12
8+8 = 16 21
8+16=24 32
8+32=40 42 1 54 8 58 10 14 47 21
Lookup in finger table for the furthest node that precedes the key
In a system with N nodes and K keys, with high probability,
each node receives at most K/N keys
each node maintains information about O(logN) other nodes
lookups resolved with O(logN) hops
No network locality.
Replicas need to have explicit consistency.
Optimizations:
location: weight neighbor nodes by RTT.
When routing choose the neighbor who is closer to destination with lowest RTT from me.
Reduce path latency.
Multiple physical nodes per virtual node.
What if a node leaves?
Identifier circle
Keys assigned to successor
Evenly distributed keys and nodes
Finger table: logN
ith finger points to first node that succeeds n by at least 2i-1
Stabilization for join/leave 42 38 32 38 24 30

21. P2P-SIP Design Alternatives1 8 14 21 32 38 58 47 10 24 30 54 42
65a1fc
d13da3
d4213f
d462ba
d467c4
d471f1
d46a1c
Route(d46a1c)
servers 1 54 10 38 24 30
Hierarchy
Dynamically adapt
clients
Use DHT in server farm
Use DHT for all clients; But some are resource limited
Use DHT among super-nodes

22. P2P-SIP Node architecture: registrar, proxy, user agent
User interface (buddy list, etc.)
Signup,
Find buddies
IM,
call
On reset
Signout,
transfer
On startup
User location
Leave
Find
Discover
Join
Audio devices
DHT (Chord)
REG, INVITE,
MESSAGE
Codecs
Peer found/
Detect NAT
Multicast REG
REG
ICE
SIP
RTP/RTCP
DHT communication using SIP REGISTER
Known node:
Unknown node:
User:

23. P2P-SIP Implementation31
sippeer: C++, Linux, Chord
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 29 1 31 30 25 26 26 9 19 11 15

24. P2P-SIP Evaluation - scalability
#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

25. P2P-SIP Evaluation – reliability and call setup latency
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
Advanced services also possible.
the ConChord system for
certificate storage, the Tarzan system for anonymous communications, and
the proposal to use Chord as replacement of standard DNS hierarchies by
Cox, Muthitacharoen, and Morris -- this last proposal is most similar in
spirit to your work

26. Thank you Research plan Timeline Work Jul’04-Oct’04
P2P-SIP implementation
Oct-Nov’04
Two-stage server setup
Dec’04
P2P-SIP performance evaluation/profiling
Nov-Dec’04
Two-stage server evaluation (project student)
Jan’05
Interworking with Nortel MCS
Feb’05
Conference server evaluation
Mar’05
Start writing thesis
May’05
Thesis defense
Thank you

27. Publications Conference, workshop, technical report, magazine
H. Schulzrinne, K. Singh and X. Wu, "Programmable Conference Server", Columbia University Technical Report CUCS , 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 , NY, Oct 2004.
K. Singh and H. Schulzrinne, "Failover and Load Sharing in SIP Telephony", Columbia University Technical Report CUCS , NY, May 2004.
K. Singh, Xiaotao Wu, J. Lennox and H. Schulzrinne, "Comprehensive Multi-platform Collaboration", MMCN 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 , NY, Nov 2003.
M. Buddhikot, A. Hari, K. Singh and S. Miller, "MobileNAT: A new Technique for Mobility across Heterogeneous Address Spaces", WMASH 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 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.
K. Singh, W. Jiang, J. Lennox, S. Narayanan and H. Schulzrinne, "CINEMA: Columbia InterNet Extensible Multimedia Architecture", Columbia University Technical Report CUCS , 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).
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 , NY, Oct 2000.
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 , NY, May 2000.

28. Backup slides

29. Internet telephony infrastructure CINEMA: Columbia InterNet Extensible Multimedia Architecture
CINEMA servers
Telephone
switch
Local/long distance
sipconf:
Conference server
rtspd: media server
Quicktime
RTSP
PSTN
RTSP clients
Department
PBX
sipum:
Unified
messaging
sipd:
Proxy, redirect,
Registrar server
Internal
Telephone
Extn: 7040
713x
SQL
database
cgi
Web server
SIP/PSTN Gateway
vxml
Web based
configuration
SIP
VXML
H.323
siph323:
SIP-H.323
translator
NetMeeting

30. CINEMA My contribution in design and implementation
CINEMA Applications
RTSP media
server
SIP/VoiceXML
browser
SIP/H.323
gateway
SIP/RTP
conferencing
SIP/RTSP
unified messaging
SIP proxy
server
rtspd
sipvxml
sip323
sipconf
sipum
sipd
Flite
Xerces-C
Xerces-C
OpenH323
CINEMA Libraries
libsip
Basic SIP library
rtplib++
RTP library
libcine
Utilities parsing
IPv6
librtsp
RTSP
client
libsipapi
SIP UA library
libconf
RTP audio mixer
libmedia
Recording, files
libNT
Win32 stub
libdict
Hash table
libdb++
mySQL interface
libsnmp
SIP MIB
libcanon
canonicalize
MySQL
PWLib
Resparse
… and web-based GUI
C/C++: 58K out of 187 KLOC
Tcl: 30 KLOC

31. MobileNAT Architecture
Two IP addresses
Virtual IP (fixed host-id)
Actual IP (routable; changes)
DHCP, NAT, mobility manager CN
Application
Socket
TCP/UDP IP
Addr “A”
Shim Layer
Addr “V”
Net IF V=
Anchor node (AN)
moves MN MN A=
Actual IP
Virtual IP

32. MobileNAT Comparison with other work
MIP
CIP
Hawaii
HMIP (RR)
IDMP TeleMIP
MIP LR
MIP RO
SIP
IPv6
Mobile NAT
Virtual NAT
MIP messaging Y N -
Inter-tunnel O
Intra-tunnel
Paging UD
Host ID HA
CoA
LCoA
virtual
signaling
Data
DHCP/MM
CN modify?
MN modify?
Router modify? FA
NAT support Y1 IN
Non-mobile IP nodes
Triangular route
N/Y
Y: yes N: no :N/A O: optional IN:independent UD: Under Development
1: We assume Mobile IP with UDP tunneling for NAT

33. Interoperability with Nortel MCS
We have MCS 5100 (and phones)
It uses proprietary protocol and SIP
CINEMA+Nortel: two models
Use both at the same time (reliable)
Split user base between the two
User registration, call setup and conferencing
Security and trust: out of scope

34. Related work IP telephony and multimedia communication
Unlike low cost VoIP: Vonage, AT&T
We provide enterprise infrastructure
There are enterprise IPtel: Cisco, Nortel
But redundancy architecture, interoperability, distributed components model differ
Collaboration: CSCW, SIGGROUP
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
Distributed software development – CHIME (kaiser)

35. Related work Comprehensive multi-platform collaboration
Goal: Alternate between synchronous and asynchronous communication, and access from different devices and clients.
Synchronous (tightly coupled)
Video conference, IM, screen sharing, floor control, …
Asynchronous (loosely coupled)
File sharing, message board, …
Messaging and notifications
Personalized view
Per-user calendar, access control, address book
We try to incorporate…
Long lived groups
Design teams, committees, college classes
Asymmetric events
Lecture and lecture series
Short-lived spontaneous interaction
Current practice
, teleconference
Vendor specific tools, platform dependence
Application specific
E.g., collaborative software development

36. Multi-party collaboration What is done, and what is left.
Sipconf: conference server
Audio, video, IM, screen, shared browsing, floor control
No XCON yet: use web interface
Small to medium size conferences
Cascaded conference mixer
#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 (
Availability in the face of (DoS) attacks
Standby – hot (same data on both), cold (bring only when primary fails), warm (periodically send data to secondary; both running)
Scalability of web servers:
Same IP (L4/2 cluster): Bell labs ONE-IP, IBM eNetwork Dispatcher (2000/s), Alteon ACEdirectory (in switch, 25000/s)
NAT (L4/3 cluster): server IP is that of NAT. Cisco localdirector (25Mb/s with 8000 cluster nodes), LSNAT (30Mb/s)
L7: Locality aware request distributor (Rice Univ; uses connection migration – non-commodity OS,Content based – less cache.) (2000/s, 280Mb/s)
IBM web accelerator - cache in dispatcher (but low performance for bigger response). Arrowpoint (hardware; cache; sticky; 20000/s,20Gb/s)
Client based – DNS server rotates list of IP addresses returned.
Redirecting to less loaded server (SWED from UCSB) – application layer. Proxy becomes the bottleneck.
Remapping in the network: scheduler (L3) or link (L2)

38. Related work Scalability for (web) servers
Existing work
Connection dispatcher
Content/session-based redirection
DNS-based load sharing
HTTP vs SIP
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
Multi-homing.
Geographic load balancing.
Round-robin DNS – no account of server load, and server failure.
Load balancer – can use server response time, with damping. Or load information is pushed.
Active content verification by load balancer
Session and context – use external DB or sticky session in load balancer

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?
User population: BHCA=f(#users,%active,call interval); f(20000,1/4,3min)=100,000/hr=28c/s
Request modeling: poison arrival, INVITE transaction duration (20s=.7x8.5s+.3x38s), UAS latency<100ms
Transaction response time<200ms for register and <100ms for 1xx, <2s for 2xx of INVITE,
At 100c/s with 1500 bytes each, signaling requires 1.2Mb/s
E721 says at most 6s, 8s, 11s respectively for local,toll,international call setup delay.

40. Related work 3GPP (release 5)’s IP Multimedia core network Subsystem uses SIP
Proxy-CSCF (call session control function)
First contact in visited network. 911 lookup. Dialplan.
Interrogating-CSCF
First contact in operator’s network.
Locate S-CSCF for register
Serving-CSCF
User policy and privileges, session control service
Registrar
Connection to PSTN
MGCF and MGW

41. Related work: Skype From the KaZaA community
Host cache of some super nodes
Bootstrap IP addresses
Auto-detect NAT/firewall settings
Similar to STUN and TURN
Protocol among super nodes – ??
Allows searching a user (e.g., kun*)
History of known buddies
All communication is encrypted
Promote to super node
Based on availability, capacity
Conferencing
Problems:
Proprietary, single service, centralized login P
Super-nodes Election: capacity (bandwidth, storage, CPU) and availability (connection time,public address)
Read on STUN and TURN – what kind of NAT they support etc.
Symmetric NAT (different outbound connection from internal IP:port to different destination use different external address)
Full cone, restricted and port restricted cone: same internal IP:port has same external address for any destination, same destination IP, same destination IP:port
TURN: acts as a relay for UDP or TCP
ICE: caller collects all external address, sends to callee, callee tries STUN to all, sends packets to whichever works, callee also collects all external address, sends to caller, caller reuses callees address or tries STUN. Periodically keep trying STUN.

42. Related work P2P P2P networks Skype and related systems
Unstructured (Kazaa, Gnutella,…)
Structured (DHT: Chord, CAN,…)
Skype and related systems
Flooding based chat, groove, Magi
P2P-SIP telephony
Proprietary: NimX, Peerio,
File sharing: SIPShare
Mercora – legal music sharing
S2S – science to science is a p2p search engine built using JXTA
SOS – source->access point->beacon->secret servlet->filter/firewall->target. Target picks secret servlets. Beacon know abt secret servlets.

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
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)
JXTA: peer discovery, resolver, information, rendezvous, pipe binding, endpoint routing protocols.
Peers, groups, messages, pipes, advertisement,

45. P2P-SIP Node Startup SIP DHT Dialing out REGISTER with SIP registrar
columbia.edu DB
sipd
SIP
REGISTER with SIP registrar
DHT
Discover peers: multicast REGISTER
Join DHT using node-key=Hash(ip)
REGISTER with DHT using
Dialing out
Call, instant message, etc.
INVITE
MESSAGE
Last seen, SIP NAPTR/SRV, DHT
REGISTER
Detect peers
REGISTER alice=42 42 58 12 14
REGISTER bob=12 32

46. P2P-SIP Node Leaves Graceful leave Failure Un-REGISTER
Transfer registrations
Failure
Attached nodes detect and re-REGISTER
New REGISTER goes to new super-nodes
Super-nodes adjust DHT accordingly
REGISTER key=42
REGISTER
DHT
OPTIONS 42 42

47. P2P-SIP Advanced services
Offline messages
INVITE or MESSAGE fails => Responsible node stores voic , 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
Don’t forward all calls, log call history (spy),…
“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 (
works for server farm in DHT
Collusion
Hide security algorithm (e.g., yahoo, skype)
Chord
Recommendations, design principles, …
Design principles:
define verifiable system invariants and verify them
Allow querier to observe the lookup progress
Assign keys to nodes in a verifiable manner
Server selection in routing may be abused
Cross check routing tables using random queries
Avoid single point of responsibility
Pastry - exclude untrusted nodes with help of central certificate authority.
Incorrect data served: verify by self certifying path names

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
Fast start in v2 is optional
User registration
Both SIP and H.323 users should be reachable
Session description is more complex
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 voic with PBX or phone, or send voice attachments in
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
VoiceXML for touch tone-based service programming
Backend scripts (CGI) or servlets
Problem
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)
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
Similar API for H.323 defined using wrapper around openH323
Unlike JAIN-SIP or SIP servlet, libsip++ is more high level with facility to access low level features
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

55. My contribution in CINEMA GUI: web-based user interface
Configuration, user profile, etc., stored in SQL DB
Front end as web-based GUI
CGI scripts in Tcl
About 100 pages for various configuration
User friendly (beginner vs advanced, context help)
Asynchronous collaboration
Voic , file sharing, IM archive, groups, address book, calendar
Undergone three iterations
See current version at