Peer-to-Peer Internet Telephony using SIP

1
Peer-to-Peer Internet Telephony using SIP

• Kundan Singh and Henning Schulzrinne
• Columbia University, New York
• Sep 10, 2004

2
Agenda

• Introduction
• Client-server vs P2P for VoIP
• Related work Skype
• P2P-SIP architecture
• Design alternatives
• DHT (Chord) and SIP
• Node startup, peer discovery, node failure
• Advanced services
• Offline messages
• Conferencing
• Conclusions and future work

Total 18 slides
3
SIP Session Initiation Protocol
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
4
P2P Advantages

• 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

5
Related work Skype From the KaZaA community

• Host cache of some super nodes
• Bootstrap IP addresses
• Auto-detect NAT/firewall settings
• STUN and TURN
• Protocol among super nodes ??
• Allows searching a user (e.g., kun)
• History of known buddies
• All communication is encrypted
• Promote to super node
• Based on availability, capacity
• Conferencing

6
We propose P2P-SIP

• 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

7
Background DHT (Chord)
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

• 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

42
38
32
38
24
30
8
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

9
Architecture
Signup, Find buddies
IM, call
On reset
Signout, transfer
On startup
Leave
Find
Join
REG, INVITE, MESSAGE
Multicast REG
Peer found/ Detect NAT
REG

• DHT communication using SIP REGISTER
• Known node sip15_at_192.2.1.3
• Unknown node sip17_at_sippeer.net
• User sipalice_at_example.com

10
Node Startup
columbia.edu

• SIP
• REGISTER with SIP registrar
• DHT
• Discover peers multicast REGISTER
• Join DHT using node-keyHash(ip)
• REGISTER with DHT using user-keyHash(alice_at_columb
  ia.edu)

REGISTER
alice_at_columbia.edu
Detect peers
REGISTER alice42
58
42
12
14
REGISTER bob12
32
11
Super-nodes

• Initial bootstrap super-nodes
• Never allow capacity to exceed
• When to become super-node
• Local decision can be influenced by existing
  peer
• If REGISTER received
• Local key gt store locally
• Else, forward REGISTER to appropriate nodes
• Super-node refreshes REGISTER on behalf
• Should be in public address space (?)

REGISTER key42
REGISTER
DHT
42
12
Node Leaves

• 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
13
Dialing Out

• Call, instant message, etc.
• INVITE siphgs10_at_columbia.edu
• MESSAGE sipalice_at_yahoo.com
• If existing buddy, use cache first
• If not found
• SIP-based lookup (DNS NAPTR, SRV,)
• P2P lookup
• Send to super-nodes proxy
• Use DHT to locate proxy or redirect to next hop

INVITE key42
Last seen
302
INVITE
DHT
42
14
Offline messages

• INVITE or MESSAGE fails
• Responsible node stores voicemail, instant
  message.
• Delivered using MWI or when online detected
• Replicate the message at redundant nodes
• Sequence number prevents duplicates
• Security How to avoid spies?
• How to recover if all responsible nodes leave?

15
Conferencing (further study)

• One member becomes mixer
• Centralized conferencing
• What if mixer leaves?
• Fully distributed
• Many to many signaling and media
• Application level multicast
• Small number of senders

16
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,
• . . .

17
More open issues (further study)

• Security
• Anonymity, encryption,
• Attack/DOS-resistant, SPAM-resistant
• Malicious node
• Protecting voicemails from storage nodes
• Optimization
• Locality, proximity
• Motivation
• Why should I run as super-node?

18
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