P2P-SIP Peer to peer Internet telephony using SIP

1
P2P-SIPPeer 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

2
Overview

• Introduction
• What is P2P? and SIP? Why P2P-SIP?
• Architecture
• SIP using P2P vs P2P over SIP Components that
  can be P2P
• Implementation
• Choice of P2P (DHT) Node join, leave message
  routing
• Conclusions and future work

Total 33 slides
3
What is P2P?

• Share the resources of individual peers
• CPU, disk, bandwidth, information,

4
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?
• true for proxy
• no need for central server
• true for SIP-based media
• SIP can be e2e
• proxy functions distributed among end systems

5
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)
6
Why P2P-SIP?
REGISTER alice_at_columbia.edu gt128.59.19.194
INVITE alice_at_columbia.edu
Contact 128.59.19.194
Alices host 128.59.19.194
Bobs host
columbia.edu
Client-servergt maintenance, configuration,
controlled infrastructure
7
How to combine SIP P2P?

• P2P-over-SIP
• Additionally, implement P2P using SIP messaging

• SIP-using-P2P
• Replace SIP location service by a P2P protocol

P2P network
REGISTER
INVITE alice
FIND
INSERT
P2P-SIP overlay
Alice 128.59.19.194
INVITE sipalice_at_128.59.19.194
Alice 128.59.19.194
8
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

9
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

10
What else can be P2P?

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

11
Our P2P-SIP approach

• 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 SIPP2P
• Unlike file-sharing applications
• Data storage, caching, delay, reliability
• Disadvantages
• Lookup delay and security

12
Background DHT (Chord)

• 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

Key node
81 9 14
82 10 14
84 12 14
88 16 21
81624 32
83240 42
1
54
8
58
10
14
47
21
42
38
32
38
24
30
13
Design alternatives
servers
1
54
10
38
24
30
clients
Use DHT in server farm
Use DHT for all clients - but some are resource
limited

• Use DHT among super-nodes
• Hierarchy
• Dynamically adapt

14
Architecture of prototype
Signup, Find buddies
IM, call
On reset
Signout, transfer
On startup
Leave
Find
Join
REGISTER, INVITE, MESSAGE
Multicast REGISTER
Peer found/ Detect NAT
REGISTER
SIP-over-P2P
P2P-using-SIP
15
Naming and authentication

• SIP URI as node and user identifiers
• Known node sip15_at_192.2.1.3
• Unknown node sip17_at_example.com
• User sipalice_at_columbia.edu
• User name is chosen randomly by the system, by
  the user, or as users email
• Email the randomly generated password
• TTL, security

16
SIP messages
1

• DHT (Chord) maintenance
• Query the node at distance 2k with node id 11
• REGISTER
• To ltsip11_at_example.invalidgt
• From ltsip7_at_128.59.15.56gt
• SIP/2.0 200 OK
• To ltsip11_at_example.invalidgt
• Contact ltsip15_at_128.59.15.48gt
  predecessorsip10_at_128.59.15.55
• Update my neighbor about me
• REGISTER
• To ltsip1_at_128.59.15.60gt
• Contact ltsip7_at_128.59.15.56gt predecessorsip1_at_1
  28.59.15.60

10
22
7
15
Find(11) gives 15
17
SIP messages

• User registration
• REGISTER
• To sipalice_at_columbia.edu
• Contact sipalice_at_128.59.19.1948094
• Call setup and instant messaging
• INVITE sipbob_at_example.com
• To sipbob_at_example.com
• From sipalice_at_columbia.edu

18
Node startup
columbia.edu

• SIP
• REGISTER with SIP registrar
• DHT
• Discover peers multicast REGISTER
• SLP, bootstrap, host cache
• Join DHT using node-keyHash(ip)
• Query its position in DHT
• Update its neighbors
• Stabilization repeat periodically
• User registers using user-keyHash(alice_at_columbia.
  edu)

REGISTER
alice_at_columbia.edu
Detect peers
REGISTER alice42
58
42
12
14
REGISTER bob12
32
19
Node leaves

• Chord reliability
• Log(N) successors, replicate keys
• 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

REGISTER key42
REGISTER
OPTIONS
DHT
42
42
20
Implementation
31

• sippeer C, Unix (Linux), Chord
• Node join and form the DHT
• Node failure is detected and DHT updated
• Registrations transferred on node shutdown

29
31
25
26
15
21
Adaptor for existing phones

• Use P2P-SIP node as an outbound proxy
• ICE for NAT/firewall traversal
• STUN/TURN server in the node

22
Hybrid (federated) architecture

• Cross register, or
• Locate during call setup
• DNS, or
• P2P-SIP hierarchy

23
Evaluationscalability

• messages depends on
• Keep-alive and finger table refresh rate
• Call arrival distribution
• User registration refresh interval
• Node join, leave, failure rates
• Mrs 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

24
Evaluationreliability 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

25
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
26
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,
• . . .

27
More open issues (further study)

• Security
• Anonymity, encryption
• Attack/DOS-resistant, SPAM-resistant
• Malicious node
• Protecting voicemails from 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?

28
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
29
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
• all servers crash based on client stimulus (e.g.,
  common parser bug)
• Traditional server-based system
• servers share same facility, power, OS,
• P2P system
• less likely
• share same OS?

30
Conclusions

• P2P useful for VoIP
• Scalable, reliable
• No configuration
• Not as fast as client/server
• P2P-SIP
• Basic operations easy
• Implementation
• sippeer C, Linux
• Interoperates
• Some potential issues
• Security
• Performance

http//www.p2psip.org/
http//www.cs.columbia.edu/IRT/p2p-sip