Transcript Document 7351902

P2P-SIP
Peer to peer Internet telephony using SIP
Kundan Singh and Henning Schulzrinne
Columbia University, New York
Dec 15, 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 P2P? and SIP? Why P2P-SIP?
Choice of P2P (DHT); Naming; adaptor; SIP
message
Conclusions
2
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
3
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
Client-server=> maintenance, configuration, controlled infrastructure
(2) INVITE alice
P2P overlay
(3) 128.59.19.194
(1) REGISTER
Alice
128.59.19.194
No central server, search latency
4
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 sip:[email protected]
INVITE alice
REGISTER
P2P-SIP
overlay
Alice
128.59.19.194
Alice
128.59.19.194
5
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 OpenDHT;
Clients or proxies can use;
Trusted peers (?)
Interoperate among these!
6
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!
7
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
8
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
9
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
10
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
11
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
12
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]
13
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]
14
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
15
Adaptor for existing phones


Use P2P-SIP
node as an
outbound proxy
ICE for
NAT/firewall
traversal

STUN/TURN
server in the
node
16
Hybrid architecture


Cross register, or
Locate during call
setup


DNS, or
P2P-SIP hierarchy
17
Advanced services

Offline messages


INVITE or MESSAGE fails: responsible node
stores voicemail, instant message.
Conferencing

Three-party, full-mesh, multicast
18
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
19
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?
20
P2P vs server-based
server-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
21
Conclusions

C
C
P
P
C
P
P
S
C



P
C

763
427
d46a1c
364
123
135
Route(d46a1c)
564
d471f1
d467c4
d462ba
Scalable, reliable
No configuration
Not as fast as client/server
P2P-SIP

d4213f
324
365
P2P useful for VoIP
Basic operations easy

d13da3

65a1fc

Implementation (C++, Linux)
Interoperates
Some potential issues



Security
Robustness
Performance (?)
http://www.cs.columbia.edu/IRT/p2p-sip
22
Backup slides
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
24
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
25
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
26
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
27
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
28
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
29
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, …
30