Peer-to-peer VoIP
Kundan Singh, Salman Baset and Henning SchulzrinneInternet Real Time Laboratory
Computer Science Dept., Columbia University, New York
http://www.cs.columbia.edu/IRT/p2p-siphttp://www.cs.columbia.edu/IRT/dotslash
IBM Delhi (Jan. 2006) 2
Overview• P2P – definition and motivation• Analysis of Skype• SIP-based peer-to-peer• Using existing overlays for peer-to-peer-VoIP
IBM Delhi (Jan. 2006) 3
P2P for autonomic computing• Autonomic at the application layer:
– Robust against partial network faults– Resources grow as user population grows– Self-configuring
• Traditional p2p systems– file storage
• motivation is often legal, not technical, efficiency– usually unstructured, optimized for Zipf-like popularity
• Other p2p applications:– Skype demonstrates usefulness for VoIP
• identifier lookup• NAT traversal: media traversal
– OpenDHT (and similar) as emerging common infrastructure?– Non-DHT systems with smaller scope web hotspot rescue– Network management (see our IRTF slides)
IBM Delhi (Jan. 2006) 4
Aside: middle services instead of middleware
• Common & successful network services– identifier lookup: ARP, DNS– network storage: proprietary (Yahoo, .mac, …)– storage + computation: CDNs
• Emerging network services– peer-to-peer identifier lookup– network storage– network computation (“utility”)
• maybe programmable• already found as web hosts and grid
computing
IBM Delhi (Jan. 2006) 5
What is P2P?
• Share the resources of individual peers– CPU, disk, bandwidth,
information, …
C
C
C
C
C
SP
P
P
P
P
Computer systems
Centralized Distributed
Client-server Peer-to-peer
Flat Hierarchical Pure Hybrid
mainframesworkstations
DNSmount
RPCHTTP
GnutellaChord
NapsterGroove
Kazaa
File sharing
Communication and collaboration
Distributed computing
SETI@Homefolding@Home
NapsterGnutellaKazaaFreenetOvernet
MagiGrooveSkype
IBM Delhi (Jan. 2006) 6
Overview - Skype• What is Skype?• What problems does it solve?• The Skype network• The Skype software components• Experimental setup• The Skype functions• How to block Skype?• Skype, MSN, and Yahoo• Disassembling the executable• Unanswered questions
IBM Delhi (Jan. 2006) 7
What is Skype?• Peer-to-peer, pc-to-pc, pc-to-phone, phone-
to-pc VoIP client• Developed by people who created KaZaa• First version in September 2003• 60,000 downloads in first week, 219 million
downloads (till yesterday) • Current version: 1.4.0.84 and 2.0 beta• SkypeOut (pc-to-phone) introduced in July
2004– SkypeOut terms of service: governed by
the laws of Luxembourg• SkypeIn, voicemail• OS: Windows, Linux, MacOS, PocketPC
IBM Delhi (Jan. 2006) 8
What problems does it solve?• NAT and firewall traversal
– Nielsen September 2005 ratings•61.3% of US home internet users use
broadband(http://www.nielsen-netratings.com/pr/pr_050928.pdf)
•‘Most’ users have some kind of NAT– approximately 50% (MSDN)
• NATs come in many different flavors– most allow some “funneling”
• Superior voice quality compared to MSN or Yahoo IM clients
• Phone-to-PC calling, SkypeIn– Yahoo is starting to imitate Skype
services
IBM Delhi (Jan. 2006) 9
A p2p illusion?
• Login server• Servers for SkypeOut and SkypeIn• Anonymous call minutes statistic
gathering
IBM Delhi (Jan. 2006) 10
The Skype Network
IBM Delhi (Jan. 2006) 11
The Skype Network (contd…)
• Ordinary host (OH)– A Skype client
• Super nodes (SN)– A Skype client– Has public IP address, ‘sufficient’ bandwidth,
CPU and memory• Login server
– Stores Skype id’s and passwords– Used at login for authentication– Version 0.97: 80.160.91.11
now: 212.72.49.141 and 195.215.8.141
IBM Delhi (Jan. 2006) 12
Skype Components• Ports
– No default listening port– Randomly chooses a port (P1) on installation– Opens TCP, UDP listener sockets at P1– TCP listener sockets at port 80, 443
IBM Delhi (Jan. 2006) 13
Skype Components (contd…)
• Host cache (HC)– IP address and port number of online Skype
nodes (SNs)– At least one valid entry must be present in
HC– Maximum size: 200 entries– ‘Understanding KaZaa’: 200 entries for
ordinary node (ON)– Login server IP address and port number– Stored in Windows registry in version 0.97– Now present at
C:\Documents and Settings\All Users\Application Data\Skype
IBM Delhi (Jan. 2006) 14
Skype HC (ver: 0.97)
IBM Delhi (Jan. 2006) 15
Skype HC
IBM Delhi (Jan. 2006) 16
Skype Components (Contd…)• Codecs (GlobalIPSound)
– Wide band codecs (50-8,000 Hz)– iLBC (packet size: 20 and 30 ms bitrate: 15.2 kbps and 13.3
kbps)– iSAC (packet size: 30-60 ms bitrate: 10-32 kbps)– G.729 for SkypeOut?
• Buddy list– Stored in ‘config.xml’ file
• C:\Documents and Settings\<XP user>\Application Data\Skype\<skype user id>
<CentralStorage> <LastBackoff>0</LastBackoff> <LastFailure>0</LastFailure> <LastSync>1120325519</LastSync> <NeedSync>0</NeedSync> <SyncSet> <u> <skypebuddy1>f384d3a0:1</skypebuddy1> <skypebuddy2>7d1dafc4:1</skypebuddy2>
IBM Delhi (Jan. 2006) 17
Experimental Setup• We have NOT reverse engineered Skype
executable but it can be done• Skype version: 0.97.0.6, 1.0, 1.2, 1.4• Experiments performed between Feb-May
2004, June-July and Nov-Dec 2005.• Tools Used
– Ethereal (for packet capture)– NetPeeker (for tuning the bw)– NCH Tone generator
(for generating tones of various frequencies)
– APIMonitor (for monitoring the sys calls)
IBM Delhi (Jan. 2006) 18
Experimental Setup (Contd…)
INTERNET
A (public IP) B (public IP)
INTERNET
A (private IP) B (public IP)port-restricted NAT
INTERNET
A (private IP address) B (private IP address)port-restricted NAT
UDP-blocking firewallport-restricted NAT
UDP-blocking firewall
IBM Delhi (Jan. 2006) 19
Skype Functions
•Startup•Login•User Search•Call Establishment•Media Transfer•Keep-Alive•NAT and firewall Traversal•Conferencing
IBM Delhi (Jan. 2006) 20
Skype Functions: STARTUP• First time startup
– GET /ui/0/97/en/installed HTTP/1.1
• Normal startup– GET /ui/0/97/en/getlatestversion?ver=0.97.0.6
HTTP/1.1
IBM Delhi (Jan. 2006) 21
Skype Functions: LOGIN• Must establish a TCP connection with
SN• HC must contain at least one valid SN• Bootstrap Super Nodes
IP address:port Reverse Lookup Result Authority Section
66.235.180.9:33033 sss1.skype.net ns1.hopone.net
66.235.181.9:33033 No PTR result ns1.hopone.net
212.72.49.143:33033 No PTR result ns-pri.ripe.net
195.215.8.145:33033 No PTR result ns3.DK.net
64.246.49.60:33033 rs-64-246-49-60.ev1.net ns2.ev1.net
64.246.49.61:33033 rs-64-246-49-61.ev1.net ns2.ev1.net
64.246.48.23:33033 ev1s-64-246-48-23.ev1servers.net ns1.ev1.net
IBM Delhi (Jan. 2006) 22
Skype Functions: LOGIN• Public, NAT
– Establish a TCP connection with the SN
– Authenticate with the login server– Announce arrival on the network
(controlled? flooding)– Determine NAT type?
• Firewall
– Establish a TCP connection with the SN
– Authenticate with the login server
IBM Delhi (Jan. 2006) 23
Skype Functions: LOGIN
UDPUDP
66.235.180.9:33033 (Bootstrap node)31B61B
TCPTCP
SN: (IP address not shown for privacy reasons )
94B1514B
TCPTCP
5B (1)5B (2)
TCPTCP
401B (3)218B (4)
TCP: SYN212.72.49.141:33033 (login server )
SC
SC
SC
TCP:ACK16 3 1 0 0
17 3 1 0 0
16 3 1 0 0 . . . .
17 3 1 0 0 len . . . .
IBM Delhi (Jan. 2006) 24
Skype Functions: LOGIN• 1536 and 2048 (skype account) bit RSA to
negotiate symmetric AES keys• Central Server Signing Key SS and Verification Key
VS• Client: user name A, password PA, RSA key pair SA
and VA• VS embedded in the Skype executable• 256 bit AES session with the login server• Key is chosen at random and encrypted with the
public key of the login server• {A, H(PA), VA} VS to login server (msg 3)• {A, VA} SS to client (msg 4)
• Source: Tom Berson’s security evaluation
IBM Delhi (Jan. 2006) 25
Skype Functions: LOGIN
Send UDP packets to seven bootstrap SNs at
port 33033
Response within 5 seconds
TCP connection attempts with seven bootstrap SN IP addresses and 1) port 330332) port 80 (HTTP port)3) port 443 (HTTPS port)
Yes/No
Connected
Success
Yes
No
Start
Wait for 22 seconds
IBM Delhi (Jan. 2006) 26
Skype Functions: Login
Public NAT Firewall
Data Exchanged
9 kilobytes 10 kilobytes 8.5 kilobytes
Time to login
3-7 seconds 3-7 seconds 30-35 seconds
IBM Delhi (Jan. 2006) 27
Skype Functions: USER SEARCH• From the Skype website
– Global Index (GI) Technology– Guaranteed to find a user it exists and
logged in the last 72 hours• Search results are cached at intermediate nodes• Unable to trace messages beyond SN• Cannot force a node to become a SN
– Host cache is used for connection establishment and not for SN selection
• User does not exist. How does search terminate?• SN searches for a user behind UDP-restricted
firewall • Same search query from two different machines
initiated at the same time give different results• Wildcard queries supported
IBM Delhi (Jan. 2006) 28
Skype Functions: USER SEARCH
Public NAT Firewall
Data Exchanged
1-2 kilobytes 1-2 kilobytes 2-4 kilobytes
IBM Delhi (Jan. 2006) 29
Call Establishment• Call signaling always carried over TCP• Calls to non buddies=search+call• Initial exchange checks for blocked users• Public-public call
– Caller SC establishes a TCP connection with callee SC• Public-NAT
– Caller SC is behind NAT– Caller---->Skype node (SN?) ----> Callee– TCP connection established between caller, callee, and
more than one Skype nodes– Unknown: How a node is selected to route calls from
caller to callee?• Perhaps determined at login
• Firewall-firewall call– Same as public-NAT
IBM Delhi (Jan. 2006) 30
Call Establishment
Public-public Public-NAT Firewall-Firewall
Data Exchanged
4-5 kilobytes 6-8 kilobytes 6-7 kilobytes
IBM Delhi (Jan. 2006) 31
Skype Functions: Media Transfer
Public-Public Public-NAT Firewall-firewall
Packet Size 67 bytes 67 bytes 69 bytes
Stream BW 5 kilobytes/s 5 kilobytes/s 5 kilobytes/s
Transport UDP UDP TCP
• 10/100 Mbps Ethernet
IBM Delhi (Jan. 2006) 32
Skype Functions: MEDIA TRANSFER• No silence suppression• Silence packets are used to
– play background noise at the peer– maintain UDP NAT binding– avoid drop in the TCP congestion window
• Putting a call on hold– 3 packets/sec to call-peer or Skype node– same reasons as above
• Codec frequency range– 50-8,000 Hz (total bw of 3 kilobytes/s)
• Reasonable call quality at (4 kilobytes/s)
IBM Delhi (Jan. 2006) 33
Skype Functions: Keep Alive• Refresh message over TCP to SN every 60 seconds• Refresh message size: 60 bytes
IBM Delhi (Jan. 2006) 34
Skype Functions: Conferencing
A: Pentium4, 2GHz
B: PentiumII , 300 MHz
C: Pentium Pro 200 MHz
• A, B, and C have public IP addresses
1: B-A Call
IBM Delhi (Jan. 2006) 35
Skype Functions: Conferencing
A: Pentium4, 2GHz
B: PentiumII , 300 MHz
C: Pentium Pro 200 MHz
• A, B, and C have public IP addresses
1: B-A Call
2: B-C Call
IBM Delhi (Jan. 2006) 36
Skype Functions: Conferencing
A: Pentium4, 2GHz
B: PentiumII , 300 MHz
C: Pentium Pro 200 MHz
• A, B, and C have public IP addresses
1: B-A Call
2: B-C Call
B decides to initiate a conference
IBM Delhi (Jan. 2006) 37
Skype Functions: Conferencing
A: Pentium4, 2GHz
B: PentiumII , 300 MHz
C: Pentium Pro 200 MHz
• A, B, and C have public IP addresses
B
C A+B
A+C
IBM Delhi (Jan. 2006) 38
Skype Functions: Conferencing
A: Pentium4, 2GHz
B: PentiumII , 300 MHz
C: Pentium Pro 200 MHz
• B and C are behind NAT. A has public IP addresses
1: B-A Call
B
A
BA
Online Skype node
IBM Delhi (Jan. 2006) 39
Skype Functions: Conferencing
A: Pentium4, 2GHz (public IP)
B: PentiumII , 300 MHz
(NAT) C: Pentium Pro 200 MHz
(NAT)
• B and C are behind NAT. A has public IP addresses
B
A+C
Online Skype node
A+BC
IBM Delhi (Jan. 2006) 40
How to block Skype?• Block IP address and port of Skype login servers.• Skype goes through super nodes.• Inspect TCP payload of login messages and block
outgoing login messages.• Skype is blocked.
IBM Delhi (Jan. 2006) 41
Skype, MSN, and Yahoo
Application version
Memory usage before call
(caller, callee)
Memory usage after call (caller,
callee)
Process priority
before call
Process priority
during call
Mouth-to-ear latency
Skype 1.217 KB, 10 KB 18 KB, 19 KB Normal High 90ms~
MSN 6.2 20 KB, 19 KB 25 KB, 25 KB Normal Normal 95ms~, 130ms~
Yahoo 7.0 beta 33 KB, 33 KB 38 KB, 29 KB Normal Normal 190ms~
IBM Delhi (Jan. 2006) 42
Call / IM Forking• User can login from multiple machines• All Skype instances notified of call arrival• Pickup, cancel at other locations• IMs delivered to all locations
IBM Delhi (Jan. 2006) 43
Skype Online Users
Skype Online Users vs Time (Nov 24, 2004)
0200,000400,000600,000800,000
1,000,0001,200,0001,400,000
Time
Onl
ine
Use
rs
IBM Delhi (Jan. 2006) 44
Breaking the executable• Skype does not run with ltrace• Skype does run with strace• nm does not reveal anything• libcrypt is (perhaps) statically linked. ldd does not
reveal anything• Skype can be run with SoftICE, OllyDbg• LD_PRELOAD technique
IBM Delhi (Jan. 2006) 45
Unanswered questions• How Skype encrypts and decrypts?• SN to SN communication?• One hop or multiple hop media relaying?• How does search terminate if the user is not found?
IBM Delhi (Jan. 2006) 46
Skype: Conclusions• Login server and super nodes, not strictly peer-to-
peer• Code obfuscation, runtime decryption• Multiple paths for ‘in-time’ switching incase of
failures• Other companies are following Skype
– damaka, peerio, pc-telephone
IBM Delhi (Jan. 2006) 47
Back to SIP-based peer-to-peer VoIP• Distributed hash tables• Functions for peer-to-peer
– call routing, presence, …• Using SIP to build a DHT• Using OpenDHT as an infrastructure
IBM Delhi (Jan. 2006) 48
Distributed Hash Table (DHT)• Types of search
– Central index (Napster)– Distributed index with flooding (Gnutella)– Distributed index with hashing (Chord, Bamboo, …)
• Basic operationsfind(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(n) O(log(N)2) O(1)
IBM Delhi (Jan. 2006) 49
CANContent Addressable Network
• Each key maps to one point in the d-dimensional space
• Each node responsible for all the keys in its zone.
• Divide the space into zones.
A B
C D E
0.0 1.00.0
1.0
A B
C D E
IBM Delhi (Jan. 2006) 50
CAN
AE
X CB
D
(x,y)
AE
X CB
D
Z
Node X locates (x,y)=(.3,.1)Node Z joins
State = 2d Search = dxn1/d
0.0 .25 .5 .75 1.0
1.0
.75
.5
.25
0.0
IBM Delhi (Jan. 2006) 51
Chord• Identifier circle• Keys assigned to
successor• Evenly distributed
keys and nodes
1
8
14
21
32
38
58
47
10
2430
54
38
42
0 1 2 3 4 5 6 7 8
IBM Delhi (Jan. 2006) 52
Chord
• Finger table: logN
• ith finger points to first node that succeeds n by at least 2i-1
• Stabilization after join/leave
1
8
14
21
32
38
58
47
10
2430
54
38
42
Key node
8+1 = 9 14
8+2 = 10 14
8+4 = 12 14
8+8 = 16 21
8+16=24 32
8+32=40 42
IBM Delhi (Jan. 2006) 53
Tapestry• ID with base B=2b
• Route to numerically closest node to the given key
• Routing table has O(B) columns. One per digit in node ID
• Similar to CIDR – but suffix-based
427 763
135
365
123
324
564
364
N=2 N=1 N=0
064 ?04 ??0
164 ?14 ??1
264 ?24 ??2
364 ?34 ??3
464 ?44 ??4
564 ?54 ??5
664 ?64 ??6
**4 => *64 => 364
IBM Delhi (Jan. 2006) 54
Pastry
• Prefix-based• Route to node with shared
prefix (with the key) of ID at least one digit more than this node
• Neighbor set, leaf set and routing table
65a1fc
d13da3
d4213f
d462bad467c4
d471f1
d46a1c
Route(d46a1c)
IBM Delhi (Jan. 2006) 55
Other schemes• Distributed TRIE• Viceroy• Kademlia• SkipGraph• Symphony• …
IBM Delhi (Jan. 2006) 56
DHT 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
Routing load is evenly distributed among participant lookup servers
IBM Delhi (Jan. 2006) 57
The basic SIP service • HTTP: retrieve resource identified by URI• SIP: translate address-of-record SIP URI
(sip:[email protected]) to one or more contacts (hosts or other AORs, e.g., sip:[email protected])
– single user multiple hosts• e.g., home, office, mobile, secretary• can be equal or ordered sequentially
• Thus, SIP is (also) a binding protocol– similar, in spirit, to mobile IP except application
layer and without some of the related issues• Function performed by SIP proxy for AOR’s domain
– delegated logically to location server• This function is being replaced by p2p approaches
IBM Delhi (Jan. 2006) 58
What is SIP? Why P2P-SIP?
Bob’s hostAlice’s host128.59.19.194
(1) REGISTER [email protected] =>128.59.19.194
(2) INVITE [email protected]
(3) Contact: 128.59.19.194
columbia.edu
Problem in client-server: maintenance, configuration, controlled infrastructure
Peer-to-peer network
Alice128.59.19.194
(1) REGISTER(2) INVITE alice
(3) 128.59.19.194
No central server, but more lookup latency
IBM Delhi (Jan. 2006) 59
How to combine SIP + P2P?
• SIP-using-P2P– Replace SIP
location service by a P2P protocol
• P2P-over-SIP– Additionally,
implement P2P using SIP messaging
P2P network
Alice128.59.19.194
INSERT
INVITE sip:[email protected]
P2P-SIPoverlay Alice
128.59.19.194
REGISTERINVITE aliceFIND
SIP-using-P2P P2P SIP proxies P2P-over-SIP
Maintenance P2P P2P SIP
Lookup P2P SIP SIP
IBM Delhi (Jan. 2006) 60
Design alternatives
65a1fc
d13da3
d4213f
d462bad467c4
d471f1
d46a1c
Route(d46a1c)
18
14
21
3238
58
47
10
24 30
54
38
42
Use DHT in server farm
Use DHT for all clients - but some are resource limited
Use DHT among super-nodes
1. Hierarchy2. Dynamically adapt
servers
clients
1
10
2430
54
38
IBM Delhi (Jan. 2006) 61
Deployment scenarios
P
P
P
P
P
P2P proxies
P
P
P
P
P
P2P database
P
P
P
P
P
P2P clients
Plug and play; May use adaptors;Untrusted peers
Zero-conf server farm; Trusted servers and user identities
Global, e.g., OpenDHT; Clients or proxies can use;Trusted deployed peers
Interoperate among these!
IBM Delhi (Jan. 2006) 62
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!
IBM Delhi (Jan. 2006) 63
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 SIP+P2P• Unlike file-sharing applications
– Data storage, caching, delay, reliability• Disadvantages
– Lookup delay and security
IBM Delhi (Jan. 2006) 64
Implementation: SIPpeer• Platform: Unix (Linux), C++• Modes:
– Chord: using SIP for P2P maintenance– OpenDHT: using external P2P data storage
• based on Bamboo DHT, running on PlanetLab nodes
• Scenarios:– P2P client, P2P proxies– Adaptor for existing phones
• Cisco, X-lite, Windows Messenger, SIPc– Server farm
IBM Delhi (Jan. 2006) 65
P2P-SIP: identifier lookup• P2P serves as SIP location server:
– address-of-record contacts– e.g., [email protected]
128.59.16.1, 128.72.50.13
• multi-valued: (keyn, value1), (keyn, value2)
• with limited TTL• variant: point to SIP proxy server
– either operated by supernode or traditional server• allows registration of non-
p2p SIP domains (*@example.com)
– easier to provide call routing services (e.g., CPL) alice 128.59.16.1
alice 128.72.50.13
IBM Delhi (Jan. 2006) 66
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
1
8
14
21
32
38
58
47
10
2430
54
38
42
Key node
8+1 = 9 14
8+2 = 10 14
8+4 = 12 14
8+8 = 16 21
8+16=24 32
8+32=40 42
0 1 2 3 4 5 6 7 8
IBM Delhi (Jan. 2006) 67
Implementation: SIPpeer
User interface (buddy list, etc.)
SIPICE RTP/RTCP
Codecs
Audio devicesDHT (Chord)
On startup
Discover
User location
Multicast REGISTERPeer found/Detect NAT
REGISTER
REGISTER, INVITE,MESSAGE
Signup,Find buddies
JoinFind
Leave
On resetSignout,transfer
IM,call
SIP-over-P2P
P2P-using-SIP
IBM Delhi (Jan. 2006) 68
P2P vs. server-based SIP• Prediction:
– 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
IBM Delhi (Jan. 2006) 69
Using P2P for binding updates• Proxies do more than just plain identifier
translation:– translation may depend on who’s asking, time of
day, …• e.g., based on script output• hide full range of contacts from caller
– sequential and parallel forking– disconnected services: e.g., forward to voicemail
if no answer• Using a DHT as a location service
– use only plain translation– run services on end systems– run proxy services on supernode(s) and use
proxy as contact need replication for reliability
Skype approach
IBM Delhi (Jan. 2006) 70
P2P-SIP: Using an External P2P network (DHT)
• Data model– Treat DHT as database
• Service model– Join DHT to provide service
DHT
[1]
[2]
[3]
[1] put(k,192.1.2.3), k is H(bob)[2] get(k) gives 192.1.2.3[3] INVITE sip:bob to 192.1.2.3
bob192.1.2.3
alice
DHT[1]
[2]
[3]bob
alice
[4]
[5]
[5]
[1] join(128.3.4.5)[2] lookup(H(bob)) gives 128.3.4.5[3] REGISTER sip:bob to 128.3.4.5[4] lookup(H(bob)) gives 128.3.4.5[5] INVITE sip:bob to 128.3.4.5
Servicenode
(128.3.4.5)
IBM Delhi (Jan. 2006) 71
P2P-SIP: Logical Operations• Contact management
– put (user id, signed contact)• Key storage
– User certificates and private configurations• Presence
– put (subscribee id, signed encrypted subscriber id)– Composition needs service model
• Offline message– put (recipient, signed encrypted message)
• NAT and firewall traversal– STUN and TURN server discovery needs service
model
IBM Delhi (Jan. 2006) 72
P2P-SIP: Implementation in SIPc
• OpenDHT– Trusted nodes– Robust– Fast enough (<1s)
• Identity protection– Certificate-based– SIP id == email
• P2P forCalls, IM, presence, offline message, STUN server discovery and name search
IBM Delhi (Jan. 2006) 73
P2P-SIP: What is OpenDHT?• Service model, unlike earlier library model of Chord or
CAN– DHT accessed via SunRPC & XML-RPC– Easy deployment and maintenance
• 200-300 Bamboo DHT nodes on PlanetLab– Public DHT service running since April 2004– Many existing applications: i3, CFS, Ostream, HIP,…
• DHT API (server side on Bamboo nodes)– PUT(key,value,H(secret),ttl) where H() is SHA1– GET(key) (value,H(secret),remaining-ttl)– REMOVE(key,H(value),secret,ttl)
• ReDiR API (client side for lookup/join/leave) – Can build anycast, multicast, range search using
this• Fair resource (disk) allocation among clients (IP addr)
IBM Delhi (Jan. 2006) 74
Hybrid architecture
• Cross register, or • Locate during call setup
– DNS, or– P2P-SIP hierarchy
IBM Delhi (Jan. 2006) 75
Concerns about 3G + NGN• Complexity
– many signaling hops server cost, delay• Assumption of heavy-weight peering
– “lawyer employment act of 2004”– rather than email-style “all I need is a name”
peering• Coupling of application signaling and network
signaling– incentive to bypass if cost/byte is higher– makes it more costly to add new QoS-sensitive
applications• IPTV, remote instrumentation, etc.
– got us tromboning before: mobility issues
IBM Delhi (Jan. 2006) 76
Reliability and scalabilityTwo stage architecture for CINEMA
Master
Slave
Master
Slave
sip:[email protected]:[email protected]
s1
s2
s3
a1
a2
b1
b2
a*@example.com
b*@example.com
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
a.example.com_sip._udp SRV 0 0 a1.example.com SRV 1 0 a2.example.com
b.example.com_sip._udp SRV 0 0 b1.example.com SRV 1 0 b2.example.com
Request-rate = f(#stateless, #groups)
Bottleneck: CPU, memory, bandwidth?Failover latency: ?
ex
IBM Delhi (Jan. 2006) 77
Hybrid architecture
• Cross register, or • Locate during call setup
– DNS, or– P2P-SIP hierarchy
IBM Delhi (Jan. 2006) 78
Comparison of P2P and server-based systems
server-based P2P
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
IBM Delhi (Jan. 2006) 79
Open issues• Presence and IM
– where to store presence information: need access authorization
• Performance– how many supernodes are needed? (Skype: ~1000)
• Reliability– P2P nodes generally replicate data– if proxy or presence agent at leaf, need proxy data replication
• Security– Sybil attacks: blackholing supernodes– Identifier protection: protect first registrant against identity
theft– Anonymity, encryption– Protecting voicemails on 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?
IBM Delhi (Jan. 2006) 80
SIP p2p summary
• Advantages– Out-of-box
experience– Robust
• catastrophic failure-unlikely
– Inherently scalable• more with more
nodes• Status
– IETF involvement– Columbia SIPpeer
• Security issues– Trust, reputation– malicious node, sybil
attack– SPAM, DDoS– Privacy, anonymity (?)
• Other issues– Lookup
latency,proximity– P2P-SIP vs SIP-using-
P2P– Why should I run as
super-node?
http://www.cs.columbia.edu/IRT/p2p-sip http://www.p2psip.org and
IBM Delhi (Jan. 2006) 81
Conclusion• Peer-to-peer VoIP offers new opportunities
– small, low-maintenance networks– low overhead
• But Skype success is largely independent of peer-to-peer approach
– (usually) “just works” – out-of-the-box experience
– voice quality– low cost to entry (cf. Vonage)
• Standards-based peer-to-peer VoIP– IETF SIPPEER BOF at next IETF meeting (March)– different perspectives (large vs. small, etc.)
IBM Delhi (Jan. 2006) 82
References• Skype reports:
http://www1.cs.columbia.edu/~salman/skype/• iSAC:
http://www.globalipsound.com/datasheets/iSAC.pdf• iLBC: http://
www.globalipsound.com/datasheets/iLBC.pdf