P2P-SIP%20Peer%20to%20peer%20Internet%20telephony%20using%20SIP

1
P2P-SIPPeer to peer Internet telephony using SIP

• Kundan Singh and Henning Schulzrinne
• Columbia University, New York
• Dec 15, 2005
• http//www.cs.columbia.edu/IRT/p2p-sip

2
Agenda

• Introduction
• What is P2P? and SIP? Why P2P-SIP?
• Architecture
• Design choices SIP using P2P vs P2P over SIP
  Components that can be P2P
• Implementation
• Choice of P2P (DHT) Naming adaptor SIP message
• Conclusions

3
What is P2P?

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

4
What is SIP? Why P2P-SIP?
(1) REGISTER alice_at_columbia.edu
gt128.59.19.194
(2) INVITE alice_at_columbia.edu
(3) Contact 128.59.19.194
Alices host 128.59.19.194
Bobs host
columbia.edu
Client-servergt maintenance, configuration,
controlled infrastructure
5
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

SIP-using-P2P P2P SIP proxies P2P-over-SIP
Maintenance P2P P2P SIP
Lookup P2P SIP SIP
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
6
Deployment scenarios?
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P2P database
P2P proxies
P2P clients
Zero-conf server farm Trusted servers and user
identities
Global OpenDHT Clients or proxies can
use Trusted peers (?)
Plug and play May use adaptors Untrusted peers
Interoperate among these!
7
What else can be P2P?

• Rendezvous/signaling (SIP)
• Configuration storage
• Media storage (e.g., voice mail)
• Identity assertion (?)
• PSTN gateway (?)
• NAT/media relay (find best one)

Trust models are different for different
components!
8
What is our 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

9
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

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

• Find
• Map key to node
• Join, Leave, or Failure
• Update the immediate neighbors
• Successor and predecessor
• Stabilize eventually propagate the info
• Reliability
• Log(N) successors data replication

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

11
Architecture
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
12
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

13
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
14
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

15
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
16
Adaptor for existing phones

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

17
Hybrid architecture

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

18
Advanced services

• Offline messages
• INVITE or MESSAGE fails responsible node stores
  voicemail, instant message.
• Conferencing
• Three-party, full-mesh, multicast

19
Performance prediction

• Scalability
• messages f(refresh-rate, call arrival,
  join/leave/failure rate)
• Mrs rf(log(N))2 c.log(N) (k/t)log(N)
  ?(log(N))2/N
• User availability
• f(failure, refresh-rate, replication)
• Call setup latency
• f(availability, retransmission timers)
• Known buddies DHT optimizations

20
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?

21
P2P vs server-based
server-based P2P
scaling server count ? scales with user count, but limited by supernode count
efficiency most efficient DHT maintenance O((log N)2), lookup O(logN)
security trust server provider binary trust most supernodes probabilistic
reliability server redundancy catastrophic failure possible unreliable supernodes catastrophic failure unlikely
22
Conclusions

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

http//www.cs.columbia.edu/IRT/p2p-sip
23
Backup slides
24
Server-based vs peer-to-peer
Reliability, failover latency DNS-based. Depends on client retry timeout, DB replication latency, registration refresh interval DHT self organization and periodic registration refresh. Depends on client timeout, registration refresh interval.
Scalability, number of users Depends on number of servers in the two stages. Depends on refresh rate, join/leave rate, uptime
Call setup latency One or two steps. O(log(N)) steps.
Security TLS, digest authentication, S/MIME Additionally needs a reputation system, working around spy nodes
Maintenance, configuration Administrator DNS, database, middle-box Automatic one time bootstrap node addresses
PSTN interoperability Gateways, TRIP, ENUM Interact with server-based infrastructure or co-locate peer node with the gateway
25
Related workP2P

• P2P networks
• Unstructured (Kazaa, Gnutella,)
• Structured (DHT Chord, CAN,)
• Skype and related systems
• Flooding based chat, groove, Magi
• P2P-SIP telephony
• Proprietary NimX, Peerio,
• File sharing SIPShare

26
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
27
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
28
Dialing Out (message routing)

• 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
• Use DHT to locate proxy or redirect to next hop

INVITE key42
Last seen
302
INVITE
DHT
42
29
Find(user)

• Option-2 With REGISTER
• REGISTERs with nodes responsible for its key
• Refreshes periodically
• Allows offline messages (?)

• Option-1 No REGISTER
• Node computes key based on user ID
• Nodes join the overlay based on ID
• One node ? one user

56
REGISTER alice42
58
42
alice42
12
bob12
42
14
12
REGISTER bob12
32
24
24
sam24
30
P2P-SIPSecurity open issues (threats,
solutions, issues)

• More threats than server-based
• Privacy, confidentiality
• Malicious node
• Dont forward all calls, log call history (spy),
• free riding, motivation to become super-node
• Existing solutions
• Focus on file-sharing (non-real time)
• Centralized components (boot-strap, CA)
• Assume co-operating peers (
• works for server farm in DHT
• Collusion
• Hide security algorithm (e.g., yahoo, skype)
• Chord
• Recommendations, design principles,