1. P2P-SIP Peer to peer Internet telephony using SIP
Kundan Singh and Henning Schulzrinne
Columbia University, New York
June 2005

2. Overview Introduction Architecture Implementation
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, …
Computer systems
Centralized
Distributed
Client-server
Peer-to-peer
Flat
Hierarchical
Pure
Hybrid
mainframes
workstations
DNS
mount
RPC
HTTP
Gnutella
Chord
Napster
Groove
Kazaa
File sharing
Communication and collaboration
Distributed computing
Napster
Gnutella
Kazaa
Freenet
Overnet
Magi
Groove
Skype
Another category in the system is the infrastructure component, which defines what routing mechanism to use: Chord, CAN, etc.
What are Groove and Magi?
Groove: P2P system for office collaboration. Not clear how the user is detected, perhaps statically added by peers. Every peer in the group sees the same user space. Synchronized across all peers. All communications are signed. Proprietary.
Magi: goal was to make it standards based such as HTTP, XML, WebDAV to provide document sharing and communication mechanism on the Internet. It uses dynamic DNS to register the Magi nodes/instances. All communications are signed. C S P

4. P2P goals Definition fuzzy both client and server?
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(log(N)2)

6. Why P2P-SIP? P2P overlay Alice’s host 128.59.19.194 Bob’s host Alice
REGISTER
=>
INVITE
Contact:
Alice’s host
Bob’s host
columbia.edu
Client-server=> maintenance, configuration, controlled infrastructure
P2P overlay
Alice
REGISTER
INVITE alice
No central server, search latency
What we gain: Reliability, scalability.
What we lose: bounds on INVITE. Search feature.

7. How to combine SIP + P2P? P2P-over-SIP SIP-using-P2P
Additionally, implement P2P using SIP messaging
SIP-using-P2P
Replace SIP location service by a P2P protocol
P2P network
REGISTER
FIND
INVITE alice
INSERT
P2P-SIP
overlay
Alice
INVITE
Alice

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., voic
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 SIP+P2P
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
8+1 = 9 14
8+2 = 10
8+4 = 12
8+8 = 16 21
8+16=24 32
8+32=40 42 1 54 8 58 10 14 47 21
Lookup in finger table for the furthest node that precedes the key
In a system with N nodes and K keys, with high probability,
each node receives at most K/N keys
each node maintains information about O(logN) other nodes
lookups resolved with O(logN) hops
No network locality.
Replicas need to have explicit consistency.
Optimizations:
location: weight neighbor nodes by RTT.
When routing choose the neighbor who is closer to destination with lowest RTT from me.
Reduce path latency.
Multiple physical nodes per virtual node.
What if a node leaves? 42 38 32 38 24 30

13. Design alternatives Use DHT in server farm1 8 14 21 32 38 58 47 10 24 30 54 42
65a1fc
d13da3
d4213f
d462ba
d467c4
d471f1
d46a1c
Route(d46a1c)
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
User interface (buddy list, etc.)
Signup,
Find buddies
IM,
call
On reset
Signout,
transfer
On startup
User location
Leave
Find
Discover
Join
Audio devices
DHT (Chord)
REGISTER,
INVITE,
MESSAGE
Codecs
Peer found/
Detect NAT
Multicast REGISTER
REGISTER
ICE
SIP
RTP/RTCP
SIP-over-P2P
P2P-using-SIP

15. Naming and authentication
SIP URI as node and user identifiers
Known node:
Unknown node:
User:
User name is chosen randomly by the system, by the user, or as user’s
the randomly generated password
TTL, security

16. SIP messages DHT (Chord) maintenance1
DHT (Chord) maintenance
Query the node at distance 2k with node id 11
REGISTER
To:
From:
SIP/ OK
Contact:
Update my neighbor about me
To:
Contact: 10 22 7 15
Find(11) gives 15

17. SIP messages User registration Call setup and instant messaging
REGISTER
To:
Contact:
Call setup and instant messaging
INVITE
To:
From:

18. Node startup SIP DHT REGISTER with SIP registrar
columbia.edu DB
sipd
SIP
REGISTER with SIP registrar
DHT
Discover peers: multicast REGISTER
SLP, bootstrap, host cache
Join DHT using node-key=Hash(ip)
Query its position in DHT
Update its neighbors
Stabilization: repeat periodically
User registers using
REGISTER
Detect peers
REGISTER alice=42 42 58 12 14
REGISTER bob=12 32

19. Node leaves Chord reliability Graceful leave Failure
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 key=42
REGISTER
DHT
OPTIONS 42 42

20. Implementation sippeer: C++, Unix (Linux), Chord31
sippeer: C++, Unix (Linux), Chord
Node join and form the DHT
Node failure is detected and DHT updated
Registrations transferred on node shutdown 29 1 31 30 25 26 26 9 19 11 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. 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

24. 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
Advanced services also possible.
the ConChord system for
certificate storage, the Tarzan system for anonymous communications, and
the proposal to use Chord as replacement of standard DNS hierarchies by
Cox, Muthitacharoen, and Morris -- this last proposal is most similar in
spirit to your work

25. P2P vs. server-based SIP Prediction: Need federated system
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 voic s 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
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 P2P-SIP 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 C S P
427
763
135
365
123
324
564
364
65a1fc
d13da3
d4213f
d462ba
d467c4
d471f1
d46a1c
Route(d46a1c)