peer-to-peer voip kundan singh, salman baset and henning schulzrinne internet real time laboratory...

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


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)


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


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


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


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


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


A p2p illusion?

• Login server• Servers for SkypeOut and SkypeIn• Anonymous call minutes statistic

gathering


The Skype Network


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


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


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


Skype HC (ver: 0.97)


Skype HC


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>

http://www.globalipsound.com/


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)

http://www.net-peeker.com/

http://www.nch.com.au/tonegen/

http://www.rohitab.com/apimonitor/


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


Skype Functions

•Startup•Login•User Search•Call Establishment•Media Transfer•Keep-Alive•NAT and firewall Traversal•Conferencing


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


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


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


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 . . . .


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


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


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


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


Skype Functions: USER SEARCH

Public NAT Firewall

Data Exchanged

1-2 kilobytes 1-2 kilobytes 2-4 kilobytes


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


Call Establishment

Public-public Public-NAT Firewall-Firewall

Data Exchanged

4-5 kilobytes 6-8 kilobytes 6-7 kilobytes


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


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)


Skype Functions: Keep Alive• Refresh message over TCP to SN every 60 seconds• Refresh message size: 60 bytes


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



A: Pentium4, 2GHz




1: B-A Call

2: B-C Call



A: Pentium4, 2GHz




1: B-A Call

2: B-C Call

B decides to initiate a conference



A: Pentium4, 2GHz




B

C A+B

A+C



A: Pentium4, 2GHz



• B and C are behind NAT. A has public IP addresses

1: B-A Call

B

A

BA

Online Skype node



A: Pentium4, 2GHz (public IP)


(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


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.


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~


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


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


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


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?


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


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


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)


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


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


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


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


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


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)


Other schemes• Distributed TRIE• Viceroy• Kademlia• SkipGraph• Symphony• …


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


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


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


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


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


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!


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!


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


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


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


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


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


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


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


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)


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


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


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)


Hybrid architecture

• Cross register, or • Locate during call setup

– DNS, or– P2P-SIP hierarchy


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


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


Hybrid architecture

• Cross register, or • Locate during call setup

– DNS, or– P2P-SIP hierarchy


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


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?


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

http://www.cs.columbia.edu/IRT/p2p-sip

http://www.p2psip.org/


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.)


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

http://www1.cs.columbia.edu/~salman/skype/

http://www.globalipsound.com/datasheets/iSAC.pdf

http://www.globalipsound.com/datasheets/iLBC.pdf

http://www.globalipsound.com/datasheets/iLBC.pdf