1. Peer-to-peer Internet telephony using SIP
by Kundan Singh and Henning Schulzrinne
Computer Science Department, Columbia University, New York
July 26, 2006

2. Why P2P-SIP? What is our P2P-SIP?
Server-based
Maintenance and configuration cost: dedicated administrator
Central point of failures: catastrophic failures
Depends on controlled infrastructure (e.g., DNS)
Peer-to-peer
Self adjusting, robust against catastrophic failures, highly scalable, and no configurations
Call setup and user search latency is higher: O(log(N))
Security: how to handle malicious peers? Identity protection?
Our P2P-SIP
Hybrid architecture: works with both P2P and server-based
Built-in P2P network: acts as a service node for proxy, registrar, presence, offline storage, and media relay
External P2P network: managed and trusted peer nodes
Identity protection: identifier == SIP identifier

3. How to combine SIP + P2P? P2P-over-SIP SIP-using-P2P
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
SIP
Lookup
SIP-using-P2P:
Reuse optimized and well-defined external P2P network
Define P2P location service interface to be used in SIP
Extends to other signaling protocols (H.323)
Don’t overload SIP or REGISTER
Lookup is separate from call signaling
P2P-over-SIP
No change in semantics of SIP
No dependence on external P2P network
Reuse existing features such as forking (for voice mail)
Built-in NAT/media relays.
Additional message overhead due to SIP.
P2P network
REGISTER
FIND
INVITE alice
P2P-SIP
overlay
INSERT
Alice
INVITE
Alice

4. SIP-using-P2P 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 design consists of many logical operations. The contact management deals with storing and retrieving user contacts as in SIP location service. The contacts are signed by the user on put and verified on get before making a call. Key storage deals with storing the certificate and encrypted private key of the user. The caller uses this certificate to verify. Presence deals with the subscribers updating the watcher list of the given subscribee such that only he can read the identifiers of the subscribers. Similarly, offline message deals with putting the signed and encrypted messages for the recipient such that only he can read and delete it. For NAT and firewall traversal, it provides P2P service discovery of a STUN or TURN server.
XML-based data format

5. SIP-using-P2P Using an External P2P network (distributed hash table - DHT)
Data model
Treat DHT as database
Service model
Join DHT to provide service
[5]
bob
bob
[3]
[1]
[2]
[1]
[3]
DHT
DHT
Service
node
( )
There are two approaches to do the P2P-SIP operations. In the data model, the DHT is treated as a database with put, get, remove API, and performs all operations using this. In the service model, the every P2P-SIP node joins the DHT as a service node and serves as registrar, proxy, presence agent and STUN/TURN server for other nodes. It uses lookup, join and leave API.
It is possible to layer them on one another: data model on top of service model is straight forward. Additionally OpenDHT shows that service model on top of data model is also possible using the ReDiR interface.
[4]
[2]
[5]
alice
alice
[1] join( )
[2] lookup(H(bob)) gives
[3] REGISTER sip:bob to
[4] lookup(H(bob)) gives
[5] INVITE sip:bob to
[1] put(k, ), k is H(bob)
[2] get(k) gives
[3] INVITE sip:bob to

6. SIP-using-P2P Implementation in SIPc with the help of Xiaotao Wu
OpenDHT
Trusted nodes
Robust
Fast enough (<1s)
Identity protection
Certificate-based
SIP id ==
P2P for
Calls, IM, presence, offline message, STUN server discovery and name search
P2P clients better than proxies:
Less DHT calls
OpenDHT quota per client limits put by proxies
We have implemented P2P-SIP in our multimedia collaboration client, sipc, using OpenDHT running on Planetlab with about 200 nodes. The advantage of using an externally managed DHT is that we can trust to some extent that the nodes are not malicious and perform the DHT operations (get/put) correctly. Thus the security problem is mostly avoided. The identity protection is provided using a well known CA such as ours which gives out the certificate to the user for her address, so that the user can securely use her address as the SIP identifier in P2P-SIP. The implementation includes the P2P modes for calls, IM, presence, offline message storage, STUN server discovery and name search (find the user identifier for “Firstname Lastname”)
OpenDHT is robust and fast enough for our needs. Lookups on an average take less than a second. We implemented redundancy and failover so that if one OpenDHT node is unavailable it uses another randomly choosen closer node.

7. P2P-over-SIP Architecture and implementation
DHT (Chord) algorithm using SIP messages with query and update semantics of REGISTER
Has SIP registrar, proxy, user agent
Other: discovery, NAT traversal, failover
Adaptor: allows existing SIP devices to become P2P

8. P2P-over-SIP Node architecture: registrar, proxy, user agent
User interface (buddy list, etc.)
Signup,
Find buddies
IM,
call
On reset
Signout,
transfer
On startup
User location
Leave
Find
Discover
Join
Audio devices
DHT (Chord)
REGISTER,
INVITE,
MESSAGE
Codecs
Peer found/
Detect NAT
Multicast REGISTER
REGISTER
ICE
SIP
RTP/RTCP
SIP-over-P2P
P2P-using-SIP
DHT communication using SIP REGISTER
Known node:
Unknown node:
User:

9. Design alternatives Use DHT in server farm1 8 14 21 32 38 58 47 10 24 30 54 42
65a1fc
d13da3
d4213f
d462ba
d467c4
d471f1
d46a1c
Route(d46a1c)
servers 1 54 10 38 24 30
Hierarchy
Dynamically adapt
clients
Use DHT in server farm
Use DHT for all clients; But some are resource limited
Use DHT among super-nodes

10. Deployment scenarios Interoperate among these! P2P proxies P2P clients
Different scenarios have different trust models!
P2P proxies
P2P clients
Plug and play;
May use adaptors;
Untrusted peers;
Super-nodes
Zero-conf server farm;
Trusted servers and
user identities
Interoperate among these!

11. SIP-using-P2P vs P2P-over-SIP
Not SIP-specific, hence no implementation overhead for non-VoIP but P2P applications
Low transport and transaction overhead
No P2P security burden on SIP
No dependency on single DHT implementation
Reuse SIP naming, routing, security, NAT/firewall traversal
Easily reuse existing SIP components without change
voic , conference
Single DHT implementation
Readily supports service model

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

13. IETF activities Concepts and terminologies Questions?
Client vs peer protocol
Enrollment vs insertion
Questions?
What gets standardized?
Are topologies with NAT within scope?

14. More at … http://www.cs.columbia.edu/IRT/p2p-sip

15. Backup slides

16. What is P2P-SIP? Unlike proprietary Skype architecture
Robust and efficient lookup using DHT
Interoperability
DHT algorithm uses SIP communication
Hybrid architecture
Lookup in SIP+P2P
Inter-domain P2P-SIP
Unlike file-sharing applications
Data storage, caching, delay, reliability
Data model and service model
Disadvantages
Lookup delay and security
Problems with skype: proprietary architecture, single service, centralized component.
Zipf: straight line on double log axes.

17. Comparison: Server-based, structured and unstructured P2P
Architecture
Server-based (two-stage)
Structure P2P (Chord/log(N))
Unstructured P2P
(blind search)
Reliability (or user record availability)
(1-(1-R)P)
Upper bound
No guarantee
Performance (delay)
Low
Log(N)
No guarantee; Implementation dependent
Scalability (number of users)
Linear with number of servers
Exponential with per node capacity
If constant degree, then no limit

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

19. Structured vs. unstructured P2P-SIP
Unstructured P2P alone is not good
No guarantee (upper bound) in lookup
Fall back to server; has central dependency
Caching is not much useful as contacts change often; caching good for non-mutable data (e.g., certificates) because replication and caching of mutable data don’t go together well.
Skype works:
Few super nodes are too burdened
Node:supernode ~ 400:1
Probably some kind of structure (user name prefix) among super nodes, and falls back to central server

20. Chord background Finger table: logN Stabilization for join/leave
Key
node
8+1 = 9 14
8+2 = 10
8+4 = 12
8+8 = 16 21
8+16=24 32
8+32=40 42 1 54 8 58 10 14 47 21
Lookup in finger table for the furthest node that precedes the key
In a system with N nodes and K keys, with high probability,
each node receives at most K/N keys
each node maintains information about O(logN) other nodes
lookups resolved with O(logN) hops
No network locality.
Replicas need to have explicit consistency.
Optimizations:
location: weight neighbor nodes by RTT.
When routing choose the neighbor who is closer to destination with lowest RTT from me.
Reduce path latency.
Multiple physical nodes per virtual node.
What if a node leaves?
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

21. P2P-over-SIP Implementation31
sippeer: C++, Linux, Chord
Node join and form the DHT
Node failure is detected and DHT updated
Registrations transferred on node shutdown
Co-located sipc can use sippeer service 29 1 31 30 25 26 26 9 19 11 15

22. SIP messages DHT (Chord) maintenance1
DHT (Chord) maintenance
Query the node at distance 2k with node id 11
REGISTER
To:
From:
SIP/ OK
Contact:
Update my neighbor about me
To:
Contact: 10 22 7 15
Find(11) gives 15

23. SIP messages User registration Call setup and instant messaging
REGISTER
To:
Contact:
Call setup and instant messaging
INVITE
To:
From:

24. Node startup SIP DHT Dialing out REGISTER with SIP registrar
columbia.edu DB
sipd
SIP
REGISTER with SIP registrar
DHT
Discover peers: multicast REGISTER
Join DHT using node-key=Hash(ip)
REGISTER with DHT using
Dialing out
Call, instant message, etc.
INVITE
MESSAGE
Last seen, SIP NAPTR/SRV, DHT
REGISTER
Detect peers
REGISTER alice=42 42 58 12 14
REGISTER bob=12 32

25. Node leaves Graceful leave Failure Un-REGISTER Transfer registrations
Attached nodes detect and re-REGISTER
New REGISTER goes to new super-nodes
Super-nodes adjust DHT accordingly
REGISTER key=42
REGISTER
DHT
OPTIONS 42 42

26. Adaptor for existing phones
Use P2P-SIP node as an outbound proxy
ICE for NAT/firewall traversal
STUN/TURN server in the node

27. Hybrid architecture Cross register, or Locate during call setup
DNS, or
P2P-SIP hierarchy

28. NAT traversal and P2P-SIP
Joining a DHT from behind a NAT: open issue
NATed nodes acts as users of DHT
Media traversal
STUN (not symmetric: 18%?), TURN, ICE
Hole punching – works with 60% symmetric

29. Security open issues (threats, solutions, issues)
More threats than server-based
Privacy, confidentiality
Malicious node
Don’t 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, …
Design principles:
define verifiable system invariants and verify them
Allow querier to observe the lookup progress
Assign keys to nodes in a verifiable manner
Server selection in routing may be abused
Cross check routing tables using random queries
Avoid single point of responsibility
Pastry - exclude untrusted nodes with help of central certificate authority.
Incorrect data served: verify by self certifying path names

30. Security Random thoughts
Un-trusted peers:
Misrouting: easy to detect
No-routing: hard (redundancy, reputation, “call itself”)
Problems:
Malicious program, copyright violation, stolen identity, privacy, free riding, sybil, programmable scripts, aliases
Separate DHT from application
Managed DHT: more trusted

31. Related work P2P networks Skype and related systems P2P-SIP telephony
Unstructured (Kazaa, Gnutella,…)
Structured (DHT: Chord, CAN,…)
Skype and related systems
Flooding based chat, groove, Magi
Skype-in/out uses SIP
P2P-SIP telephony
Proprietary: NimX, Peerio,
File sharing: SIPShare
Now in IETF: W&M, Avaya, Panasonic, …
Mercora – legal music sharing
S2S – science to science is a p2p search engine built using JXTA
SOS – source->access point->beacon->secret servlet->filter/firewall->target. Target picks secret servlets. Beacon know abt secret servlets.

32. Advanced services Offline messages Conferencing Inter-domain
INVITE or MESSAGE fails => Responsible node stores voic , instant message.
Conferencing
Mixer, full mesh, multicast
Inter-domain
Local DHT; connected by DNS or global DHT