Transcript Autonomic - Columbia University

Peer-to-peer VoIP
Kundan Singh, Salman Baset and Henning Schulzrinne
Internet Real Time Laboratory
Computer Science Dept., Columbia University, New York
http://www.cs.columbia.edu/IRT/p2p-sip
http://www.cs.columbia.edu/IRT/dotslash
Overview
•
•
•
•
P2P – definition and motivation
Analysis of Skype
SIP-based peer-to-peer
Using existing overlays for peer-to-peer-VoIP
IBM Delhi (Jan. 2006)
2
P2P for autonomic computing
•
•
•
Autonomic at the application layer:
– Robust against partial network faults
– Resources grow as user population grows
– Self-configuring
Traditional p2p systems
– file storage
• motivation is often legal, not technical, efficiency
– usually unstructured, optimized for Zipf-like popularity
Other p2p applications:
– Skype demonstrates usefulness for VoIP 
• identifier lookup
• NAT traversal: media traversal
– OpenDHT (and similar) as emerging common infrastructure?
– Non-DHT systems with smaller scope  web hotspot rescue
– Network management (see our IRTF slides)
IBM Delhi (Jan. 2006)
3
Aside: middle services instead of middleware
• Common & successful network services
– identifier lookup: ARP, DNS
– network storage: proprietary (Yahoo, .mac, …)
– storage + computation: CDNs
• Emerging network services
– peer-to-peer identifier lookup
– network storage
– network computation (“utility”)
• maybe programmable
• already found as web hosts and grid computing
IBM Delhi (Jan. 2006)
4
What is P2P?
•
Computer systems
Centralized
Distributed
mainframes
workstations
Client-server
Flat
Hierarchical
RPC
HTTP
DNS
mount
Share the resources of
individual peers
– CPU, disk, bandwidth,
information, …
Communication and collaboration
Magi
Groove
Skype
Peer-to-peer
Pure
Hybrid
Gnutella
Chord
Napster
Groove
Napster
Gnutella
Kazaa
Freenet
Overnet
Kazaa
C
C
S
C
C
C
P
P
P
P
P
File sharing
SETI@Home
folding@Home
Distributed computing
IBM Delhi (Jan. 2006)
5
Overview - Skype
• What is Skype?
• What problems does it solve?
• The Skype network
• The Skype software components
• Experimental setup
• The Skype functions
• How to block Skype?
• Skype, MSN, and Yahoo
• Disassembling the executable
• Unanswered questions
IBM Delhi (Jan. 2006)
6
What is Skype?
• Peer-to-peer, pc-to-pc, pc-to-phone, phone-to-pc
VoIP client
• Developed by people who created KaZaa
• First version in September 2003
• 60,000 downloads in first week, 219 million
downloads (till yesterday)
• Current version: 1.4.0.84 and 2.0 beta
• SkypeOut (pc-to-phone) introduced in July 2004
– SkypeOut terms of service: governed by the
laws of Luxembourg
• SkypeIn, voicemail
• OS: Windows, Linux, MacOS, PocketPC
IBM Delhi (Jan. 2006)
7
What problems does it solve?
• NAT and firewall traversal
– Nielsen September 2005 ratings
• 61.3% of US home internet users use
broadband
(http://www.nielsen-netratings.com/pr/pr_050928.pdf)
• ‘Most’ users have some kind of NAT
– approximately 50% (MSDN)
• NATs come in many different flavors
– most allow some “funneling”
• Superior voice quality compared to MSN or Yahoo
IM clients
• Phone-to-PC calling, SkypeIn
– Yahoo is starting to imitate Skype services
IBM Delhi (Jan. 2006)
8
A p2p illusion?
• Login server
• Servers for SkypeOut and SkypeIn
• Anonymous call minutes statistic
gathering
IBM Delhi (Jan. 2006)
9
The Skype Network
IBM Delhi (Jan. 2006)
10
The Skype Network (contd…)
• Ordinary host (OH)
– A Skype client
• Super nodes (SN)
– A Skype client
– Has public IP address, ‘sufficient’ bandwidth, CPU
and memory
• Login server
– Stores Skype id’s and passwords
– Used at login for authentication
– Version 0.97: 80.160.91.11
now: 212.72.49.141 and 195.215.8.141
IBM Delhi (Jan. 2006)
11
Skype Components
•
Ports
– No default listening port
– Randomly chooses a port (P1) on installation
– Opens TCP, UDP listener sockets at P1
– TCP listener sockets at port 80, 443
IBM Delhi (Jan. 2006)
12
Skype Components (contd…)
•
Host cache (HC)
– IP address and port number of online Skype
nodes (SNs)
– At least one valid entry must be present in HC
– Maximum size: 200 entries
– ‘Understanding KaZaa’: 200 entries for ordinary
node (ON)
– Login server IP address and port number
– Stored in Windows registry in version 0.97
– Now present at
C:\Documents and Settings\All Users\Application Data\Skype
IBM Delhi (Jan. 2006)
13
Skype HC (ver: 0.97)
IBM Delhi (Jan. 2006)
14
Skype HC
IBM Delhi (Jan. 2006)
15
Skype Components (Contd…)
• Codecs (GlobalIPSound)
– Wide band codecs (50-8,000 Hz)
– iLBC (packet size: 20 and 30 ms bitrate: 15.2 kbps and 13.3 kbps)
– iSAC (packet size: 30-60 ms bitrate: 10-32 kbps)
– G.729 for SkypeOut?
• Buddy list
– Stored in ‘config.xml’ file
• C:\Documents and Settings\<XP user>\Application Data\Skype\<skype user id>
<CentralStorage>
<LastBackoff>0</LastBackoff>
<LastFailure>0</LastFailure>
<LastSync>1120325519</LastSync>
<NeedSync>0</NeedSync>
<SyncSet>
<u>
<skypebuddy1>f384d3a0:1</skypebuddy1>
<skypebuddy2>7d1dafc4:1</skypebuddy2>
IBM Delhi (Jan. 2006)
16
Experimental Setup
• We have NOT reverse engineered Skype
executable but it can be done
• Skype version: 0.97.0.6, 1.0, 1.2, 1.4
• Experiments performed between Feb-May 2004,
June-July and Nov-Dec 2005.
• Tools Used
– Ethereal (for packet capture)
– NetPeeker (for tuning the bw)
– NCH Tone generator
(for generating tones of various frequencies)
– APIMonitor (for monitoring the sys calls)
IBM Delhi (Jan. 2006)
17
Experimental Setup (Contd…)
INTERNET
B (public IP)
A (public IP)
INTERNET
A (private IP)
B (public IP)
port-restricted NAT
INTERNET
A (private IP address)
B (private IP address)
port-restricted NAT
UDP-blocking firewall
port-restricted NAT
UDP-blocking firewall
IBM Delhi (Jan. 2006)
18
Skype Functions
• Startup
• Login
• User Search
• Call Establishment
• Media Transfer
• Keep-Alive
• NAT and firewall Traversal
• Conferencing
IBM Delhi (Jan. 2006)
19
Skype Functions: STARTUP
• First time startup
– GET /ui/0/97/en/installed HTTP/1.1
•
Normal startup
– GET /ui/0/97/en/getlatestversion?ver=0.97.0.6
HTTP/1.1
IBM Delhi (Jan. 2006)
20
Skype Functions: LOGIN
• Must establish a TCP connection with SN
• HC must contain at least one valid SN
• Bootstrap Super Nodes
IP address:port
Reverse Lookup Result
Authority Section
66.235.180.9:33033
sss1.skype.net
ns1.hopone.net
66.235.181.9:33033
No PTR result
ns1.hopone.net
212.72.49.143:33033
No PTR result
ns-pri.ripe.net
195.215.8.145:33033
No PTR result
ns3.DK.net
64.246.49.60:33033
rs-64-246-49-60.ev1.net
ns2.ev1.net
64.246.49.61:33033
rs-64-246-49-61.ev1.net
ns2.ev1.net
64.246.48.23:33033
ev1s-64-246-48-23.ev1servers.net
ns1.ev1.net
IBM Delhi (Jan. 2006)
21
Skype Functions: LOGIN
• Public, NAT
– Establish a TCP connection with the SN
– Authenticate with the login server
– Announce arrival on the network
(controlled? flooding)
– Determine NAT type?
• Firewall
– Establish a TCP connection with the SN
– Authenticate with the login server
IBM Delhi (Jan. 2006)
22
Skype Functions: LOGIN
SC
66.235.180.9:33033 (Bootstrap node)
UDP
31B
61B
UDP
SC
SN: (IP address not shown for privacy reasons )
TCP
94B
1514B
TCP
SC
212.72.49.141:33033 (login server )
TCP: SYN
TCP:ACK
16 3 1 0 0
5B (1)
TCP
17 3 1 0 0
5B (2)
TCP
16 3 1 0 0 . . . .
401B (3)
TCP
17 3 1 0 0 len . . .
TCP
218B (4)
.
IBM Delhi (Jan. 2006)
23
Skype Functions: LOGIN
• 1536 and 2048 (skype account) bit RSA to negotiate
symmetric AES keys
• Central Server Signing Key SS and Verification Key VS
• Client: user name A, password PA, RSA key pair SA and VA
• VS embedded in the Skype executable
• 256 bit AES session with the login server
• Key is chosen at random and encrypted with the public
key of the login server
• {A, H(PA), VA} VS to login server (msg 3)
• {A, VA} SS to client (msg 4)
• Source: Tom Berson’s security evaluation
IBM Delhi (Jan. 2006)
24
Skype Functions: LOGIN
Start
Send UDP
packets to seven
bootstrap SNs at
port 33033
Response within
5 seconds
Yes/No
TCP connection attempts
with seven bootstrap SN
IP addresses and
1) port 33033
2) port 80 (HTTP port)
3) port 443 (HTTPS port)
Success
Connected
Yes
No
Wait for 22 seconds
IBM Delhi (Jan. 2006)
25
Skype Functions: Login
Public
NAT
Firewall
Data
Exchanged
9 kilobytes
10 kilobytes
8.5 kilobytes
Time to
login
3-7 seconds
3-7 seconds
30-35 seconds
IBM Delhi (Jan. 2006)
26
Skype Functions: USER SEARCH
• From the Skype website
– Global Index (GI) Technology
– Guaranteed to find a user it exists and
logged in the last 72 hours
• Search results are cached at intermediate nodes
• Unable to trace messages beyond SN
• Cannot force a node to become a SN
– Host cache is used for connection establishment and
not for SN selection
• User does not exist. How does search terminate?
• SN searches for a user behind UDP-restricted firewall
• Same search query from two different machines initiated
at the same time give different results
• Wildcard queries supported
IBM Delhi (Jan. 2006)
27
Skype Functions: USER SEARCH
Data
Exchanged
Public
NAT
Firewall
1-2 kilobytes
1-2 kilobytes
2-4 kilobytes
IBM Delhi (Jan. 2006)
28
Call Establishment
•
•
•
•
•
•
Call signaling always carried over TCP
Calls to non buddies=search+call
Initial exchange checks for blocked users
Public-public call
– Caller SC establishes a TCP connection with callee SC
Public-NAT
– Caller SC is behind NAT
– Caller---->Skype node (SN?) ----> Callee
– TCP connection established between caller, callee, and more
than one Skype nodes
– Unknown: How a node is selected to route calls from caller to
callee?
• Perhaps determined at login
Firewall-firewall call
– Same as public-NAT
IBM Delhi (Jan. 2006)
29
Call Establishment
Data
Exchanged
Public-public
Public-NAT
Firewall-Firewall
4-5 kilobytes
6-8 kilobytes
6-7 kilobytes
IBM Delhi (Jan. 2006)
30
Skype Functions: Media Transfer
• 10/100 Mbps Ethernet
Public-Public
Public-NAT
Firewall-firewall
Packet Size
67 bytes
67 bytes
69 bytes
Stream BW
5 kilobytes/s
5 kilobytes/s
5 kilobytes/s
Transport
UDP
UDP
TCP
IBM Delhi (Jan. 2006)
31
Skype Functions: MEDIA TRANSFER
• No silence suppression
• Silence packets are used to
– play background noise at the peer
– maintain UDP NAT binding
– avoid drop in the TCP congestion window
• Putting a call on hold
– 3 packets/sec to call-peer or Skype node
– same reasons as above
• Codec frequency range
– 50-8,000 Hz (total bw of 3 kilobytes/s)
• Reasonable call quality at (4 kilobytes/s)
IBM Delhi (Jan. 2006)
32
Skype Functions: Keep Alive
• Refresh message over TCP to SN every 60 seconds
• Refresh message size: 60 bytes
IBM Delhi (Jan. 2006)
33
Skype Functions: Conferencing
•
A, B, and C have public IP addresses
1: B-A
Call
A: Pentium4,
2GHz
B: PentiumII , 300 MHz
C: Pentium Pro 200 MHz
IBM Delhi (Jan. 2006)
34
Skype Functions: Conferencing
•
A, B, and C have public IP addresses
1: B-A
Call
A: Pentium4,
2GHz
B: PentiumII , 300 MHz
2: B-C
Call
IBM Delhi (Jan. 2006)
C: Pentium Pro 200 MHz
35
Skype Functions: Conferencing
•
A, B, and C have public IP addresses
1: B-A
Call
A: Pentium4,
2GHz
B: PentiumII , 300 MHz
B decides to
initiate a
conference
2: B-C
Call
IBM Delhi (Jan. 2006)
C: Pentium Pro 200 MHz
36
Skype Functions: Conferencing
•
A, B, and C have public IP addresses
A: Pentium4,
2GHz
B
A+C
B: PentiumII , 300 MHz
C
A+B
C: Pentium Pro 200 MHz
IBM Delhi (Jan. 2006)
37
Skype Functions: Conferencing
•
B and C are behind NAT. A has public IP addresses
B
Online Skype
node
A
A
B
A: Pentium4,
2GHz
1: B-A
Call
B: PentiumII , 300 MHz
C: Pentium Pro 200 MHz
IBM Delhi (Jan. 2006)
38
Skype Functions: Conferencing
•
B and C are behind NAT. A has public IP addresses
A: Pentium4, 2GHz (public
IP)
Online Skype
node
B
A+C
C
A+B
B: PentiumII , 300 MHz
C: Pentium Pro 200 MHz
(NAT)
(NAT)
IBM Delhi (Jan. 2006)
39
How to block Skype?
• Block IP address and port of Skype login servers.
• Skype goes through super nodes.
• Inspect TCP payload of login messages and block outgoing
login messages.
• Skype is blocked.
IBM Delhi (Jan. 2006)
40
Skype, MSN, and Yahoo
Application
version
Memory usage
before call
(caller, callee)
Memory usage
after call
(caller, callee)
Process
priority
before call
Process
priority
during call
Mouth-to-ear
latency
18 KB, 19 KB
Normal
High
90ms~
Skype
1.2
MSN
6.2
20 KB, 19 KB
25 KB, 25 KB
Normal
Normal
95ms~,
130ms~
7.0 beta
33 KB, 33 KB
38 KB, 29 KB
Normal
Normal
190ms~
Yahoo
17 KB, 10 KB
IBM Delhi (Jan. 2006)
41
Call / IM Forking
•
•
•
•
User can login from multiple machines
All Skype instances notified of call arrival
Pickup, cancel at other locations
IMs delivered to all locations
IBM Delhi (Jan. 2006)
42
Skype Online Users
pm
4:
54
pm
3:
00
pm
2:
00
12
:4
8
pm
am
5:
19
am
3:
00
am
1,400,000
1,200,000
1,000,000
800,000
600,000
400,000
200,000
0
2:
27
Online Users
Skype Online Users vs Time (Nov 24, 2004)
Time
IBM Delhi (Jan. 2006)
43
Breaking the executable
•
•
•
•
•
•
Skype does not run with ltrace
Skype does run with strace
nm does not reveal anything
libcrypt is (perhaps) statically linked. ldd does not reveal
anything
Skype can be run with SoftICE, OllyDbg
LD_PRELOAD technique
IBM Delhi (Jan. 2006)
44
Unanswered questions
•
•
•
•
How Skype encrypts and decrypts?
SN to SN communication?
One hop or multiple hop media relaying?
How does search terminate if the user is not found?
IBM Delhi (Jan. 2006)
45
Skype: Conclusions
•
•
•
•
Login server and super nodes, not strictly peer-to-peer
Code obfuscation, runtime decryption
Multiple paths for ‘in-time’ switching incase of failures
Other companies are following Skype
– damaka, peerio, pc-telephone
IBM Delhi (Jan. 2006)
46
Back to SIP-based peer-to-peer VoIP
• Distributed hash tables
• Functions for peer-to-peer
– call routing, presence, …
• Using SIP to build a DHT
• Using OpenDHT as an infrastructure
IBM Delhi (Jan. 2006)
47
Distributed Hash Table (DHT)
• Types of search
– Central index (Napster)
– Distributed index with flooding (Gnutella)
– Distributed index with hashing (Chord, Bamboo, …)
• Basic operations
find(key), insert(key, value), delete(key),
but no search(*)
Properties/types
Every peer has complete
table
Chord
Every peer has one
key/value
Search time or messages
O(1)
O(log(N))
O(n)
Join/leave messages
O(n)
O(log(N)2)
O(1)
IBM Delhi (Jan. 2006)
48
CAN
Content Addressable Network
•
•
•
Each key maps to one point in the
d-dimensional space
Each node responsible for all the
keys in its zone.
Divide the space into zones.
1.0
C
D
E
B
A
0.0
1.0
0.0
C
D
A
B
IBM Delhi (Jan. 2006)
E
49
CAN
1.0
E
A
B
X
E
A
B
X Z
.75
C
C
.5
D
D
.25
(x,y)
0.0
0.0
.25
.5
.75
1.0
Node X locates (x,y)=(.3,.1)
Node Z joins
State = 2d
Search = dxn1/d
IBM Delhi (Jan. 2006)
50
Chord
• Identifier circle
• Keys assigned to
successor
• Evenly distributed keys
and nodes
1
54
8
58
10
14
47
21
42
38
32
38
24
30
1 2006) 2
IBM 0
Delhi (Jan.
3
4
5
6
7
8 51
Chord
1
54
8
58
10
14
47
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
21 •
42
Finger table: logN
• ith finger points to first node
that succeeds n by at least 2i-1
• Stabilization after join/leave
38
32
38
24
30
IBM Delhi (Jan. 2006)
52
Tapestry
• ID with base B=2b
• Route to numerically closest
node to the given key
• Routing table has O(B) columns.
One per digit in node ID
• Similar to CIDR – but suffixbased
763
427
364
123
324
365
135
564
**4 => *64 => 364
N=2
N=1
N=0
064
?04
??0
164
?14
??1
264
?24
??2
364
?34
??3
464
?44
??4
564
?54
??5
664
?64
??6
IBM Delhi (Jan. 2006)
53
Pastry
• Prefix-based
• Route to node with shared
prefix (with the key) of ID at
least one digit more than this
node
• Neighbor set, leaf set and
routing table
d471f1
d46a1c
d467c4
d462ba
d4213f
Route(d46a1c)
d13da3
65a1fc
IBM Delhi (Jan. 2006)
54
Other schemes
•
•
•
•
•
•
Distributed TRIE
Viceroy
Kademlia
SkipGraph
Symphony
…
IBM Delhi (Jan. 2006)
55
DHT Comparison
Property/
scheme
Un-structured
CAN
Chord
Tapestry
Pastry
Viceroy
Routing
O(N) or no
guarantee
d x N1/d
log(N)
logBN
logBN
log(N)
State
Constant
2d
log(N)
logBN
B.logBN
log(N)
Join/leave
Constant
2d
(logN)2
logBN
logBN
log(N)
Reliability
and fault
resilience
Data at Multiple
locations;
Retry on failure;
finding popular
content is efficient
Multiple peers
for each data
item; retry on
failure; multiple
paths to
destination
Replicate data on
consecutive peers;
retry on failure
Replicate data on multiple peers;
keep multiple paths to each peers
IBM Delhi (Jan. 2006)
Routing load is
evenly distributed
among participant
lookup servers
56
The basic SIP service
• HTTP: retrieve resource identified by URI
• SIP: translate address-of-record SIP URI
(sip:[email protected]) to one or more contacts (hosts
or other AORs, e.g., sip:[email protected])
– single user  multiple hosts
• e.g., home, office, mobile, secretary
• can be equal or ordered sequentially
• Thus, SIP is (also) a binding protocol
– similar, in spirit, to mobile IP except application layer
and without some of the related issues
• Function performed by SIP proxy for AOR’s domain
– delegated logically to location server
• This function is being replaced by p2p approaches
IBM Delhi (Jan. 2006)
57
What is SIP? Why P2P-SIP?
(1) REGISTER
[email protected] =>128.59.19.194
(2) INVITE [email protected]
(3) Contact: 128.59.19.194
columbia.edu
Bob’s host
Alice’s host
128.59.19.194
Problem in client-server: maintenance, configuration, controlled infrastructure
(2) INVITE alice
Peer-to-peer network
(3) 128.59.19.194
(1) REGISTER
Alice
128.59.19.194
No central server, but more lookup latency
IBM Delhi (Jan. 2006)
58
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
SIP-using-P2P
P2P SIP proxies
P2P-over-SIP
Maintenance
P2P
P2P
SIP
Lookup
P2P
SIP
SIP
P2P network
FIND
INSERT
INVITE alice
INVITE sip:[email protected]
REGISTER
P2P-SIP
overlay
Alice
128.59.19.194
Alice
128.59.19.194
IBM Delhi (Jan. 2006)
59
Design alternatives
1
54
58
servers
47
42
38
38
8
d471f1
14 10
d46a1c
21
d467c4
d462ba
1
54
d4213f
10
32
24 30
Route(d46a1c)
d13da3
65a1fc
38
24 30
clients
Use DHT in
server farm
Use DHT for all
clients - but some
are resource limited
IBM Delhi (Jan. 2006)
Use DHT among super-nodes
1.
2.
Hierarchy
Dynamically adapt
60
Deployment scenarios
P
P
P
P
P
P
P
P
P
P
P
P
P
P2P clients
Plug and play;
May use adaptors;
Untrusted peers
P
P
P2P proxies
Zero-conf server farm;
Trusted servers and
user identities
P2P database
Global, e.g., OpenDHT;
Clients or proxies can use;
Trusted deployed peers
Interoperate among these!
IBM Delhi (Jan. 2006)
61
What else can be P2P?
•
•
•
•
•
•
Rendezvous/signaling (SIP)
Configuration storage
Media storage (e.g., voice mail)
Identity assertion (?)
PSTN gateway (?)
NAT/media relay (find best one)
Trust models are different for different components!
IBM Delhi (Jan. 2006)
62
What is our 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
IBM Delhi (Jan. 2006)
63
Implementation: SIPpeer
• Platform: Unix (Linux), C++
• Modes:
– Chord: using SIP for P2P maintenance
– OpenDHT: using external P2P data storage
• based on Bamboo DHT, running on PlanetLab nodes
• Scenarios:
– P2P client, P2P proxies
– Adaptor for existing phones
• Cisco, X-lite, Windows Messenger, SIPc
– Server farm
IBM Delhi (Jan. 2006)
64
P2P-SIP: identifier lookup
•
•
•
•
P2P serves as SIP location server:
– address-of-record  contacts
– e.g., [email protected] 
128.59.16.1, 128.72.50.13
multi-valued: (keyn, value1), (keyn,
value2)
with limited TTL
variant: point to SIP proxy server
– either operated by supernode or
traditional server
• allows registration of nonp2p SIP domains
(*@example.com)
– easier to provide call routing
services (e.g., CPL)
IBM Delhi (Jan. 2006)
alice  128.59.16.1
alice  128.72.50.13
65
Background: DHT (Chord)
1
54
8
58
10
14
47
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
•
•
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
•
•
•
21
42
38
32
38
24
30
0
1
IBM Delhi (Jan. 2006)
2
3
4
5
6
7
8
66
Implementation: SIPpeer
User interface (buddy list, etc.)
On reset Signout,
transfer
On startup
Leave
Discover
Peer found/
Detect NAT
ICE
Signup,
Find buddies
IM,
call
User location
Find
Join
DHT (Chord)
Multicast REGISTER
REGISTER
Audio devices
REGISTER,
INVITE,
MESSAGE
SIP
Codecs
RTP/RTCP
SIP-over-P2P
P2P-using-SIP
IBM Delhi (Jan. 2006)
67
P2P vs. server-based SIP
• Prediction:
– P2P for smaller & quick
setup scenarios
– Server-based for corporate
and carrier
• Need federated system
– multiple p2p systems,
identified by DNS domain
name
– with gateway nodes
2000 requests/second ≈7 million
registered users
IBM Delhi (Jan. 2006)
68
Using P2P for binding updates
• Proxies do more than just plain identifier translation:
– translation may depend on who’s asking, time of day,
…
• e.g., based on script output
• hide full range of contacts from caller
– sequential and parallel forking
– disconnected services: e.g., forward to voicemail if
no answer
• Using a DHT as a location service 
– use only plain translation
Skype approach
– run services on end systems
– run proxy services on supernode(s) and use proxy as
contact  need replication for reliability
IBM Delhi (Jan. 2006)
69
P2P-SIP: Using an External P2P network (DHT)
• Service model
– Join DHT to provide service
• Data model
– Treat DHT as database
[5]
bob
[3]
[2]
bob
192.1.2.3
DHT
[1]
[4]
[3]
[5]
DHT
[1]
Service
node
(128.3.4.5)
alice
[2]
alice
[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
[1]
[2]
[3]
[4]
[5]
join(128.3.4.5)
lookup(H(bob)) gives 128.3.4.5
REGISTER sip:bob to 128.3.4.5
lookup(H(bob)) gives 128.3.4.5
INVITE sip:bob to 128.3.4.5
IBM Delhi (Jan. 2006)
70
P2P-SIP: Logical 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
IBM Delhi (Jan. 2006)
71
P2P-SIP: Implementation in SIPc
• OpenDHT
– Trusted nodes
– Robust
– Fast enough (<1s)
• Identity protection
– Certificate-based
– SIP id == email
• P2P for
Calls, IM, presence,
offline message,
STUN server discovery
and name search
IBM Delhi (Jan. 2006)
72
P2P-SIP: What is OpenDHT?
• Service model, unlike earlier library model of Chord or CAN
– DHT accessed via SunRPC & XML-RPC
– Easy deployment and maintenance
• 200-300 Bamboo DHT nodes on PlanetLab
– Public DHT service running since April 2004
– Many existing applications: i3, CFS, Ostream, HIP,…
• DHT API (server side on Bamboo nodes)
– PUT(key,value,H(secret),ttl) where H() is SHA1
– GET(key)  (value,H(secret),remaining-ttl)
– REMOVE(key,H(value),secret,ttl)
• ReDiR API (client side for lookup/join/leave)
– Can build anycast, multicast, range search using this
• Fair resource (disk) allocation among clients (IP addr)
IBM Delhi (Jan. 2006)
73
Hybrid architecture
• Cross register, or
• Locate during call setup
– DNS, or
– P2P-SIP hierarchy
IBM Delhi (Jan. 2006)
74
Concerns about 3G + NGN
• Complexity
– many signaling hops  server cost, delay
• Assumption of heavy-weight peering
– “lawyer employment act of 2004”
– rather than email-style “all I need is a name” peering
• Coupling of application signaling and network signaling
– incentive to bypass if cost/byte is higher
– makes it more costly to add new QoS-sensitive
applications
• IPTV, remote instrumentation, etc.
– got us tromboning before: mobility issues
IBM Delhi (Jan. 2006)
75
Reliability and scalability
Two stage architecture for CINEMA
a*@example.com
a1
s1
Master
a2
a.example.com
_sip._udp
SRV 0 0 a1.example.com
SRV 1 0 a2.example.com
Slave
sip:[email protected]
s2
sip:[email protected]
b*@example.com
s3
ex
example.com
_sip._udp
SRV 0 40 s1.example.com
SRV 0 40 s2.example.com
SRV 0 20 s3.example.com
SRV 1 0 ex.backup.com
b1
Master
b2
Slave
b.example.com
_sip._udp
SRV 0 0 b1.example.com
SRV 1 0 b2.example.com
Request-rate = f(#stateless, #groups)
Bottleneck: CPU, memory, bandwidth?
Failover latency: ?
IBM Delhi (Jan. 2006)
76
Hybrid architecture
• Cross register, or
• Locate during call setup
– DNS, or
– P2P-SIP hierarchy
IBM Delhi (Jan. 2006)
77
Comparison of P2P and server-based systems
server-based
P2P
scaling
server count 
scales with user count,
but limited by
supernode count
efficiency
most efficient
DHT maintenance =
O((log N)2)
security
trust server provider;
binary
trust most supernodes;
probabilistic
reliability
server redundancy;
catastrophic failure
possible
unreliable supernodes;
catastrophic failure
unlikely
IBM Delhi (Jan. 2006)
78
Open issues
• Presence and IM
– where to store presence information: need access authorization
• Performance
– how many supernodes are needed? (Skype: ~1000)
• Reliability
– P2P nodes generally replicate data
– if proxy or presence agent at leaf, need proxy data replication
• Security
– Sybil attacks: blackholing supernodes
– Identifier protection: protect first registrant against identity theft
– Anonymity, encryption
– Protecting voicemails on storage nodes
• Optimization
– Locality, proximity, media routing
• Deployment
– SIP-P2P vs P2P-SIP, Intra-net, ISP servers
• Motivation
– Why should I run as super-node?
IBM Delhi (Jan. 2006)
79
SIP p2p summary
•
•
•
Advantages
– Out-of-box experience
– Robust
• catastrophic failureunlikely
– Inherently scalable
•
• more with more
nodes
Status
– IETF involvement
– Columbia SIPpeer
Security issues
– Trust, reputation
– malicious node, sybil
attack
– SPAM, DDoS
– Privacy, anonymity (?)
Other issues
– Lookup latency,proximity
– P2P-SIP vs SIP-using-P2P
– Why should I run as supernode?
http://www.p2psip.org and
http://www.cs.columbia.edu/IRT/p2p-sip
IBM Delhi (Jan. 2006)
80
Conclusion
• Peer-to-peer VoIP offers new opportunities
– small, low-maintenance networks
– low overhead
• But Skype success is largely independent of peer-to-peer
approach
– (usually) “just works” – out-of-the-box experience
– voice quality
– low cost to entry (cf. Vonage)
• Standards-based peer-to-peer VoIP
– IETF SIPPEER BOF at next IETF meeting (March)
– different perspectives (large vs. small, etc.)
IBM Delhi (Jan. 2006)
81
References
• Skype reports:
http://www1.cs.columbia.edu/~salman/skype/
• iSAC:
http://www.globalipsound.com/datasheets/iSAC.pdf
• iLBC:
http://www.globalipsound.com/datasheets/iLBC.pdf
IBM Delhi (Jan. 2006)
82