Peer-to-Peer Internet Telephony using SIP - PowerPoint PPT Presentation

About This Presentation
Title:

Peer-to-Peer Internet Telephony using SIP

Description:

Peer-to-Peer Internet Telephony using SIP Kundan Singh and Henning Schulzrinne Columbia University, New York Sep 10, 2004 Agenda Introduction Client-server vs P2P for ... – PowerPoint PPT presentation

Number of Views:187
Avg rating:3.0/5.0
Slides: 19
Provided by: Kundan
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com