P2P-SIP Peer to peer Internet telephony using SIP (Session Initiation Protocol)

1
P2P-SIPPeer to peer Internet telephony using SIP
(Session Initiation Protocol)

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

2
Agenda

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

3
What is SIP? 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
4
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
5
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

6
What else can be P2P?

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

7
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

8
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
9
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

10
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
11
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
12
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
13
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
14
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
15
Adaptor for existing phones

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

16
Hybrid architecture

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

17
Advanced services

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

18
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

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

20
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.cs.columbia.edu/IRT/p2p-sip
21
Backup slides
22
What is P2P?

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

23
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

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

26
Distributed Hash Tables

• 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), no
  search()

Properties/types Every peer has complete table Every peer has one key/value
Search time or messages O(1) O(n)
Join/leave messages O(n) O(1)
27
Chord

• Identifier circle
• Keys assigned to successor
• Evenly distributed keys and nodes

1
54
8
58
10
14
47
21
42
38
32
38
24
30
28
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

• Finger table logN
• ith finger points to first node that succeeds n
  by at least 2i-1
• Stabilization after join/leave

42
38
32
38
24
30
29
Comparison
Property/ scheme Un-structured CAN Chord Tapestry Pastry Viceroy
Routing O(N) or no guarantee d x N1/d log(N) logBN logBN log(N)
State Constant 2d log(N) logBN B.logBN log(N)
Join/leave Constant 2d (logN)2 logBN logBN log(N)
Reliability and fault resilience Data at Multiple locations Retry on failure finding popular content is efficient Multiple peers for each data item retry on failure multiple paths to destination Replicate data on consecutive peers retry on failure Replicate data on multiple peers keep multiple paths to each peers Replicate data on multiple peers keep multiple paths to each peers Routing load is evenly distributed among participant lookup servers
30
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
31
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

32
Reliability and scalabilityTwo stage
architecture for CINEMA
a_at_example.com
a.example.com _sip._udp SRV 0 0 a1.example.com
SRV 1 0 a2.example.com
a1
s1
a2
sipbob_at_example.com
s2
sipbob_at_b.example.com
b_at_example.com
b.example.com _sip._udp SRV 0 0 b1.example.com
SRV 1 0 b2.example.com
s3
b1
b2
ex
example.com _sip._udp SRV 0 40 s1.example.com
SRV 0 40 s2.example.com SRV 0 20
s3.example.com SRV 1 0 ex.backup.com
Request-rate f(stateless, groups) Bottleneck
CPU, memory, bandwidth? Failover latency ?
33
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

34
Why we chose Chord?

• Chord can be replaced by another
• As long as it can map to SIP
• High node join/leave rates
• Provable probabilistic guarantees
• Easy to implement
• X proximity based routing
• X security, malicious nodes

35
Related workJXTA vs Chord in P2P-SIP

• JXTA
• Protocol for communication (peers, groups, pipes,
  etc.)
• Stems from unstructured P2P
• P2P-SIP
• Instead of SIP, JXTA can also be used
• Separate search (JXTA) from signaling (SIP)

36
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
37
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,

38
P2P so far
Kademlia protocol eMule MindGem MLDonkey
MANOLITO/MP2P network Blubster Piolet
RockItNet Napster network Napigator OpenNap
WinMX Peercasting type networks PeerCast
IceShare Freecast  WPNP network WinMX other
networks Akamai Alpine ANts P2P Ares Galaxy
Audiogalaxy network Carracho Chord The Circle
Coral5  Dexter Diet-Agents EarthStation 5
network
Evernet FileTopia GNUnet Grapevine Groove
Hotwire iFolder6 konspire2b Madster/Aimster
MUTE Napshare OpenFT Poisoned P-Grid7 IRC
_at_find XDCC JXTA Peersites 8 MojoNation Mnet
Overnet network Scour Scribe Skype
Solipsis SongSpy network Soulseek SPIN
SpinXpress SquidCam 9 Swarmcast WASTE Warez
P2P Winny

• Gnutella network
• Acquisitionx (Mac OS X)
• BearShare
• BetBug
• Cabos
• CocoGnut (RISC OS)
• Gnucleus
• Grokster
• iMesh Light
• gtk-gnutella (Unix)
• LimeWire (Java)
• MLDonkey
• mlMac
• Morpheus
• Phex
• Poisoned
• Swapper
• Shareaza

• Applejuice network
• Applejuice Client
• BitTorrent network
• ABC
• Azureus
• BitAnarch
• BitComet
• BitSpirit
• BitTornado
• BitTorrent
• BitTorrent
• BitTorrent.Net
• G3 Torrent
• mlMac
• MLDonkey
• QTorrent
• SimpleBT
• Shareaza
• TomatoTorrent (Mac OS X)

eDonkey network aMule (Linux) eDonkey client
(no longer supported) eMule LMule MindGem
MLDonkey mlMac Shareaza xMule iMesh Light
ed2k (eDonkey 2000 protocol) eDonkey eMule
xMule aMule Shareaza FastTrack protocol giFT
Grokster iMesh, iMesh Light Kazaa , Kazaa
Lite, K, Diet Kaza, CleanKazaa Mammoth
MLDonkey mlMac Poisoned Freenet network
Entropy Freenet Frost