Transcript No Slide Title

P2P-SIP
Peer to peer Internet telephony using SIP
(Session Initiation Protocol)
Kundan Singh and Henning Schulzrinne
Columbia University, New York
June 2005
http://www.cs.columbia.edu/IRT/p2p-sip
Agenda

Introduction


Architecture


Design choices: SIP using P2P vs P2P over SIP;
Components that can be P2P
Implementation


What is SIP? Why P2P-SIP?
Choice of P2P algorithm (DHT); Node join,
leave; message routing
Conclusions and future work
2
What is SIP? Why P2P-SIP?
REGISTER
[email protected] =>128.59.19.194
INVITE [email protected]
Contact: 128.59.19.194
Alice’s host
128.59.19.194
columbia.edu
Bob’s host
Client-server=> maintenance, configuration, controlled infrastructure
INVITE alice
P2P overlay
128.59.19.194
REGISTER
Alice
128.59.19.194
No central server, search latency
3
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
FIND
INSERT
INVITE sip:[email protected]
INVITE alice
REGISTER
P2P-SIP
overlay
Alice
128.59.19.194
Alice
128.59.19.194
4
P2P-over-SIP





P2P algorithm over SIP without change
in semantics
No dependence on external P2P
network
Reuse and interoperate with existing
components, e.g., voicemail
Built-in NAT/media relays
Message overhead
5
What else can be P2P?






Rendezvous/signaling (SIP)
Configuration storage
Media storage (e.g., voice mail)
Identity assertion (?)
Gateway (?)
NAT/media relay (find best one)
6
What is our P2P-SIP?


Unlike server-based SIP architecture
Unlike proprietary Skype architecture


Robust and efficient lookup using DHT
Interoperability


Hybrid architecture


Lookup in SIP+P2P
Unlike file-sharing applications


DHT algorithm uses SIP communication
Data storage, caching, delay, reliability
Disadvantages

Lookup delay and security
7
Background: DHT (Chord)
1
54
8
58
10
14
47
21
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


Identifier circle
Keys assigned to
successor
Evenly distributed
keys and nodes
Finger table: logN
Find

ith finger points
to first node that
succeeds n by at
least 2i-1


Map key to node
Join, Leave, or Failure
38


32
38


24
Update the immediate neighbors
30
Successor and predecessor
Stabilize: eventually propagate the info
Reliability


Log(N) successors; data replication
8
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
Use DHT among super-nodes
1.
2.
Hierarchy
Dynamically adapt
9
Architecture
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
10
Node Startup
columbia.edu
sipd

REGISTER
SIP

DB

[email protected]
DHT

Detect peers
Discover peers: multicast REGISTER


58

12

14

REGISTER bob=12
SLP, bootstrap, host cache
Join DHT using node-key=Hash(ip)

REGISTER alice=42
42
REGISTER with SIP registrar
Query its position in DHT
Update its neighbors
Stabilization: repeat periodically
User registers using userkey=Hash([email protected])
32
11
Node Leaves

Chord reliability

REGISTER key=42

Graceful leave

REGISTER

42
OPTIONS
DHT

Un-REGISTER
Transfer registrations
Failure

42
Log(N) successors, replicate
keys


Attached nodes detect and
re-REGISTER
New REGISTER goes to new
super-nodes
Super-nodes adjust DHT
accordingly
12
Dialing Out (message routing)

INVITE sip:[email protected]
MESSAGE sip:[email protected]
INVITE key=42
302
Last seen
Call, instant message, etc.

INVITE

If existing buddy, use cache
first
If not found

DHT

SIP-based lookup (DNS
NAPTR, SRV,…)
P2P lookup

Use DHT to locate: proxy or
redirect to next hop
42
13
Implementation
31
29
1

31
30
sippeer: C++,
Unix (Linux), Chord

25
26
26

9

19
11
Node join and form
the DHT
Node failure is
detected and DHT
updated
Registrations
transferred on node
shutdown
15
14
Adaptor for existing phones


Use P2P-SIP
node as an
outbound proxy
ICE for
NAT/firewall
traversal

STUN/TURN
server in the
node
15
Hybrid architecture


Cross register, or
Locate during call
setup


DNS, or
P2P-SIP hierarchy
16
Advanced services

Offline messages


INVITE or MESSAGE fails: responsible node
stores voicemail, instant message.
Conferencing

Three-party, full-mesh, multicast
17
Performance prediction

Scalability

#messages = f(refresh-rate, call arrival,
join/leave/failure rate)
M={rs+ rf(log(N))2} + c.log(N) + (k/t)log(N) + (log(N))2/N

User availability


f(failure, refresh-rate, replication)
Call setup latency


f(availability, retransmission timers)
Known buddies; DHT optimizations
18
More open issues (further study)

Security





Optimization


Locality, proximity, media routing
Deployment


Anonymity, encryption,
Attack/DOS-resistant, SPAM-resistant
Malicious node
Protecting voicemails from storage nodes
SIP-P2P vs P2P-SIP, Intra-net, ISP servers
Motivation

Why should I run as super-node?
19
Conclusions
C
C
S
C
C
P
P
P
P

763
d46a1c
364
Route(d46a1c)
365
d471f1
d467c4
d462ba
d4213f
324
135

P
123
P2P useful for VoIP

C
427


Scalable, reliable
No configuration
Not as fast as client/server
P2P-SIP

Basic operations easy

d13da3
65a1fc
Implementation

564


sippeer: C++, Linux
Interoperates
Some potential issues


Security
Performance (?)
http://www.cs.columbia.edu/IRT/p2p-sip
20
Backup slides
What is P2P?
Computer systems
Centralized

Distributed

mainframes
workstations
Client-server
Flat
Hierarchical
RPC
HTTP
DNS
mount
Share the resources of
individual peers
Peer-to-peer
Pure
Hybrid
Gnutella
Chord
Napster
Groove
CPU, disk, bandwidth,
information, …
Communication and collaboration
Magi
Groove
Skype
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
22
Naming and authentication

SIP URI as node and user identifiers





Known node: sip:[email protected]
Unknown node: sip:[email protected]
User: sip:[email protected]
User name is chosen randomly by the
system, by the user, or as user’s email
Email the randomly generated password

TTL, security
23
SIP messages

1
DHT (Chord) maintenance

Query the node at distance 2k with node id 11
REGISTER
To: <sip:[email protected]>
From: <sip:[email protected]>
10
22
7
15
Find(11) gives 15
SIP/2.0 200 OK
To: <sip:[email protected]>
Contact: <sip:[email protected]>; predecessor=sip:[email protected]

Update my neighbor about me
REGISTER
To: <sip:[email protected]>
Contact: <sip:[email protected]>; predecessor=sip:[email protected]
24
SIP messages

User registration
REGISTER
To: sip:[email protected]
Contact: sip:[email protected]:8094

Call setup and instant messaging
INVITE sip:[email protected]
To: sip:[email protected]
From: sip:[email protected]
25
Distributed Hash Tables

Types of search




Central index (Napster)
Distributed index with flooding (Gnutella)
Distributed index with hashing (Chord)
Basic operations
find(key), insert(key, value), delete(key), no search(*)
Properties/types
Every peer has
complete table
Every peer has one
key/value
Search time or
messages
O(1)
O(n)
Join/leave messages O(n)
O(1)
26
Chord

1
54
8
58

10
14

47
21
42
Identifier circle
Keys assigned to
successor
Evenly
distributed keys
and nodes
38
32
38
24
30
0
1
2
3
4
5
6
7 27 8
Chord
1
54
8
58
10
14
47
21

42

38
32
38

24
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
Finger table: logN
ith finger points to first node that
succeeds n by at least 2i-1
Stabilization after join/leave
30
28
Comparison
Property/
scheme
Unstructured
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
Routing load
is evenly
distributed
among
participant
lookup
servers
29
Server-based vs peer-to-peer
Reliability,
failover latency
DNS-based. Depends on client
retry timeout, DB replication
latency, registration refresh
interval
DHT self organization and
periodic registration refresh.
Depends on client timeout,
registration refresh interval.
Scalability,
number of users
Depends on number of servers
in the two stages.
Depends on refresh rate,
join/leave rate, uptime
Call setup
latency
One or two steps.
O(log(N)) steps.
Security
TLS, digest authentication,
S/MIME
Additionally needs a reputation
system, working around spy nodes
Maintenance,
configuration
Administrator: DNS, database,
middle-box
Automatic: one time bootstrap
node addresses
PSTN
interoperability
Gateways, TRIP, ENUM
Interact with server-based
infrastructure or co-locate peer node
with the gateway
30
Related work: Skype
From the KaZaA community
P
P
P

P
P
P
P

P

P
Host cache of some super nodes
Bootstrap IP addresses
Auto-detect NAT/firewall settings

P
P
P





Protocol among super nodes – ??
Allows searching a user (e.g., kun*)
History of known buddies
All communication is encrypted
Promote to super node


STUN and TURN
Based on availability, capacity
Conferencing
31
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?
32
Failover latency: ?
Related work
P2P

P2P networks



Skype and related systems


Unstructured (Kazaa, Gnutella,…)
Structured (DHT: Chord, CAN,…)
Flooding based chat, groove, Magi
P2P-SIP telephony


Proprietary: NimX, Peerio,
File sharing: SIPShare
33
Why we chose Chord?

Chord can be replaced by another






As long as it can map to SIP
High node join/leave rates
Provable probabilistic guarantees
Easy to implement
X proximity based routing
X security, malicious nodes
34
Related work
JXTA vs Chord in P2P-SIP

JXTA



Protocol for communication (peers, groups,
pipes, etc.)
Stems from unstructured P2P
P2P-SIP

Instead of SIP, JXTA can also be used

Separate search (JXTA) from signaling (SIP)
35
Find(user)

Option-1: No REGISTER




Node computes key based on
user ID
Nodes join the overlay based on
ID
One node  one user
Option-2: With REGISTER



REGISTERs with nodes
responsible for its key
Refreshes periodically
Allows offline messages (?)
56
42
alice=42
42
12
REGISTER alice=42
58
12
bob=12
14
REGISTER bob=12
32
24
sam=24
24
36
P2P-SIP
Security – open issues (threats, solutions, issues)

More threats than server-based


Privacy, confidentiality
Malicious node



“free riding”, motivation to become super-node
Existing solutions



Focus on file-sharing (non-real time)
Centralized components (boot-strap, CA)
Assume co-operating peers (




Don’t forward all calls, log call history (spy),…
works for server farm in DHT
Collusion
Hide security algorithm (e.g., yahoo, skype)
Chord

Recommendations, design principles, …
37
P2P so far…
Kademlia protocol
eMule
Applejuice Client
Acquisitionx (Mac OS X)
MindGem
aMule
(Linux)
BitTorrent network
BearShare
eDonkey client (no longer
MLDonkey
ABC
BetBug
supported)
Azureus
MANOLITO/MP2P
network
Cabos
eMule
BitAnarch
Blubster
CocoGnut (RISC OS)
BitComet
LMule
Piolet
Gnucleus
BitSpirit
MindGem
Grokster
RockItNet
BitTornado
MLDonkey
iMesh Light
Napster network
BitTorrent
mlMac
gtk-gnutella (Unix)
Napigator
BitTorrent++
Shareaza
LimeWire (Java)
OpenNap
BitTorrent.Net
MLDonkey
xMule
WinMX
G3 Torrent
mlMac
iMesh Light
Peercasting
type networks
mlMac
Morpheus
ed2k
(eDonkey
2000
protocol)
MLDonkey
PeerCast
Phex
eDonkey
QTorrent
IceShare
Poisoned
eMule
SimpleBT
Freecast
Swapper
xMule
Shareaza
Shareaza
WPNP network
aMule
TomatoTorrent (Mac OS X)
XoloX
WinMX
Shareaza
TorrentStorm
Gnutella2
network
other
networks
FastTrack protocol
CAKE network
Adagio
Akamai
giFT
BirthdayCAKE
Caribou
Grokster
Alpine
Direct Connect network
Gnucleus
iMesh, iMesh Light
ANts P2P
BCDC++
iMesh Light
Kazaa , Kazaa Lite, K++, Diet
Ares Galaxy
CZDC++
MLDonkey
Kaza, CleanKazaa
Audiogalaxy network
DC++
mlMac
Mammoth
NeoModus Direct Connect
Carracho
Morpheus
MLDonkey
JavaDC
Chord
Shareaza
mlMac
DCGUI-QT
TrustyFiles
The Circle
Poisoned
HyperCast
Coral[5]
Freenet network
Joltid PeerEnabler
Entropy
Dexter
Freenet
Altnet
Diet-Agents
Frost
Bullguard
EarthStation 5 network
Applejuice network
eDonkey network
Gnutella network
Joltid
Kazaa, Kazaa Lite
Evernet
FileTopia
GNUnet
Grapevine
Groove
Hotwire
iFolder[6]
konspire2b
Madster/Aimster
MUTE
Napshare
OpenFT
Poisoned
P-Grid[7]
IRC @find XDCC
JXTA
Peersites [8]
MojoNation
Mnet
Overnet network
Scour
Scribe
Skype
Solipsis
SongSpy network
Soulseek
SPIN
SpinXpress
SquidCam [9]
Swarmcast
WASTE
Warez P2P 38
Winny