P2P-SIP

Peer to peer Internet telephony using

SIP

Kundan Singh and Henning Schulzrinne

Columbia University, New York
June 2005
http://www.cs.columbia.edu/IRT/p2p-sip

Overview

Introduction

Architecture

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); Node join, leave;

message routing

Conclusions and future work

Total 33 slides

What is P2P?

Computer systems
Centralized

Distributed

mainframes
workstations

Client-server
Flat

Peer-to-peer

Hierarchical Pure

RPC
HTTP

DNS
mount

Share the resources of

individual peers
CPU, disk, bandwidth,
information,
Communication and collaboration
Magi
Groove
Skype

Hybrid

Gnutella
Chord

Napster
Groove

Napster
Gnutella
Kazaa
Freenet
Overnet

Kazaa

C
S

C
C

P
P

File sharing

SETI@Home
folding@Home
Distributed computing

P2P goals

Resource aggregation CPU, disk,

Cost sharing/reduction
Improved
scalability/reliability
Interoperability heterogeneous peers
Increased autonomy at
the network edge
Anonymity/privacy
Dynamic (join, leave),
self organizing
Ad hoc communication
and collaboration

Definition fuzzy

both client and

server?

no need for
central server

true for proxy

true for SIP-based

media
SIP can be e2e

proxy functions
distributed among
end systems
4

Distributed Hash Table

(DHT)

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),
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)

Why P2P-SIP?
REGISTER
alice@columbia.edu =>128.59.19.194

INVITE alice@columbia.edu
Contact: 128.59.19.194

Alices host
128.59.19.194

columbia.edu

Bobs 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

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:alice@128.59.19.194

INVITE alice

REGISTER

P2P-SIP
overlay

Alice
128.59.19.194

Alice
128.59.19.194

SIP-using-P2P

Reuse optimized and well-defined

external P2P network
Define P2P location service
interface to be used in SIP
Extends to other signaling
protocols

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
9

What else can be P2P?

Rendezvous/signaling
Configuration storage
Media storage
Identity assertion (?)
Gateway (?)
NAT/media relay (find best one)

10

Our P2P-SIP approach

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

11

Background: DHT (Chord)

Key

1
54

58

10

14

47
42

21

nod
e

8+1 = 9

14

8+2 =
10

14

8+4 =
12

14

8+8 =
16

21

8+16=2
4

32

8+32=4
0

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

38
32

38
24

30
0

12

Design alternatives
1

54

58

servers

47

42
38
38

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 supernodes

1.
2.

Hierarchy
Dynamically adapt

13

Architecture of prototype
User interface (buddy list, etc.)
Signup,
Find buddies

IM,
call

On resetSignout,
transfer
On startup
User location
Leave
Find

Discover
Peer found/
Detect NAT

ICE

Join

DHT (Chord)

Multicast REGISTER

REGISTER

Audio devices
REGISTER,
INVITE,
MESSAGE

SIP

Codecs
RTP/RTCP

SIP-over-P2P
P2P-using-SIP

14

Naming and
authentication

SIP URI as node and user identifiers

Known node: sip:15@192.2.1.3

Unknown node: sip:17@example.com
User: sip:alice@columbia.edu

User name is chosen randomly by the

system, by the user, or as users email
Email the randomly generated
password

TTL, security
15

SIP messages

DHT (Chord) maintenance

Query the node at distance 2k with node id 11

REGISTER
To: <sip:11@example.invalid>
From: <sip:7@128.59.15.56>

10

22
7

15

Find(11) gives 15
SIP/2.0 200 OK
To: <sip:11@example.invalid>
Contact: <sip:15@128.59.15.48>; predecessor=sip:10@128.59.15.55

Update my neighbor about me

REGISTER
To: <sip:1@128.59.15.60>
Contact: <sip:7@128.59.15.56>; predecessor=sip:1@128.59.15.60

16

SIP messages

User registration
REGISTER
To: sip:alice@columbia.edu
Contact: sip:alice@128.59.19.194:8094

Call setup and instant messaging

INVITE sip:bob@example.com
To: sip:bob@example.com
From: sip:alice@columbia.edu

17

Node startup
columbia.edu
sipd

REGISTER

SIP

DB

alice@columbia.edu

REGISTER with SIP registrar

DHT

Detect peers

Discover peers: multicast

REGISTER

REGISTER alice=42
42

58
12

Join DHT using nodekey=Hash(ip)

14

REGISTER bob=12

SLP, bootstrap, host cache

Query its position in DHT

Update its neighbors
Stabilization: repeat periodically

User registers using userkey=Hash(alice@columbia.edu)

32

18

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

19

Implementation
31
29

31

30
25
26

26

19
15

sippeer: C++,
Unix (Linux),
Chord

11

Node join and

form the DHT
Node failure is
detected and DHT
updated
Registrations
transferred on
node shutdown
20

Adaptor for existing

phones

Use P2P-SIP
node as an
outbound proxy
ICE for
NAT/firewall
traversal

STUN/TURN
server in the
node
21

Hybrid (federated)
architecture

Cross register,
or
Locate during
call setup

DNS, or
P2P-SIP
hierarchy

22

Evaluation
scalability

#messages depends on

Keep-alive and finger table refresh rate

Call arrival distribution
User registration refresh interval
Node join, leave, failure rates

M={rs+ rf(log(N))2} + c.log(N) + (k/t)log(N) + (log(N))2/N

#nodes = f(capacity,rates)

CPU, memory, bandwidth

Verify by measurement and profiling

23

Evaluation

reliability and call setup latency

User availability depends on

Super-node failure distribution

Node keep-alive and finger refresh rate
User registration refresh rate
Replicate user registration
Measure effect of each

Call setup latency

Same as DHT lookup latency: O(log(N))

Calls to known locations (buddies) is direct

DHT optimization can further reduce latency

User availability and retransmission timers

Measure effect of each
24

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

25

Explosive growth (further

study)

Cache replacement at super-nodes

Last seen many days ago

Cap on local disk usage (automatic)

Forcing a node to become super node

Graceful denial of service if overloaded
Switching between flooding, CAN,
Chord,
...
26

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?

27

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

28

Catastrophic failure

Server redundancy is well-understood can

handle single-server failures
Catastrophic (system-wide) failure occurs
when common element fails
Both server-based and P2P:

Traditional server-based system:

all servers crash based on client stimulus (e.g.,

common parser bug)
servers share same facility, power, OS,

P2P system

less likely
share same OS?

29

Conclusions
C

C
S

763
d471f1
d467c4
d46a1c
d462ba

364

123

d4213f

Scalable, reliable
No configuration
Not as fast as client/server

P2P-SIP

Basic operations easy

324

Route(d46a1c)

365
135

P2P useful for VoIP

427

d13da3

65a1fc

564

sippeer: C++, Linux

Interoperates

Some potential issues

http://www.p2psip.org/

Implementation

Security
Performance

http://www.cs.columbia.edu/IRT/p2p-sip

30