| Date post: | 26-Dec-2015 |
| Category: |
Documents |
| Upload: | janice-franklin |
| View: | 217 times |
| Download: | 3 times |
Reliable, Scalable and Reliable, Scalable and Interoperable Internet TelephonyInteroperable Internet Telephony
PhD thesis presentation
by Kundan SinghAdvisor: Henning Schulzrinne
Computer Science Department, Columbia University, New York
June 21, 2006
2
My research My research background/timelinebackground/timeline
1997 1999 2000 2001 2002 2003 2004 2005 2006Undergrad
@India
Work@
Motorola
H.3
23 clien
t
gatew
ay
SIP-H
.323 tran
slatorSIP-R
TSP voice m
ailSIP con
ferencin
g
Libsip
++
(SIP lib
rary)
P2P V
oIP usin
g S
IP
SIP Failover/load
sharin
g
Enterp
rise VoIP in
frastructu
re
Interactive voice resp
onse
CIN
EM
A u
ser interface
Multim
edia collab
oration
Mob
ile NA
T
Reliability &
scalability
VoIP infrastructure
Con
ference evalu
ation
3
Outline of the presentationOutline of the presentation Introduction
What is the problem? Why important? My contributions
Server redundancy Load sharing and failover in SIP telephony Comparison of thread models for SIP server
Peer-to-peer (P2P) SIP servers using external P2P network Additionally, P2P maintenance using SIP
Enterprise IP telephony Multi-platform collaboration using SIP Scalable centralized conferencing architecture Interworking between SIP/SDP and H.323
Conclusion
36 slides
4
Telephone reliability & Telephone reliability & scalability scalability (PSTN: Public Switched Telephone Network)(PSTN: Public Switched Telephone Network)
“bearer” network telephone switch(SSP)
database (SCP)for freephone, calling card, …
signaling network(SS7)
signaling router(STP)
local telephone switch(class 5 switch)10,000 customers20,000 calls/hour
database (SCP)10 million customers2 million lookups/hour
signaling router (STP)1 million customers1.5 million calls/hour
regional telephone switch(class 4 switch)100,000 customers150,000 calls/hour
Switches strive for 99.999% availability.Lucent’s 5E-XC supports 4 million BHCA.
5
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
Can SIP server provide carrier grade reliability and scalability using commodity hardware
6
What are the problems?What are the problems? Can SIP server provide carrier-grade
reliability and scalability using commodity hardware? What affects the server performance?
How can we build a server-less self-organizing peer-to-peer VoIP network? Can this be done in standards compliant
way? Can communication be extended to
multi-platform collaboration using existing protocols? How well multi-party conferencing scales? How to interoperate between SIP and H.323?
7
My contributionsMy contributions Server redundancy
Implemented failover using database replication
Two-stage architecture for SIP load sharing Comparison of thread models for SIP server
Peer-to-peer (P2P) SIP servers using external P2P network Additionally, P2P maintenance using SIP
Enterprise IP telephony Multi-platform collaboration using SIP Scalable centralized conferencing
architecture Interworking between SIP/SDP and H.323
New architecture, New algorithm or approach, Implementation, Evaluation
8
Outline of the presentationOutline of the presentation Introduction
What is the problem? Why important? My contributions
Server redundancy Load sharing and failover in SIP telephony Comparison of thread models for SIP server
Peer-to-peer (P2P) SIP servers using external P2P network Additionally, P2P maintenance using SIP
Enterprise IP telephony Multi-platform collaboration using SIP Scalable centralized conferencing architecture Interworking between SIP/SDP and H.323
Conclusion
9
Server redundancyServer redundancyThe problem: failure or overloadThe problem: failure or overload
REGISTERINVITE
10
High availabilityHigh availabilityImplementation and analysisImplementation and analysis
ImplementationUsing MySQL replication
System reliabilityindividual component
reliability Call setup latency
DNS TTL, time-to-repair, retry timeout
User unavailabilityMost registers are
refreshesRetry timeout, replication
interval, register refresh interval
Slave/master
Master/slave
P1 P2
DNS
Caller
D1 D2
TR
D2Callee
Tr
TR
Tc
Tc
Td
A
ATc
P1 P2D1
11
ScalabilityScalabilityLoad sharing: redundant proxies and databasesLoad sharing: redundant proxies and databases
REGISTER Write to D1 & D2
INVITE Read from D1 or
D2 Database write/
synchronization traffic becomes bottleneck
D1
D2
P1
P2
P3
REGISTER
INVITE
12
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
D1
D2
P1
P2
P3
D3
a-h
i-q
r-z
13
ScalabilityScalabilityComparison of the two designsComparison of the two designs
D1
D2
P1
P2
P3
D1
D2
P1
P2
P3
D2
a-h
i-q
r-z
High Scalability
Low Reliability
Low Scalability
High Reliability
14
Scalability (and reliability)Scalability (and reliability)Two stage architectureTwo stage architecture
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
Capacity = f(#stateless, #groups)
ex
I stage II stage
15
Load SharingLoad SharingPerformance result: calls/secondPerformance result: calls/second
Using 3+3 servers gives carrier-grade performance (10 million busy hour call attempts)
Registration test: supports 10 million subscribers
On commodity hardware: 3 GHz, Pentium 4, 1 GB memory
Test with UDP, stateless, no DNS and no mempool
9001050
18002100
2800
0
500
1000
1500
2000
2500
3000
calls/ sec
16
Server performanceServer performanceWhat happens inside a server? What thread/event models What happens inside a server? What thread/event models possible?possible?
recvfrom
Match transaction
Modifyresponse
Match transaction
Update DB
Lookup DBBuildresponse
Modify Request
DNS
sendtoparse
Request
Response
Stateless proxy
Found
Stateless proxy
stateful
REGISTER
other
Redirect/reject
Proxy
(Blocking) I/OCritical section (lock)
Critical section (r/w lock)
1. Pure event-based (one thread)2. Thread-per-msg or transaction3. Pool-thread per msg (sipd)4. Two stage thread pool
accept recv File read send
Web server
SIP server
17
Server performanceServer performanceResults of my measurementResults of my measurement
Event-based performs 30% better than existing thread-pool architecture on single-CPU
Two stage thread-pool architecture gives better performance on multi-CPU 60% more on 4xPentium
Both Pentium and Sparc took 2 MHz of CPU cycles per call/s on single-CPU
18
Problem with serversProblem with servers
Server-based Cost: maintenance, configuration Central points of failures,
catastrophic failures Controlled infrastructure (e.g., DNS)
Peer-to-peer Robust: no central dependency Self organizing, no configuration Inherent scalability
C
C
C
C
C
S
P
P
P
P
P
19
We built: P2P-SIPWe built: P2P-SIP Unlike proprietary Skype architecture
Robust and efficient lookup using DHT Interoperability
DHT algorithm uses SIP communication Hybrid architecture
Lookup in SIP+P2P Inter-domain P2P-SIP
Unlike file-sharing applications Data storage, caching, delay, reliability Data model and service model
Disadvantages Lookup delay and security
20
How to combine SIP + P2P?How to combine SIP + P2P? SIP-using-P2P
Replace SIP location service by a P2P protocol
P2P-over-SIP Additionally,
implement P2P using SIP messaging
P2P network
Alice128.59.19.194
INSERT
INVITE sip:[email protected]
P2P-SIPoverlay Alice
128.59.19.194
REGISTERINVITE aliceFIND
SIP-using-P2P P2P SIP proxies
P2P-over-SIP
Maintenance P2P P2P SIP
Lookup P2P SIP SIP
21
SIP-using-P2PSIP-using-P2PLogical OperationsLogical Operations
Contact management put (user id, signed contact)
Key storage User certificates and private configurations
Presence put (subscribee id, signed encrypted subscriber id) Composition needs service model
Offline message put (recipient, signed encrypted message)
NAT and firewall traversal STUN and TURN server discovery needs service
model
XML-based data format
22
SIP-using-P2PSIP-using-P2PImplementation in SIPc with the help of Xiaotao WuImplementation in SIPc with the help of Xiaotao Wu
OpenDHT Using Data
model Identity
protection Certificate-
based SIP id == email
P2P forCalls, IM, presence, offline message and name lookup
23
P2P-over-SIPP2P-over-SIPArchitecture and implementationArchitecture and implementation
DHT (Chord) algorithm using SIP messages with query and update semantics of REGISTER
Has SIP registrar, proxy, user agent Other: discovery, NAT traversal, failover Adaptor: allows existing SIP devices to
become P2P
24
P2P-over-SIPP2P-over-SIPAnalysis: scalabilityAnalysis: scalability
Computed message load as function of Refresh rate (keep-alive, finger table, user
registration), call arrival rate, churn (join, leave, failure), scale (number of peer nodes and users)
Number of nodes = f(individual node capacity) Measured performance: 800 register/s. Assuming a conservative 10 reqister/s
capacity, and aggressive refresh and call rate of 1/min, it gives more than 16 million peers (super nodes) in the network.
25
P2P-over-SIPP2P-over-SIPAnalysis: availability and call setup latencyAnalysis: availability and call setup latency
To increase user availability: Fast failure detection: increase keep-alive
rate Reduce unavailability: frequent registration
refresh Replicate: user and node registrations
Call setup latency: Same as DHT lookup latency: O(log(N))
Calls to known locations (“buddies”) is direct Chord: 10000 nodes => 6 hops
At most a few seconds User availability and retransmission timers
26
SIP-using-P2PSIP-using-P2P vs vs P2P-over-SIPP2P-over-SIP Not SIP-specific, hence
no implementation overhead for non-VoIP but P2P applications
Low transport and transaction overhead
No P2P security burden on SIP
No dependency on single DHT implementation
Reuse SIP naming, routing, security, NAT/firewall traversal
Easily reuse existing SIP components without change
voicemail, conference Single DHT
implementation Readily supports
service model
27
Server-based vs peer-to-Server-based vs peer-to-peerpeer
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
28
Outline of the presentationOutline of the presentation Introduction
What is the problem? Why important? My contributions
Server redundancy Load sharing and failover in SIP telephony Comparison of thread models for SIP server
Peer-to-peer (P2P) SIP servers using external P2P network Additionally, P2P maintenance using SIP
Enterprise IP telephony Multi-platform collaboration using SIP Scalable centralized conferencing architecture Interworking between SIP/SDP and H.323
Conclusion
29
InternalTelephoneExtn: 7040
SIP/PSTN Gateway
Department PBX
Web based configuration
Web server
Telephoneswitch
SQLdatabase
sipd:Proxy, redirect, Registrar server
NetMeeting
H.323
rtspd: media server
sipum: Unified messaging
Quicktime
RTSP clients
RTSP
713x
CINEMA servers
sipconf: Conference server
siph323: SIP-H.323 translator
Local/long distance1-212-5551212
PSTN
Internet telephony Internet telephony infrastructureinfrastructureCINEMA: Columbia InterNet Extensible Multimedia CINEMA: Columbia InterNet Extensible Multimedia ArchitectureArchitecture
SIP
VXML
vxml
cgi
My work
Built many components in a complete system for enterprise IP telephony and multimedia collaboration
30
My other workMy other work Communication to collaboration
Comprehensive, multi-platform collaboration using SIP Unified messaging: The gaps among different media
(audio, video, text), devices (PC, phone) and means of communications (Email, SIP, IM) disappear for messaging
Novel SIP/RTSP based voicemail and answering machine SIP interface to VoiceXML browser
Centralized conferencing Audio mixing, video forwarding, IM, shared web browsing,
screen sharing, web-based configuration and control, floor control
Performance evaluation; cascaded server architecture SIP-H.323 translation
31
Conference serverConference serverPerformance evaluation of audio mixerPerformance evaluation of audio mixer
On commodity PC About 480 participants in a single
conference with one active speaker About 80 four-party conferences, with
one speaker each Both Pentium and Sparc took 6
MHz per participant
32
Conference serverConference serverCascaded architectureCascaded architecture
N.(N-1) participants
Higher delay
N2/4 participants Lower delay
I measured the CPU usage for two cascaded servers: supports about 1000 participants
SIP REFER message is used to create cascading
33
Outline of the presentationOutline of the presentation Introduction
What is the problem? Why important? My contributions
Server redundancy Load sharing and failover in SIP telephony Comparison of thread models for SIP server
Peer-to-peer (P2P) SIP servers using external P2P network Additionally, P2P maintenance using SIP
Enterprise IP telephony Multi-platform collaboration using SIP Scalable centralized conferencing architecture Interworking between SIP/SDP and H.323
Conclusion
34
Revisiting the problemsRevisiting the problems Can SIP server provide carrier-grade
reliability and scalability using commodity hardware? What affects the server performance?
How can we build a server-less self-organizing peer-to-peer VoIP network? Can this be done in standards compliant
way? Can communication be extended to
multi-platform collaboration using existing protocols? How well multi-party conferencing scales? How to interoperate between SIP and H.323?
Developed a two stage scalable and reliable SIP server architecture: linear scaling. Use event-based.
Developed P2P-SIP architecture: SIP-using-P2P and P2P-over-SIP
Multi-platform collaboration using existing protocols and tools, unified messaging, centralized conferencing (cascaded), SIP-H.323 interworking.
35
ConclusionsConclusions Impact:
Commercialized by SIPquest (now FirstHand) and sold to many customers.
CINEMA was deployed in our department for a brief period of time. Used in various other projects at IRT: NG911, firewall controller,
presence scalability, TCP/TLS measurements,… P2P-SIP is a “hot” topic in industry and IETF now – client desktop,
hardware phone as well as server vendors are pursuing this. SIP-H.323 requirements eventually became an RFC Plan to open source SIPc for large scale deployment experience of
P2P-SIP Started working on a P2P-based self organizing servers for 3GPP at
Bell Labs “So what” (Implications):
Replacing PSTN – better features, quality and performance at lower cost and maintenance; zero cost VoIP using P2P-SIP
Distributed, multi-provider, component architecture for telephony and collaboration
36
My publicationsMy publicationsConferenceConference, , workshopworkshop, , technical reporttechnical report, , magazine/journalmagazine/journal
1. K. Singh and H. Schulzrinne, “Using an external DHT as a SIP location service", Columbia University Technical Report CUCS-007-06, NY, Feb’06.
2. K. Singh and H. Schulzrinne, “Peer-to-peer Internet telephony using SIP", NOSSDAV, Skamania, Washington, Jun 2005.. 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. K. Singh and H. Schulzrinne, “Failover, load sharing and server architecture in SIP telephony”, Elsevier Computer Communication Journal. To appear. Aug 2006.
“K. Singh and H. Schulzrinne, “Failover and load sharing in SIP telephony", SPECTS (Symposium on performance evaluation of computer and telecommunication systems). Philadelphia, PA, Jul 2005.
K. Singh and H. Schulzrinne, "Failover and Load Sharing in SIP Telephony", Columbia University Technical Report CUCS-011-04, NY, May 2004. 4. H. Schulzrinne, K. Singh and X. Wu, "Programmable Conference Server", Columbia University Technical Report CUCS-040-04, NY, Oct 2004. 5. 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. 6. M. Buddhikot, A. Hari, K. Singh and S. Miller, "MobileNAT: A new Technique for Mobility across Heterogeneous Address Spaces", ACM
MONET journal, March 2005. 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. 7. 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. 8. 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). 9. K. Singh, Gautam Nair and H. Schulzrinne, "Centralized Conferencing using SIP", 2nd IP-Telephony Workshop (IPTel'2001), April 2001. 10. 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. 11. 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.
Backup slidesBackup slides
38
Potential questionsPotential questionsServer redundancyServer redundancy
How much is the database traffic for replication? Does replication work for other databases?
39
Potential questionsPotential questionsEvent and thread modelEvent and thread model
Why is process pool better than others? Why did Pentium and Sparc give same performance? Why not
for multi-processor? Why is multi-CPU not Nx of single CPU performance? What are
concurrency issues? (memory bandwidth?) Not clear what is the contribution here?
Application of two-stage load sharing architecture
40
Potential questionsPotential questionspeer-to-peer Internet telephonypeer-to-peer Internet telephony
Any related work and your contribution in IETF? Why use SIP? Who will pay since it threatens the provider model?
May evolve similar to Internet – web/email – fixed cost. How does difference between SIP and file sharing affect the
architecture? Needs low guaranteed delay – no blind search; data may change
frequently – affects replication Performance of combination of P2P and server – p2p falls back
to server? How does OpenDHT give fairness? How can you interoperate with PSTN? Can you use unstructured P2P network? (yes, with fallback to
central) What is your scientific contribution?
Showing that it can work in a open standard compliant way.
41
Potential questionsPotential questionsEnterprise IP telephonyEnterprise IP telephony
Any related work and your contribution? Demonstrating and pushing the standard based collaboration
during the initial stages of SIP Who uses H.323? Why care about SIP-H.323 systems? Why did you use ‘Interoperability’ in the thesis title?
To differentiate between my work and others: Skype, Cisco Skinny/call manager, Nortel’s original server, etc., and interoperation between different protocols SIP and H.323
Server redundancyServer redundancy
43
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
A mobile service provider in 3GPP with millions of subscribers
44
Reliability of DNS, network, Reliability of DNS, network, webweb [Wenyu’03]: VoIP network 98% (.5+1.5) [Pang’04]: local DNS:98%;auth DNS:99%
Minor correlation to load MTBF: order of days, weeks or longer (1%:
10days) MTTR: order of hours (60%:5hr; 90%:15)
[Sohar’00]: overall 99.57% availability Main: 99.6%, Backbone: 99.8%, Cisco switches:
99.98%, PC server: 99.7%, DB server: 99.96%, Solaris OS: 99.99%
Hosted web portals: Usually give 99.5% in SLA; but achieve 99.9%
except for scheduled downtime
45
Availability and “nines”Availability and “nines”Availabilit
yDowntime
Per month
Per year
98% 14 hrs 7.3 days
99% 7hr 3days, 15hrs
99.5% 3.5hr 1day, 19hr
99.9% 44m 8h, 46min
99.95% 22m 4h, 23min
99.99% 4.4m 52m, 36s
99.999% 26s 5m, 15s
99.9999%
2.7s 32s
PC, VoIP callsIP-PBX software (guess)
PSTN, network
US Power, Solaris OS
Switches
46
Related work: web server Related work: web server reliabilityreliability Dispatcher or stateful NAT
Not data dominated so becomes bottleneck IP address takeover (linux-ha) or MAC takeover
Requires servers on same subnet; reachability Can’t use for scalability for stateful proxy
IP anycast Probably closer/faster server
Client-based Cisco phones: primary and backup proxy; implementation
dependent; what is servers IP change. DNS
Dynamic: load; caching problem; not every impl respects TTL NAPTR, SRV
Rserpool: to maintain server pool and name server pool Requires new protocol support; local network;
Database redundancy TCP connection migration/process migration
47
Related work: SIP server Related work: SIP server reliabilityreliability
Cisco: proprietary protocol; same subnet Dynamicsoft (bought by cisco): backend
database replication Ubiquity: load balancer Vovida: some kind of SIP replication;
sync problem after recovery Iptel: IP anycast with state replication
Requires transaction state sharing among servers because replication is not visible to the client
48
High availabilityHigh availabilityFailover implementation in our test-bed - CINEMAFailover implementation 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
MySQL: No locking protocol between master and slave. Race if insert into D1 and remove from D2
INVITE to P2 either onICMP error or after 10
s
sipd has in-memory cache: REGISTER refresh much before expiry; web gets delayed data; not an issue for cisco phones
49
High availabilityHigh availabilityAnalysisAnalysis
System reliability(1-(1-R)2)
Call setup latencyTR (1-R) P[tM<TD]
where TD is DNS TTL,
tM is time-to-repair, and
P[tM<TD] = 1 – e-TD/TM
User unavailabilityNone (refresh; double register)For first time registration,
probability that the server goes down before replication is:
1 – e-(Td/+Tc)/TF
where TF is mean-time-to-failure
Redundant serversTradeoff: reliability vs capacity
Slave/master
Master/slave
DNS
P1 P2Caller
Callee
D1 D2
TR
Tr
TR
Tc
Tc
Td
A
ATc
P1 P2D1 D2
50
Bulk arrivalBulk arrival
What if all servers come up immediately after power recovery? Carrier (gradually) vs enterprise (all at once) Wait timer in SIP configuration based server
capacity Don’t query the server for config on reboot
Not a problem if server gracefully drops requests without degrading the performance
Clients retry – and succeed over an hour
51
What does scalability depend What does scalability depend on?on?Depends on traffic typeDepends on traffic type
Registration (uniform) Authentication, mobile users
Call routing (Poisson) stateful vs stateless proxy, redirect, programmable
scripts Beyond telephony (Don’t know)
Instant message, presence (including sensors), device control
Stateful calls (Poisson arrival, exponential call duration)
Firewall, conference, voicemail Transport type
UDP/TCP/TLS (cost of security)
52
Related work: web server Related work: web server scalabilityscalability Existing work
Connection dispatcher (NAT) Same IP address 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, real-time media data, gateway 302 redirect to less loaded server, REFER session
to another location, signal upstream to reduce
53
SIP vs HTTP serverSIP vs HTTP server Signaling (vs data) bound
No File I/O (exception: scripts, logging) No caching; DB read and write frequency are
comparable Transactions
Stateful wait for response Depends on external entities
DNS, SQL database Transport
UDP in addition to TCP/TLS; may not need TCP state Goals
Carrier class scaling using commodity hardware Try not to customize/recompile OS or implement (parts
of) server in kernel (khttpd, AFPA)
54
What is SIPstone?What is SIPstone?SIP server performance metricsSIP server performance metrics
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,
RPS (registers/s), CPS (calls/s), transaction failure probability<5%,
Delay budget: R1 < 500 ms, R2 < 2000 ms Shortcomings:
does not consider forking, scripting, Via header, packet size, different call rates, SSL. Is there linear combination of results?
Whitebox measurements: turnaround time Extend to SIMPLEstone
Loader Handler
REGISTER
Server
INVITE
INVITE
180 Ringing180 Ringing
100 Trying
200 OK
200 OK200 OK
200 OK 200 OK
ACKACK
BYE BYE
SQLdatabase
R2
R1
55
Comparison of two designsComparison of 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 latencyP = number of proxy serversRp = reliability of the proxy serverRd = reliability of the database server
=(1-(1-Rp)P).(1-(1-Rd)D) =R0.(RP)D.(Rd)DSystem reliability
High Scalability
Low Reliability
Low Scalability
High Reliability
56
Two stage architectureTwo stage architecture
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
57
Performance evaluationPerformance evaluationScalability result (UDP, stateless, no DNS, no mempool)Scalability result (UDP, stateless, no DNS, no mempool)
I(s) II(p) calls/s
3 3 2800
2 3 2100
2 2 1800
1 2 1050
0 1 900
On commodity hardware:3 GHz, Pentium 4, 1 GB memory
Stateful proxy gave similar graphs with 650 CPS for single server.
Line segments due to non-uniform distribution in II stage; I have verified uniform distribution also.
Regitration test also gave similar graphs with about 2400 RPS (no auth). This means 10 million subscribers using S3P3.
This means 10 million BHCA (busy hour call attempts) using S3P3.
58
User diversity on incoming User diversity on incoming callscallsIs uniform hashing an issue?Is uniform hashing an issue?
Didn’t find any existing evaluation Adaptive load balancing for identifier-based
distribution. issue – transfer registrations to new DB
Related results: File popularity is Zipf; user is more uniform (poisson) Dynamic load balancing in web is useful if service
time range is more than two orders. (but all servers have same pages)
Intuitive: With 100,000 subscribers per server, you need to be
very unlucky that one of those is equivalent to thousands of subscribers
59
User diversity on incoming User diversity on incoming callscallsIs uniform hashing an issue?Is uniform hashing an issue?
My argument (not sure): Assume user popularity for calls is Poisson with mean L.
(independent calls for users) X is a random variable indicating number of calls a user receives
If there are two servers, and assuming the user population gets uniformly distributed, each server gets roughly half the user population for each call rank. So user popularity again is Poisson with mean L.
Thus mean (and variance) remains the same However if user popularity is Zipf, then it is different;
variance can be high Alternative:
If you plot number of calls vs users in decreasing order. Assume this is exponential. (analogy: calls/time to calls/users)
Having two servers basically shrinks the x-axis to half. So each server has exponential graph with mean L/2
60
Reliability of two-stageReliability of two-stage
If S=P=B=3, each server is 99% available
Total: (1-(1-R)S).(1-(1-R)B)P = 99.9996%
P doesn’t have to be 1+1 for each group, but can be N+1 for N groups.
One backup keeps all records in memory, but gets only updates in contact rather than each refresh. Doesn’t have to survive reboots. Clones itself to another DB when failure occurs.
61
What is the best What is the best architecture?architecture?
Event-based Reactive system
Process pool Each pool process
receives and processes to the end (SER)
Thread pool1. Receive and hand-over to pool
thread (sipd)2. Each pool thread receives and
processes to the end3. Staged event-driven: each stage
has a thread pool
recvfrom oraccept/recv
Match transaction
Modifyresponse
Match transaction
Update DB
Lookup DBBuildresponse
Modify Request
DNS
sendto,send orsendmsg
parse
Request
Response
Stateless proxy
Found
Stateless proxy
stateful
REGISTER
other
Redirect/reject
Proxy
62
Stateless proxyStateless proxyUDP, no DNS, six messages per callUDP, no DNS, six messages per call
recvfrom oraccept/recv
Match transaction
Modifyresponse
Match transaction
Update DB
Lookup DBBuildresponse
Modify Request
DNS
sendto,send orsendmsg
parse
Request
Response
Stateless proxy
Found
Stateless proxy
stateful
REGISTER
other
Redirect/reject
Proxy
63
Stateful proxyStateful proxyUDP, no DNS, eight messages per callUDP, no DNS, eight messages per call
Event-based single thread: socket listener + scheduler/timer
Thread-per-message pool_schedule => pthread_create
Thread-pool1 (sipd) Thread-pool2
N event-based threads Each handles specific subset of requests (hash(call-id))
Receive & hand over to the correct thread poll in multiple threads => bad on multi-CPU
Process pool Not finished yet
64
Server performanceServer performanceResults of my measurements; effect of multi-processorResults of my measurements; effect of multi-processor
Calls/s for stateless proxy, UDP, no DNS, 6 msg/callArchitecture/Hardware
1 PentiumIV 3GHz, 1GB, Linux2.4.20(1xP)
4 pentium, 450MHz, 512 MB, Linux2.4.20(4xP)
1 ultraSparc-IIi, 300 MHz, 64MB, Solaris(1xS)
2 ultraSparc-II, 300 MHz, 256MB, Solaris(2xS)
Event-based 1550 400 150 600
Thread per msg 1300 500 100 500
Pool-thread per msg
1400 850 110 600
Thread-pool 1500 1300 152 750
Process-pool 1600 1350 160 1000Calls/s for stateful proxy, UDP, no DNS, 8 msg/call
Architecture/Hardware
1 PentiumIV 3GHz, 1GB, Linux2.4.20(1xP)
4 pentium, 450MHz, 512 MB, Linux2.4.20(4xP)
1 ultraSparc-IIi, 360MHz, 256 MB, Solaris5.9 (1xS)
2 ultraSparc-II, 300 MHz, 256 MB, Solaris5.8 (2xS)
Event-based 1150 300 160 400
Thread per msg 600 175 90 300
Thread-pool 850 340 120 300
2 stage thread-pool
1100 550 155 500
Better performance as this includes mempool changes Software architecture
further improves performance: S3P3 can support 16 million BHCA
Both Pentium and Sparc took approx 2 MHz CPU cycles per call/s on single-processor
65
(a) Stateless proxy
0
1
2
3
4
1xP/Linux 4xP/Linux 1xS/Solaris 2xS/Solaris
event basedthread per msgpool-thread per msgthread poolprocess pool
(b) Stateful proxy
0
1
2
3
4
1xP/Linux 4xP/Linux 1xS/Solaris 2xS/Solaris
event based
thread per msg
thread pool (sipd)
(2 stage) thread pool
Not much concurrency in stateful mode: needs more investigation
66
What is the best What is the best architecture?architecture? Stateless
CPU is bottleneck Memory is constant Process pool is the
best Event-based not
good for multi-CPU Thread/msg and
thread-pool similar Thread-pool2 close
to process-poll
Stateful Memory can
become bottle-neck
Thread-pool2 is good
But not N x CPU Not good if P
CPU Process pool may
be better (?)
67
In memory database in sipdIn memory database in sipd Call routing
involves ( 1) contact lookups
10 ms per query (approx)
Cache (FastSQL) Loading entire
database is easy Periodic refresh
Potentially useful for DNS lookups
SQLdatabase
Cache
PeriodicRefresh
< 1 ms
[2002:Narayanan] Single CPU Sun Ultra10 Turnaround time vs RPS
Web config
68
Thread-per request doesn’t Thread-per request doesn’t scalescale
One thread per message Doesn’t scale
Too many threads over a short timescale
Stateless: 2-4 threads per transaction
Stateful: 30s holding time
Thread pool + queue Thread overhead less; more useful processing Pre-fork processes for SIP-CGI
Overload management Graceful failure, drop requests over responses
Not enough if holding time is high Each request holds (blocks) a thread
R1R2
R3
R4
IncomingRequestsR1-4
Load
Thro
ugh
put
IncomingRequestsR1-4
Fixed number of threads
Thread pool with overload control
Thread per request
69
Avoid blocking calls in sipdAvoid blocking calls in sipd DNS
10-25 ms (29 queries) Cache
110 to 900 CPS Internal vs external
non-blocking Logger
Lazy logger as a separate thread Date formatter
Strftime() 10% REG processing Update date variable every second
random32() Cache gethostid()- 37s
Logger:while (1) { lock; writeall; unlock; sleep;}
70
Resource management in Resource management in sipdsipd Socket management
Problems: OS limit (1024), “liveness” detection, retransmission One socket per transaction does not scale
Global socket if downstream server is alive, soft state – works for UDP
Hard for TCP/TLS – apply connection reuse Socket buffer size
64KB to 128KB; Tradeoff: memory per socket vs number of sockets Memory management
Problems: too many malloc/free, leaks Memory pool
Transaction specific memory, free once; also, less memcpy About 30% performance gain
Stateful: 650 to 800 CPS; Stateless: 900 to 1200 CPS
Stateless processing time (s)
INV 180 200 ACK BYE 200 REG 200
W/o mempool 155 67 67 95 139 62 237 70W/ mempool 111 49 48 64 106 41 202 48Improvement (%) 28 27 28 33 24 34 15 31
71
Optimized processing in SEROptimized processing in SER Reduce copying and string operations
Data lumps, counted strings (+5-10%) Reduce URI comparison to local
User part as a keyword, use r2 parameters Parser
Lazy parsing (2-6x), incremental parsing 32-bit header parser (2-3.5x)
Use padding to align Fast for general case (canonicalized)
Case compare Hash-table, sixth bit
Database Cache is divided into domains for locking
[2003:Jan Janak] SIP proxy server effectiveness, Master’s thesis, Czech Technical University
72
Bottlenecks and other Bottlenecks and other scalability concerns scalability concerns addressed in SERaddressed in SER Protocol bottlenecks
Parsing Order of headers Host names vs IP address Line folding Scattered headers (Via, Route)
Authentication Reuse credentials in subsequent requests
TCP Message length unknown until Content-Length
Other scalability concerns Configuration:
broken digest client, wrong password, wrong expires Overuse of features
Use stateless instead of stateful if possible Record route only when needed Avoid outbound proxy if possible
73
Comparison of sipd and SERComparison of sipd and SER
sipd Thread pool Events (reactive
system) Memory pool PentiumIV 3GHz,
1GB, 1200 CPS, 2400 RPS (no auth)
SER Process pool Custom memory
management PentiumIII 850
MHz, 512 MB => 2000 CPS, 1800 RPS
74
Results of our measurementResults of our measurement Stateless proxy
S=1050, P=900 CPS S3P3 => 10 million BHCA (busy hour call attempts)
Stateful proxy S=800, P=650 CPS
Registration (no auth) S=2500, P=2400 RPS S3P3 => 10 million subscribers (1 hour refresh)
Memory pool and thread-pool2/event-based further increase the capacity (approx 1.8x)
75
3GPP’s IMS3GPP’s IMS3GPP (release 5)’s IP Multimedia core network Subsystem 3GPP (release 5)’s IP Multimedia core network Subsystem uses SIPuses 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
Peer-to-peer Internet Peer-to-peer Internet telephonytelephony
77
Comparison:Comparison:Server-based, structured and unstructured P2PServer-based, structured and unstructured P2P
Architecture Server-based (two-stage)
Structure P2P (Chord/log(N))
Unstructured P2P(blind search)
Reliability (or user record availability)
(1-(1-R)P) Upper bound No guarantee
Performance (delay)
Low Log(N) No guarantee; Implementation dependent
Scalability (number of users)
Linear with number of servers
Exponential with per node capacity
If constant degree, then no limit
78
P2P vs server-basedP2P vs server-basedserver-based P2P
scaling server count scales with user count, but limited by supernode count
efficiency most efficient DHT maintenance = O((log N)2), lookup = O(logN)
security trust server provider; binary
trust most supernodes; probabilistic
reliability server redundancy; catastrophic failure possible
unreliable supernodes; catastrophic failure unlikely
79
Structured vs. unstructured Structured vs. unstructured P2P-SIPP2P-SIP Unstructured P2P alone is not good
No guarantee (upper bound) in lookup Fall back to server; has central dependency Caching is not much useful as contacts change
often; caching good for non-mutable data (e.g., certificates) because replication and caching of mutable data don’t go together well.
Skype works: Few super nodes are too burdened Node:supernode ~ 400:1 Probably some kind of structure (user name
prefix) among super nodes, and falls back to central server
80
NAT traversal and P2P-SIPNAT traversal and P2P-SIP
Joining a DHT from behind a NAT: open issue NATed nodes acts as users of DHT
Media traversal STUN (not symmetric: 18%?), TURN,
ICE Hole punching – works with 60%
symmetric
81
SecuritySecurityopen issues (threats, solutions, issues)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, …
82
SecuritySecurityRandom thoughtsRandom thoughts
Un-trusted peers: Misrouting: easy to detect No-routing: hard (redundancy, reputation,
“call itself”) Problems:
Malicious program, copyright violation, stolen identity, privacy, free riding, sybil, programmable scripts, aliases
Separate DHT from application Managed DHT: more trusted
83
Why P2P-SIP? What is our P2P-Why P2P-SIP? What is our P2P-SIP?SIP?
Server-based Maintenance and configuration cost: dedicated
administrator Central point of failures: catastrophic failures Depends on controlled infrastructure (e.g., DNS)
Peer-to-peer Self adjusting, robust against catastrophic failures, highly
scalable, and no configurations Call setup and user search latency is higher: O(log(N)) Security: how to handle malicious peers? Identity
protection? Our P2P-SIP
Hybrid architecture: works with both P2P and server-based Built-in P2P network: acts as a service node for proxy,
registrar, presence, offline storage, and media relay External P2P network: managed and trusted peer nodes Identity protection: Email identifier == SIP identifier
84
Deployment scenariosDeployment scenarios
P
P
P
P
P
P2P proxies
P
P
P
P
P
P2P clients
Plug and play; May use adaptors;Untrusted peers;Super-nodes
Zero-conf server farm; Trusted servers and user identities
Interoperate among these!
85
SIP-using-P2PSIP-using-P2PUsing an External P2P network (distributed hash table - Using an External P2P network (distributed hash table - DHT)DHT)
Data model Treat DHT as
database
Service model Join DHT to provide
service
DHT
[1]
[2]
[3]
[1] put(k,192.1.2.3), k is H(bob)[2] get(k) gives 192.1.2.3[3] INVITE sip:bob to 192.1.2.3
bob192.1.2.3
alice
DHT[1]
[2]
[3]bob
alice
[4]
[5]
[5]
[1] join(128.3.4.5)[2] lookup(H(bob)) gives 128.3.4.5[3] REGISTER sip:bob to 128.3.4.5[4] lookup(H(bob)) gives 128.3.4.5[5] INVITE sip:bob to 128.3.4.5
Servicenode
(128.3.4.5)
86
SIP-using-P2PSIP-using-P2PImplementation in SIPc with the help of Xiaotao WuImplementation in SIPc with the help of Xiaotao Wu
OpenDHT Trusted nodes Robust Fast enough (<1s)
Identity protection Certificate-based SIP id == email
P2P forCalls, IM, presence, offline message, STUN server discovery and name search
P2P clients better than proxies:
Less DHT calls OpenDHT quota per
client limits put by proxies
87
P2P-over-SIPP2P-over-SIPNode architecture: registrar, proxy, user agentNode architecture: registrar, proxy, user agent
DHT communication using SIP REGISTER Known node: sip:[email protected] Unknown node: sip:[email protected] User: sip:[email protected]
User interface (buddy list, etc.)
SIPICE RTP/RTCP
Codecs
Audio devicesDHT (Chord)
On startup
Discover
User location
Multicast REGISTERPeer found/Detect NAT
REGISTER
REGISTER, INVITE,MESSAGE
Signup,Find buddies
JoinFind
Leave
On resetSignout,transfer
IM,call
SIP-over-P2PP2P-using-SIP
88
P2P-over-SIPP2P-over-SIPImplementationImplementation
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
1
11
9
30
26
31
15
29
25
19
31
26
89
Chord backgroundChord background
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
1
8
14
21
32
38
58
47
10
2430
54
38
42
Key node
8+1 = 9 14
8+2 = 10
14
8+4 = 12
14
8+8 = 16
21
8+16=24
32
8+32=40
42
90
Design alternativesDesign alternatives
65a1fc
d13da3
d4213f
d462bad467c4
d471f1
d46a1c
Route(d46a1c)
18
14
21
3238
58
47
10
24 30
54
38
42
Use DHT in server farm
Use DHT for all clients; But some are resource limited
Use DHT among super-nodes
servers
clients
1
10
2430
54
38
91
SIP messagesSIP messages DHT (Chord) maintenance
Query the node at distance 2k with node id 11REGISTER
To: <sip:[email protected]>
From: <sip:[email protected]>
SIP/2.0 200 OK
To: <sip:[email protected]>
Contact: <sip:[email protected]>; predecessor=sip:[email protected]
Update my neighbor about meREGISTER
To: <sip:[email protected]>
Contact: <sip:[email protected]>; predecessor=sip:[email protected]
1
10
15
22
Find(11) gives 15
7
92
SIP messagesSIP messages
User registrationREGISTER
To: sip:[email protected]
Contact: sip:[email protected]:8094
Call setup and instant messagingINVITE sip:[email protected]
To: sip:[email protected]
From: sip:[email protected]
93
Adaptor for existing phonesAdaptor for existing phones
Use P2P-SIP node as an outbound proxy
ICE for NAT/firewall traversal STUN/TURN
server in the node
94
Hybrid architectureHybrid architecture Cross register,
or Locate during
call setup DNS, or P2P-SIP
hierarchy
95
P2P-over-SIPP2P-over-SIPAnalysis: scalabilityAnalysis: scalability
Number of messages depends on Number of peer nodes (N) Keep-alive (rs) and finger table refresh rate (rf) Call arrival distribution (c) Node join, leave, failure rates () Number of users (k.N) User registration refresh rate (t)M={rs+ rf(log(N))2} + c.log(N) + (k/t)log(N) + (log(N))2/N
Number of nodes = f(node-capacity)Nmax min[2M/(r+c),2M/r] for large N Measured M = 800 reg/s and assuming aggressive
refresh and call rate of 1/min, it gives 2219 nodes >> 2160.
Even for a conservative 10 req/s capacity, it gives more than 16 million nodes (super nodes) in the network.
96
P2P-over-SIPP2P-over-SIPAnalysis: availability and call setup latencyAnalysis: availability and call setup latency
To increase user availability: Increase keep-alive rate (fast failure
detection) Increase user registration refresh rate
(reduce unavailability) Replicate user and node registrations
Call setup latency: Same as DHT lookup latency: O(log(N))
Calls to known locations (“buddies”) is direct DHT optimization further reduces latency
Chord: 10000 nodes => 6 hops At most a few seconds User availability and retransmission timers
97
Skype Skype From the KaZaA communityFrom 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
P
P
P
PP
PP
P
P P P
98
Related workRelated work P2P networks
Unstructured (Kazaa, Gnutella,…) Structured (DHT: Chord, CAN,…)
Skype and related systems Flooding based chat, groove, Magi Skype-in/out uses SIP
P2P-SIP telephony Proprietary: NimX, Peerio, File sharing: SIPShare Now in IETF: W&M, Avaya, Panasonic, …
99
Why we chose Chord?Why we chose Chord?Just as a simple example DHTJust as a simple example DHT
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
100
Why we chose Chord?Why we chose Chord?Reliability of Chord under churnReliability of Chord under churn
If 50% nodes fail, only 3% lookups fail If successor list length is O(logN) and
node failure probability is 50% in a stable network, then still works in O(logN) lookup hops.
Becomes strongly stable after O(N2) rounds of strong stabilization
If failures happen atmost N/2 in LogN steps, then becomes stable in O(N3)
101
Chord stabilization vs Chord stabilization vs availabilityavailability
Increasing message rate to 1.25 msg/sec/node allows < 0.4% failed lookupshttp://www.eecs.harvard.edu/~jonathan/sigops02/sigops02.html
102
JXTA vs Chord in P2P-SIPJXTA 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)
103
Node startupNode startup SIP
REGISTER with SIP registrar DHT
Discover peers: multicast REGISTER
Join DHT using node-key=Hash(ip) REGISTER with DHT using user-
key=Hash([email protected]) Dialing out
Call, instant message, etc. INVITE sip:[email protected]
MESSAGE sip:[email protected] Last seen, SIP NAPTR/SRV, DHT
REGISTER
DB
sipd
Detect peers
columbia.edu
14
32
5812
42
REGISTER alice=42
REGISTER bob=12
104
Node leavesNode leaves
Graceful leave Un-REGISTER Transfer registrations
Failure Attached nodes detect
and re-REGISTER New REGISTER goes to
new super-nodes Super-nodes adjust DHT
accordingly
DHT
REGISTER key=42
OPTIONS
42
42
REGISTER
105
Advanced servicesAdvanced services
Offline messages INVITE or MESSAGE fails =>
Responsible node stores voicemail, instant message.
Conferencing Mixer, full mesh, multicast
Inter-domain Local DHT; connected by DNS or
global DHT
Enterprise IP telephonyEnterprise IP telephony
107
Goal of my workGoal of my work Beyond voice: video, text, IM, presence, screen sharing, shared
web browsing, … Beyond SIP phone: regular telephone, email, web, … Beyond synchronous communication: offline mails, discussion
forum, file sharing, …
ProgramCall
routing
SIP SAP RSVP RTCP
RTP
MediaG.711MPEG
RTSP
Signaling Quality of service Media transport
InternetTelephony
InternetRadio/TV Messaging
and Presence
Interactivevoice response
Unified messagingVideo
conferencing
Physical layer
Link layer
Network (IPv4, IPv6)
Transport (TCP, UDP)
Application layer
VoiceXML
DTMF MixingSpeech/
textSDP
ProgramCall
routing
SIP SAP RSVP RTCP
RTP
MediaG.711MPEG
RTSP
Signaling Quality of service Media transport
InternetTelephony
InternetRadio/TV Messaging
and Presence
Interactivevoice response
Unified messagingVideo
conferencing
Physical layer
Link layer
Network (IPv4, IPv6)
Transport (TCP, UDP)
Application layer
Physical layer
Link layer
Network (IPv4, IPv6)
Transport (TCP, UDP)
Application layer
VoiceXML
DTMF MixingSpeech/
textSDP
108
Related workRelated workIP telephony and multimedia IP telephony and multimedia communicationcommunication
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, Breeze
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
109
Related workRelated workComprehensive multi-platform Comprehensive multi-platform collaborationcollaboration
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
Email, teleconference Vendor specific tools,
platform dependence Application specific
E.g., collaborative software development
110
Multi-party collaborationMulti-party collaborationWhat is done, and what is left.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
111
Communication to Communication to collaborationcollaboration Comprehensive
Personalized view Calendar, address book, groups and access control
Synchronous (tightly-coupled) collaboration Conferencing: audio, video, IM, white-board, screen sharing,
shared web browsing Asynchronous (loosely-coupled) collaboration
Unified messaging, shared files, discussion forum, notification Multi-platform (device)
Telephone: touch tone input and audio (IVR) PC: multimedia client, email, IM Reuse existing protocols and tools
Unified messaging The gaps among different media (audio, video, text),
devices (PC, phone) and means of communications (Email, SIP, IM) disappear for messaging
112
What’s next?What’s next?from multimedia communications to from multimedia communications to collaborationcollaboration
Synchronous communications Conferencing, IM
Asynchronous communications Voicemails, message board, file sharing
Ubiquitous computing i-button, ID-card
Service creation User friendly, end-point/network
[email protected]://www.cs.columbia.edu/~kns10/http://www.cs.columbia.edu/IRT/cinema
113
VoicemailVoicemail
Goals Universal access Scalability Provider
independent Why SIP and
RTSP? Reuse existing
infrastructure and tools
(1) INVITE
INVITE
INVITEOK
CANCEL
(3) OK
(2) SETUP
(4) RTP
(5) BYE
rtspd
sipum
114
Web interfaceWeb interface Retrieval
Web interface rtsp://server/alice
/inbox/1677.au, sip:alice-1677-
retrieve@server press 1 to listen…
Configuration Folders Options Email
115
Conferencing models Conferencing models (non-(non-multicast)multicast)
A
B C
D
B
A+C+D
A
B C
AB+C+D
A+B+D
C
D
D
A+B+C
A
B C
D
Topology star full-mesh ad-hoc
Advantages Heterogeneoussimple clients
No central point offailure
DisadvantagesExternal server with high bandwidth link
Complex endpointsComplex signaling
Typically only three party conferences
116
ConferenceConference
117
ConferenceConference
G.711, GSM, DVI, Speex, G.722 mixing (decode-mix-encode) Video replication; IM; text; VNC screen sharing; floor control; IVR for joining Optimization possible for same codecs
D
D
D
E
E
E
A
B
C
G711
DVI
GSM
Linear
Linear
Linear
G711
DVI
G711
Playout delay Periodictimer
M=A+B+C
Mixed linear
M - A=B+C
M - B
M - C
Receive Send
118
Performance evaluationPerformance evaluation
CPU usage = (.P + ).C = (Me+a.B’+b) and = (Md+c.B’+d)B’ = B + 320/TFor C conferences, each with P participants. a,b,c,d are constants; b,d are
comparatively insignificant For G.711 codec Me and Md are insignificant (5.5 and 1.7 s),
thus CPU = C.(a.P+c).(B+320/T) For GSM, G.722, (or G.723.1), Me and Md are dominant (70 and 30/50
s), thus CPU = C.(Me.P+Md)
Increase in parameter value
CPU Bandwidth Delay
Packetization interval (T) Reduces Reduces Increases
Codec bitrate (B) Increases Increases N/A
Codec complexity (M) Increases N/A N/A
Network jitter (J) N/A N/A Increases
119
Performance evaluationPerformance evaluation
About 480 participants in a single conference with one speaker
About 80 four-party conferences
Memory used 20 kB per call or participant
Delay less than 20 ms: increases from first to last participant in a conference
Packetization interval of 40 ms gives better performance: 720, but increases delay too
Both Pentium and Sparc took about 6 MHz/participant
120
CINEMACINEMAMy contribution in design and My contribution in design and implementationimplementation
sipdsip323 sipconf sipumsipvxmlrtspd
CINEMA Libraries
libNT
Win32 stub
libcine
Utilities parsingIPv6
libsip
Basic SIP library
libsipapi
SIP UA library
libconf
RTP audio mixer
libdict
Hash table
libdb++
mySQL interface
RTSP mediaserver
SIP proxy server
SIP/H.323gateway
SIP/RTP conferencing
SIP/RTSP unified messaging
SIP/VoiceXMLbrowser
Xerces-COpenH323
MySQLPWLibResparse
librtsp
RTSPclient
rtplib++
RTP library
libsnmp
SIP MIB
FliteXerces-C
CINEMA Applications
libcanon
canonicalize
libmedia
Recording, files
… and web-based GUI C/C++: 60K out of 187 KLOCTcl: 30 KLOC
121
ContributionContributionSip-h323: signaling translatorSip-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
122
ContributionContributionSipum: Unified messaging using SIP and Sipum: Unified messaging using SIP and RTSPRTSP
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
123
ContributionContributionSipconf: Centralized conferencing using Sipconf: Centralized conferencing using SIP/RTPSIP/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
124
ContributionContributionSipvxml: SIP-based VoiceXML browserSipvxml: 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) Email by phone (Pimrampai) Auto attendant (Sean)
125
ContributionContributionlibsip++: SIP user agent library in C++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 http://www.cs.columbia.edu/~kns10/software/siplib
126
ContributionContributionGUI: web-based user interfaceGUI: 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
Voicemail, file sharing, IM archive, groups, address book, calendar
Undergone three iterations See current version at
http://phone.cs.columbia.edu/cinema/
127
Interworking between SIP and Interworking between SIP and H.323H.323
IP and lower layers
TCP UDPTPKT
Q.931 H.245 RAS RTCPRTP
Codecs
Terminal Control/Devices
Transport Layer
SIP SDPRTP
CodecsRTCP
Terminal Control/Devices
Both use RTP for media thus allows scalable translator
SDP is simple. H.245 is very exhaustive and can represent inter-codec dependencies.
H.323 has multi-stage call setup. SIP has single stage. H.323 single step fast connect is optional
Basic calls are possible to translate. Complete interworking is not possible without modifying (conference, security).
128
SIP vs H.323SIP vs H.323
Text based request response
SDP (media types and media transport address)
Server roles: registrar, proxy, redirect
Binary ASN.1 PER encoding
Sub-protocols: H.245, H.225 (Q.931, RAS, RTP/RTCP), H.450.x...
H.323 Gatekeeper
Both use RTP/RTCP over UDP/IP
129
Interworking ProblemsInterworking ProblemsCall setup translationCall setup translation
Q.931 SETUP
Q.931 CONNECT
INVITE
200 OK
ACK
Terminal Capabilities
Terminal Capabilities
Open Logical Channel
Open Logical Channel
H.323 SIP
Destination address ([email protected])
Media capabilities (audio/video)
Media transport address (RTP/RTCP receive)
• Multi-stage dialing• H.323v2 Fast-start is optional
130
Interworking ProblemsInterworking ProblemsUser RegistrationUser Registration
H.323 SIP
• Location independent user identifier ?• Use information from both networks
H.323 terminal
H.323 Gatekeeper SIP registrar
SIP user agent
?
Alias: HenryE164: 7040
131
Interworking ProblemsInterworking ProblemsMedia DescriptionMedia Description
H.323/H.245 (declare your exact modes)
• Translation in both directions• Algorithm selection by end-systems
Supports inter-media constraints { [G.711 Mu law, G.711 A law][H.261 video]} { [G.723.1] [no video] }
SIP/SDP (dynamically choose from listed modes)
List of alternative set of algorithms. audio G.711 Mu law, G.723.1, G.728 video H.261
132
Interworking ProblemsInterworking ProblemsCommon subset of media capabilitiesCommon subset of media capabilities
{[a1,a2,a3], [v1,v2]}{[a1,a4,a5],[v1]} {[a1,a4,a2],[v1,v2,v3]}{[a1,a2,a5],[v1,v3]}
D1 D1’: {[a1,a2,a3],[v1,v2]}{[a1,a4,a2],[v1,v2,v3]}
D1 D2 D1’ D2’
D2 D1’: {[a1,a4,a5],[v1]} {[a1,a4,a2],[v1,v2,v3]}
D1 D2’: {[a1,a2,a3],[v1,v2]}{[a1,a2,a5],[v1, v3]}
D2 D2’: {[a1,a4,a5],[v1]} {[a1,a2,a5],[v1,v2,v3]}
S1 S2 S1’ S2’ S1^S1’, S2^S2’: {[a1,a2],[v1,v2]}S1^S2’, S2^S1’: {[ ],[ ]}
{[a1,a4],[v1]}
{[ ],[ ]}
{[a1,a2],[v1]}
{[ ],[ ]}
{[a1,a5],[v1]}
{[ ],[ ]}
Result: {[a1,a2],[v1,v2]} {[a1,a4],[v1]} {[a1,a5],[v1]}
133
Interworking ProblemsInterworking ProblemsCall ServicesCall Services
H.323 Conferencing: centralized signaling control, MC (Multi-point Controller)
Supplementary services, like call transfer: H.450.x
SIP Conferencing: centralized bridged + decentralized distributed
REFER, 3pcc
134
Interworking ProblemsInterworking ProblemsSecurity and QoSSecurity and QoS
H.323 uses H.235, whereas SIP uses Basic, Digest, TLS, S/MIME
Media Traffic end-to-end; QoS ?
135
What we want ?What we want ?
Transparent translation Minimum modification in SIP or H.323 Use features from both SIP and H.323 Direct RTP/RTCP traffic; end-to-end
136
User registrationUser registrationRegistration info Registration info toto foreign network foreign network
H.323 terminal128.59.19.200
H.323 Gatekeeper + SGWpc1.office.com
[email protected]:128.59.19.200
SIP registrar server
SIP user agent
INVITE [email protected]
3xx MovedContact:pc1
home.com
use SIP REGISTER and/or H.323 RRQ/RCF
137
User registrationUser registrationRegistration info Registration info fromfrom foreign network foreign network
use SIP OPTIONS and/or H.323 LRQ/LCF
H.323 terminal128.59.19.200
H.323 Gatekeeperpc1.office.com
[email protected]:128.59.19.200
SIP registrar server + SGW
SIP user agent
LRQ/LCF
INVITE [email protected]
200 OK
home.com
138
User registrationUser registrationDifferent ArchitecturesDifferent Architectures
• SGW co-located with H.323 gatekeeper
• SGW co-located with SIP registrar/proxy server
• Independent SGW
139
Call SetupCall Setupwith H.323v2 Fast Startwith H.323v2 Fast Start
(Almost) One-to-one mapping between SIP and H.323 messages.
INVITE
200 OK.
ACK
Setup/FastStart
Connect/FastStart
H323 SIP
RTP/RTCP
Reverse direction is similar
140
Call SetupCall Setupwithout Fast Startwithout Fast Start
Q.931 SETUP
Q.931 CONNECT
INVITE
200 OK
ACK
Terminal Capabilities
Terminal Capabilities
Open Logical Channel
Open Logical Channel
H.323 SIP
Destination address ([email protected])
Media capabilities (audio/video)
Media transport address (RTP/RTCP receive)
Accept the call from H.323, forward to SIP after OLC ? Not desirable.
141
Call SetupCall Setupwithout Fast Start, SIP to H.323without Fast Start, SIP to H.323
INVITE
200 OK.
ACK
Setup/Q931
Connect/Q931
Capabilities/H245
Open Logical Channel/ H245
Open Logical Channel / H245
Capabilities/H245.
SignalingGateway
RTP/RTCP
H323 SIP
Acknowledgement
Acknowledgement
Media Transport Address
142
Call SetupCall Setupwithout Fast Start, H.323 to SIPwithout Fast Start, H.323 to SIP
RTP/RTCP
H323 SIP
INVITE
200 OK
ACK
Setup/Q931
Connect/Q931
Capability Exchange
Open Logical Channel
SignalingGateway
Open Logical Channel
Re-INVITE/SIP+SDP
Acknowledgement
Acknowledgement
Media Transport Address
143
Media CapabilityMedia Capability
• Modify SIP/SDP : multiple capability sets, or...
• Let the SGW choose a sub-set of capabilities for SIP side
• Re-INVITE or change in H.323 mode or logical channels, whenever it changes
144
AliceBob
INVITE [email protected] can support -law and G.729Send me audio at 202.16.49.27:6780
OK; I can support -lawSend me audio at 128.59.19.194:8000
202.16.49.27 128.59.19.194
To port 6780
To port 8000RTP
RTP
Session descriptionSession description
Y
145
Presence/event notificationPresence/event notification
PA
registrar
Presence server
office.com
SUBSCRIBE
NOTIFY
PUA
PUA
PUA + PA
Y
146
Columbia Columbia IM and presenceIM and presence
Y
147
Network call controlNetwork call control
SIP-CGI CPL SIP servlets
Priority.pl
SIP_FROMSIP_TOstdin
CGI-PROXY-REQUESTstdout
SIP proxy
Urgent
Low-priority
Voicemail
Phone
Y
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";
}
}
148
Call transferCall transfer
REFER Blind/
consultation/ attended
active call
REFER CReferred-By: B
INVITE CReferred-By: B
BYE A
A B
C
active call
O
149
B2BUA and third-party call B2BUA and third-party call controlcontrol
Back-to-back UA Incoming call
triggers outgoing call
Services Calling card Anonymizer
INVITE
AB
CSIP
SIP
OK (SDP1)
ACKINVITE (SDP1)
OK (SDP2)
ACKINVITE (SDP2)
OK
ACK
O
150
VoicemailVoicemail
Problems in PSTN
Design alternatives
Issues
Redirect after 10s
vmail.pl
SIP_FROMSIP_TOstdin
CGI-PROXY-REQUESTstdout
If no response accept after 15s
Endpoint redirects
Voicemail acts like a phoneProxy controls
Y
151
VoiceXMLVoiceXML
Telephone
PSTNPSTN
Voice gateway
Web server
• Service logic (CGI, servlet, JSP)
• Voice and telephony functions• VoiceXML browser
Internet userVXMLVXML HTMLHTML
Internet
Internet
IVR platform• Voice and telephony functions (ASR, TTS, DTMF)• Service logic (application specific)
sipvxmlGateway
Y
152
VoiceXML contd.VoiceXML contd.
<form action=“url”> Enter your Id: <input name=‘id’> <input type=‘submit’> </form>
<form> <field name=‘id’> <prompt> Your ID, please. </prompt> </field> <block> <submit next=“url”/> </block></form>
Telephony, speech synthesis or audio output, user input and grammar, program flow, variable and properties, error handling, …
Y
153
Columbia Columbia sipvxmlsipvxml
Unified messaging access
Email by phone Event notification
and scheduling Audio volume control
for conference Advanced
conference control
Telephone SIP/PSTNgateway
PSTNPSTN
sipvxmlsipvxml SIP phone
Web server
Internet
Internet
Email.tcl
Media serverrtspd
TTS, ASR, DTMF, XML, HTTP, RTSP
Y
154
Email + phoneEmail + phone
Login Email formatting Listen, reply,
delete, compose, forward
Navigation -next, previous, jump
Email formatting
SIP based Text-to-speech
VoiceXMLbrowser
Emailservlet
JSP
DB
procmailEmail
Email to IM
IM
Call
Internet
Internet
TTS
important mails
SIP
SIP
Internet
Internet
SIP
HTTP
Email by phone
Email to phone
Y
Inbox
Inbox
155
IM + voice callIM + voice call
Who can initiate? authentication,
billing, … Feedback
to voice user to IM user initial IM greeting
Talk-spurt detection Speech recognition
IM
Call
TTSASR
SIPMESSAGE
SIPINVITERTP
Y
156
NotificationNotification Calendar Events Conference
s
Web server
Calendar.cgi “at 6:00pm”
Schedule from a browser
SIP call2129397063
IMkundan@
EmailKns10@…
O
157
Phone announcement serverPhone announcement server
Input Range:93970?? List: A, B, C
Example Announcement Emergency
Issues Voicemail Failure
detection
PASTTS
Destinations
SIP
Text or audio
. . .
Y
158
RTSP + TTS + ASRRTSP + TTS + ASR
Media server
TTSASR
SETUP rtsp://server/tts.cgi?text=How+are+you.
PLAY
RTP
SETUP rtsp://server/asr.cgi
RECORD
RTP
SET_PARAMETERText=I am fine, thank you.
O
159
Centralized conferencingCentralized conferencing Conference as URL
[email protected] On the fly conferences
my.adhoc@server Basic task: join/leave
Dial in, Refer dial in Dial out, Refer dial out
REFERINVITE
REFER
INVITEINVITE
server
O
160
Conference + VoiceXMLConference + VoiceXML
sipvxmlsipvxml
CallerCaller
sipconfsipconf
1. INVITE sipvxml2. Call accepted3. Enter your four digit PIN4. Entered 4-6-8-3
5. Authenticate user, 4683=>Alice6. Enter the conference identifier7. Entered 2-3-#
8. Permission to join, 23=>meet9. REFER [email protected] the old call
11.INVITE meet@conference
Call transfer vs bridged mode
Y
161
New conference applicationsNew conference applications
sipvxmlsipvxml
CallerCaller
1. INVITE sipvxml2. Menu 1. Vol Check 2. Mic Check3. User enters 2
4. User speaks out a voice sample5. Voice sample is analyzed
7. User adjusts the vol level.
The ease & flexibility of sipvxml enables us to build custom telephonic applications to suit our needs.
e.g., Volume Check Application
sipconfsipconf 8. User now joins conference.
6. SipVXML: Vol level too high/low/…
Y
162
ConferencingConferencing
Automatic volume adjustments
Automatic load balancing
Delay adjustments Conference
recording Local or RTSP
Y
sipcsipcSIP323SIP323
SIP/PSTNSIP/PSTNRecording in a media server
163
PSTN interworkingPSTN interworking
Translating audio (PCMU/PCMA) Translating signaling (PRI/T1,ISUP)
Overlap signaling Advanced features in SIP are lost in PSTN
Translating identifiers (phone number) Determining transition points
Telephonenetwork
SIP/PSTN gateway
SIP server IP endpointTelephonesubscriber
+1 212 9397063 sip:[email protected]
164
PSTN to IPPSTN to IP
Gateway knows the SIP server <sip:[email protected];user=phone>
ENUM DNS +1 212 9397042 => 2.4.0.7.9.3.9.2.1.2.1.e164.arpa => sip:[email protected]
Suitable for relatively “static” contacts
165
IP to PSTNIP to PSTN Static mapping
1-212-939xxxx => @itgw1.cs.columbia.edu ITGW information is dynamic:
Overlapping networks Multiple providers Load balancing
TRIP Route advertisement Can be implemented in outbound proxy Suitable for current hierarchical network+1 @service.mci.com at 4¢/min+1212 @nyc.gw.com at 1¢/min+1212939 @itgw1.columbia.edu free
166
30 second version30 second version I developed reliability and scalability techniques
for Internet telephony and showed that it is at par with the existing telephone system reliability and scalability at a much lower cost.
I developed interoperable architecture to build self organizing network of Internet telephones, without depending on managed infrastructure or servers.
I developed tools and components for a multi-platform multimedia collaboration system using existing standards and showed that it can scale to large number of simultaneous participants.
167
Scientific contributionScientific contribution
That linear cluster scalability can be observed in SIP servers.
That we don’t need to depend on servers or managed infrastructure for Internet telephony.
That we can build highly scalable and reliable Internet telephony systems using existing standards on commodity hardware.
