Download (SIP).

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Computer and network surveillance wikipedia , lookup

Mobile security wikipedia , lookup

Deep packet inspection wikipedia , lookup

Transcript
VOIP over Peer-to-Peer
R94921046 歐政穎
R94921042 羅成俊
R94921027 黃家俐
R93922064 蔡明倉
Road Map
Introduction
 Background
 VOIP with P2P architecture

SIP
 Media routing

Interwork with PSTN
 Problems
 Summary

Introduction

Advantages of P2P systems
High scalability
 Robustness
 Fault tolerance
 Network self-organizes
 Intelligence (cooperation)


How can VOIP be integrated within a
P2P system?
Road Map
Introduction
 Background
 VOIP on P2P architecture

SIP
 Media routing

Interwork with PSTN
 Problems
 Summary

P2P Architecture

Centralized



Pure



Directory is stored in one server, but data is
transferred between peers
Napster
Directory is stored in each peer, and lookup is by
flooding query messages
Gnutella
Hybrid (super-node)


Directory is stored in each super node, and lookup
is by requesting super-nodes
Kazza
P2P Architecture
Distributed Hash Table
Chord, Pastry, CAN, Tapestry, …
 Lookup styles directly map to the redirect and
proxy server

Chord
P2P 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/leav
e
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
consecuti
ve peers;
retry on
failure
Replicate data on
multiple peers; keep
multiple paths to each
peers
Routing load
is evenly
distributed
among
participant
lookup
servers
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
Gateways, TRIP, ENUM
interoperability
Interact with server-based
infrastructure or co-locate peer
node with the gateway
Road Map
Introduction
 Background
 VOIP on P2P architecture

SIP
 Media routing

Interwork with PSTN
 Problems
 Summary

VOIP on P2P Architecture
Block diagram of a P2P-SIP node
 SIP

Initialization
 Registration and Peer discovery
 Dialing out
 Node shutdown


Media routing
Firewall and NAT traversal
 Intelligent routing

Block diagram of a P2P-SIP node
Initialization
Initialization

Calculate the key for DHT by IP


7
Contact one of the node in DHT network

Request
REGISTER sip:128.59.15.31 SIP/2.0
To: <sip:[email protected]>
From: <sip:[email protected]>

Response
SIP/2.0 200 OK
To: sip:[email protected]
Contact: <sip:[email protected]>; predecessor=sip:[email protected]
Initialization

Insert self into correct position


Between predecessor: 1 and successor: 10
Build routing table


10>= 7+2i-1, i = 1, 2
Send sip REGISTER from 11 (= 7+23-1)
REGISTER sip:128.59.15.55 SIP/2.0
To: <sip:[email protected]>
From: <sip:[email protected]>

Respond by 15
SIP/2.0 200 OK
To: <sip:[email protected]>
Contact: <sip:[email protected]>; predecessor=sip:[email protected]

…
Initialization
Registration and Peer Discovery
columbia.edu
sipd

REGISTER
SIP

DB

[email protected]
DHT

Detect peers


REGISTER alice=42
42
58
12
14
REGISTER bob=12
32
REGISTER with SIP registrar
Discover peers: bootstrap node
Join DHT using node-key
=Hash(ip)
REGISTER with DHT using
user-key
=Hash([email protected])
Dialing Out

Call, instant message, etc.
INVITE sip:[email protected]
MESSAGE sip:[email protected]
INVITE key=42
302

If existing buddy, use cache
first
 If not found
INVITE

DHT

SIP-based lookup (DNS
NAPTR, SRV,…)
P2P lookup


42
Send to super-nodes: proxy
Use DHT to locate: proxy or
redirect
Node shutdown

Graceful termination

7 will send unregister message to its predecessor:1 and
successor: 10
REGISTER sip:[email protected] SIP/2.0
To: <sip:[email protected]>
From: <sip:[email protected]>
Expires: 0
Contact: <sip:[email protected]>; q=1.0; predecessor=sip:[email protected]
Contact: <sip:[email protected]>; q=.8
…
REGISTER sip:[email protected] SIP/2.0
To: <sip:[email protected]>
From: <sip:[email protected]>
Expires: 0
Contact: <sip:[email protected]>; q=1.0; predecessor=sip:[email protected]

DHT system will re-organize
Node shutdown

Node failure
When nodes find a remote node failure, it
removes it from its routing table
 Resend the original query request to the
new failover hop

Firewall & NAT Traversal

Signaling
SIP symmetric response routing
 Connection reuse



Use existing connections to transmit signals
Media
ICE (interactive connectivity establishment)
for media session
 STUN and TURN

Intelligent Routing
In an overlay network, there are diverse
paths through relay nodes
 But how to select a good one? It needs
extra measurements!
 Criterions for selecting paths

Packet loss rate
 End-to-end delay
 Available bandwidth

Intelligent Routing
Most of those measurements require the
cooperation of middle nodes
 They are easier to be implemented in
P2P architecture than others

Road Map
Introduction
 Background
 VOIP on P2P architecture

SIP
 Media routing

Interwork with PSTN
 Problems
 Summary

Interwork with PSTN (1/4)

How do they verify that the user owns the
number if he registers his number?


Every gateway node can reach potentially
every phone number in the world – at very
different rates.
Registering a telephone prefix

Use tel URI (Not conformant with RFC 3966)


“tel:;phone-context=+1-212”
“sip:[email protected];user=phone”
Interwork with PSTN (2/4)

Calling a telephone number
INVITE tel:+1-212-939-7040 SIP/2.0
To: <tel:+1-212-939-7040>
From: <sip:[email protected]>
Request-Disposition: redirect


The basic key, K0, is “tel:+12129397040” derived
from To header after removing any fillers.
Other keys, Kn−i, is computed as “tel:;phonecontext=+first i digits prefix”, for i=1,2,..n-1, where n
is total number of digits.
Interwork with PSTN (3/4)

Incoming INVITE handling

The canonical “tel” URI is formed to compute
the DHT key by removing fillers and converting
“sip” URI to “tel” URI.


For example, “sip:[email protected];
user=phone” is converted to “tel:;phone-context=
+1212939”.
This is used as the key to compute the next
hop in routing.
Interwork with PSTN (4/4)

Response
SIP/2.0 302 Moved temporarily
To: <tel:;phone-context=+1212939>
Contact: <sip:phone.cs.columbia.edu;lr> cost=0; q=1.0
SIP/2.0 302 Moved temporarily
To: <tel:;phone-context=+1212>
Contact: <sip:phone.cs.columbia.edu;lr> cost=USD.03/6s; q=1.0
Contact: <sip:manhattan.verizon.com;lr>; cost=USD.06/60s; q=.8
SIP/2.0 302 Moved temporarily
To: <tel:;phone-context=+1>
Contact: <sip:mci.com;lr> cost=USD.10/120s; q=1.0
Contact: <sip:att.com;lr>; cost=USD.09/60s; q=.8
Road Map
Introduction
 Background
 VOIP on P2P architecture

SIP
 Media routing

Interwork with PSTN
 Problems
 Summary

Problems

Security issues in peer-to-peer system

Malicious program


break-in, spying or spread virus, spy-wares or worms
Reducing risks by



Software developed by trusted entities or open source community
Running the application as a regular user instead of an
administrator (on Windows) or super-user (on Unix)
Copyright violation


Easily extended to support file transfer
Reducing risk by

P2P-SIP does not have an efficient search method
Problems

Stolen identity



A malicious user may steal the identify of another user
Solved by doing Authentication
 User identify must be a valid email address
 System generates a password for the user identify and sends
it to the email address
 Using MD5 hash function
Data Privacy


Public/Private/Protected Data
Solved by using Public key mechanism
Problems

Trust


Misbehaving peers that route calls incorrectly or log information
for misuse
Solved by

Hide the security algorithms
Summary

P2P useful




Scalable, reliable
No configuration
Not as fast as client/server
P2P/SIP


Basic operations easy
Some potential issues



Security
Performance
Quality (audio)
Reference





Kundan Singh and Henning Schulzrinne, "Peer-topeer Internet Telephony using SIP", NOSSDAV.
Skamania, Washington, June 2005.
Kundan Singh and Henning Schulzrinne, "Peer-topeer Internet Telephony using SIP", New York Metro
Area Networking Workshop, Sep 2004.
Kundan Singh and Henning Schulzrinne, "Peer-topeer Internet Telephony using SIP", Columbia
University Technical Report CUCS-044-04, Oct 2004.
http://www1.cs.columbia.edu/~kns10/research/p2psip/
http://www.p2psip.org/
Reference





An extension to the session initiation protocol (SIP) for symmetric
response routing. RFC 3581, Internet Engineering Task Force,
Aug. 2003
Connection reuse in the session initiation protocol (SIP). Internet
Draft draft-ietf-sip-connect-reuse-00, Internet Engineering Task
Force, Aug. 2003
Interactive connectivity establishment (ICE): a methodology for
network address translator (NAT) traversal for the session
initiation protocol (SIP). Internet Draft draft-ietf-mmusic-ice-00,
Internet Engineering Task Force, Oct. 2003
Improving VoIP Quality Through Path Switching, in Proceedings
of IEEE INFOCOM 2005, Miami, March, 2005
Exploring the Performance Benefits of End-to-End Path Switching.
In Proceedings of ACM Sigmetrics/Performance (Extended
Abstract), New York, June 2004