Embed Size (px)
Citation preview
VoIP: Not your grandmother's phone any more
Henning SchulzrinneDept. of Computer Science, Columbia University, New York
(based on work in collaboration with IRT students & staff, as well as the IETF GEOPRIV and SIMPLE WGs)
Rutgers University
April 2009
2
Outline
• VoIP maturing: vision vs. reality– presence and location-based services– user-programmable services
• VoIP challenges– scaling– peer-to-peer systems– spam/SPIT– emergency calling
• The state of SIP standardization, year 11– developments in 2006 & upcoming highlights– trouble in standards land– interoperability
3
The three Cs of Internet applications
communications communitycommerce
grossly simplified...
researchfocus
what users care aboutwhat users care about
4
Killer Application
• Carriers looking for killer application– justify huge infrastructure investment– “video conferencing” (*1950 – †2000)– ?
• “There is no killer application”– Network television block buster YouTube hit– “Army of one”– Users create their own custom applications that are important to
them– Little historical evidence that carriers (or equipment vendors) will
find that application if it exists
• Killer app = application that kills the carrier
5
Collaboration in transition
intra-organization;small number of
systems (meeting rooms)
inter-organizationmultiple
technology generations
diverse end points
proprietary (single-vendor) systems
standards-based solutions
6
Evolution of VoIP
“amazing – the
phone rings”
“does it docall transfer?”
“How can I make it
stop ringing?”
1996-2000 2000-2003 2004-2005
catching upwith the digital PBX
long-distance calling,ca. 1930
going beyondthe black phone
2006-
“Can it really
replace the phone
system?”
replacing theglobal phone system
7
IETF VoIP efforts
SIP(protocol)
SIPPING(usage, requirements)
ECRIT(emergency calling)
AVT(RTP, SRTP, media)
ENUM(E.164 translation)
IPTEL(tel URL)
SIMPLE(presence)
GEOPRIV(geo + privacy)
usesmay use
uses
provides
usually
used with
IETF RAI area
MMUSIC(SDP, RTSP, ICE)
XCON(conf. control)
SPEERMINT(peering)
uses
SPEECHSC(speech services)
SIGTRAN(signaling transport)
uses
8
Old vs. new
old reality new idea new reality
service provider
ILEC, CLEC email-like, run by enterprise, homes
E.164-driven; MSOs, some ILECs, Skype, European SIP providers, Vonage, SunRocket
media 4 kHz audio wideband audio, video, IM, shared apps, …
4 kHz audio
services CLASS (CLID, call forwarding, 3-way calling, ...)
user-created services
(web model)
presence
still CLASS
user IDs E.164 email-like E.164
IM handles
9
SIP Overview
10
Internet services – the missing entry
Service/delivery
synchronous asynchronous
push instant messagingpresenceevent notificationsession setupmedia-on-demand
messaging
pull data retrievalfile downloadremote procedure call
peer-to-peer file sharing
11
Filling in the protocol gap
Service/delivery
synchronous asynchronous
push SIPRTSP, RTP
SMTP
pull HTTPftpSunRPC, Corba, SOAP
(not yet standardized)
12
SIP as service enabler
• Rendezvous protocol– lets users find each other by only
knowing a permanent identifier• Mobility enabler:
– personal mobility• one person, multiple terminals
– terminal mobility• one terminal, multiple IP
addresses– session mobility
• one user, multiple terminals in sequence or in parallel
– service mobility• services move with user
13
What is SIP?
Session Initiation Protocol protocol that establishes, manages (multimedia) sessions also used for IM, presence & event notification
uses SDP to describe multimedia sessions Developed at Columbia U. (with others)
Standardized by IETF (RFC 3261-3265 et al)
3GPP (for 3G wireless) PacketCable
About 100 companies produce SIP products Microsoft’s Windows Messenger (≥4.7)
includes SIP
14
Philosophy
• Session establishment & event notification• Any session type, from audio to circuit emulation• Provides application-layer anycast service• Provides terminal and session mobility• Based on HTTP in syntax, but different in protocol
operation• Peer-to-peer system, with optional support by proxies
– even stateful proxies only keep transaction state, not call (session, dialogue) state
– transaction: single request + retransmissions– proxies can be completely stateless
15
Basic SIP message flow
16
SIP trapezoid
SIP trapezoid
outbound proxy
[email protected]: 128.59.16.1
registrar
1st request
2nd, 3rd, … request
voice trafficRTP
destination proxy(identified by SIP URI domain)
17
SIP message format
SDP
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP here.com:5060From: Alice <sip:[email protected]>
To: Bob <sip:[email protected]>Call-ID: [email protected]
CSeq: 1 INVITESubject: just testing
Contact: sip:[email protected]: application/sdp
Content-Length: 147
v=0o=alice 2890844526 2890844526 IN IP4 here.com
s=Session SDPc=IN IP4 100.101.102.103
t=0 0m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
SIP/2.0 200 OK
Via: SIP/2.0/UDP here.com:5060From: Alice <sip:[email protected]>
To: Bob <sip:[email protected]>Call-ID: [email protected]
CSeq: 1 INVITESubject: just testing
Contact: sip:[email protected]: application/sdp
Content-Length: 134
v=0o=bob 2890844527 2890844527 IN IP4 there.com
s=Session SDPc=IN IP4 110.111.112.113
t=0 0m=audio 3456 RTP/AVP 0a=rtpmap:0 PCMU/8000m
essa
ge b
ody
hea
der
field
sre
ques
t lin
e
request response
18
PSTN vs. Internet Telephony
Signaling & Media Signaling & Media
Signaling Signaling
Media
PSTN:
Internettelephony:
China
Belgian customer,currently visiting US
Australia
19
SIP addressing
• Users identified by SIP or tel URIs– sip:[email protected]
• tel: URIs describe E.164 number, not dialed digits (RFC 2806bis)
• tel URIs SIP URIs by outbound proxy• A person can have any number of SIP URIs• The same SIP URI can reach many different
phones, in different networks– sequential & parallel forking
• SIP URIs can be created dynamically:– GRUUs– conferences– device identifiers (sip:[email protected])
• Registration binds SIP URIs (e.g., device addresses) to SIP “address-of-record” (AOR)
tel:110 sip:sos@domain
domain 128.59.16.17
via NAPTR + SRV
20
3G Architecture (Registration)
visited IM domain
home IM domain
servingCSCF
interrogating
proxy
interrogating
mobility managementsignaling
registration signaling (SIP)_
Presence and event notification
22
We need glue!
• Lots of devices and services– cars– household– environment
• Generally, stand-alone– e.g., GPS can’t talk to camera
• Home– home control networks have generally
failed• cost, complexity
• Environment– “Internet of things”– tag bus stops, buildings, cars, ...
23
Left to do: event notification
• notify (small) group of users when something of interest happens– presence = change of communications state– email, voicemail alerts– environmental conditions– vehicle status– emergency alerts
• kludges– HTTP with pending response– inverse HTTP --> doesn’t work with NATs
• Lots of research (e.g., SIENA)
• IETF efforts starting– SIP-based– XMPP
24
Context-aware communication
• context = “the interrelated conditions in which something exists or occurs”
• anything known about the participants in the (potential) communication relationship
• both at caller and callee
time CPL
capabilities caller preferences
location location-based call routing
location events
activity/availability presence
sensor data (mood, bio) privacy issues similar to location data
25
The role of presence
• Guess-and-ring– high probability of failure:
• “telephone tag”• inappropriate time (call during
meeting)• inappropriate media (audio in
public place)– current solutions:
• voice mail tedious, doesn’t scale, hard to search and catalogue, no indication of when call might be returned
• automated call back rarely used, too inflexible
most successful calls are now scheduled by email
• Presence-based– facilitates unscheduled
communications– provide recipient-specific
information– only contact in real-time if
destination is willing and able– appropriately use synchronous
vs. asynchronous communication
– guide media use (text vs. audio)
– predict availability in the near future (timed presence)
Prediction: almost all (professional) communication will be presence-initiated or
pre-scheduled
26
GEOPRIV and SIMPLE architectures
targetlocationserver
locationrecipient
rulemaker
presentity
caller
presenceagent
watcher
callee
GEOPRIV
SIPpresence
SIPcall
PUBLISHNOTIFY
SUBSCRIBE
INVITE
publicationinterface
notificationinterface
XCAP(rules)
INVITE
DHCP
27
Presentity and Watchers
Bob’s status, location
Watchers
Available, Busy, Somewhat available,
InvisibleInvisible
wife
son
externalworld
PUBLISH SUBSCRIBE
NOTIFY
Bob’sPresentity WatchersWatchers
Bob’s Presence User Agents (PUA)
PC-IM Client
R u there ?
Bob’s play station
Cell
Phone
BUZZ
PUBLISH
Bob’s Filters
(Rules), PIDF *)
PresenceServer(PS)
*) - PIDF = Presence Information Data Format
friend
28
Basic presence
• Role of presence– initially: “can I send an instant message and expect a
response?”– now: “should I use voice or IM? is my call going to interrupt a
meeting? is the callee awake?”
• Yahoo, MSN, Skype presence services:– on-line & off-line
• useful in modem days – but many people are (technically) on-line 24x7
• thus, need to provide more context
– + simple status (“not at my desk”)• entered manually rarely correct• does not provide enough context for directing interactive
communications
29
Presence data architecture
rawpresencedocument
createview
(compose)
privacyfiltering
draft-ietf-simple-presence-data-model
compositionpolicy
privacypolicy
presence sources
XCAP XCAP
(not defined yet)
depends on watcherselect best sourceresolve contradictions
PUBLISH
30
Presence data architecture
candidatepresencedocument
watcherfilter
rawpresencedocument
post-processingcomposition(merging)
finalpresencedocument
differenceto previous notification
SUBSCRIBE
NOTIFY
remove data not of interest
watcher
31
Presence data model
“calendar” “cell” “manual”
[email protected], video, text
person(presentity)
(views)
services
devices
32
Rich presence
• More information• automatically derived from
– sensors: physical presence, movement– electronic activity: calendars
• Rich information:– multiple contacts per presentity
• device (cell, PDA, phone, …)• service (“audio”)
– activities, current and planned– surroundings (noise, privacy, vehicle, …)– contact information– composing (typing, recording audio/video IM, …)
33
RPID: rich presence
<person> <tuple> <device>
<activities>
<class>
<mood>
<place-is>
<place-type>
<privacy>
<relationship>
<service-class>
<sphere>
<status-icon>
<time-offset>
<user-input>
34
RPID = rich presence
• Provide watchers with better information about the what, where, how of presentities
• facilitate appropriate communications:– “wait until end of meeting”– “use text messaging instead of phone call”– “make quick call before flight takes off”
• designed to be derivable from calendar information– or provided by sensors in the environment
• allow filtering by “sphere” – the parts of our life– don’t show recreation details to colleagues
35
CIPID: Contact Information
• More long-term identification of contacts• Elements:
– card – contact Information – home page– icon – to represent user– map – pointer to map for user– sound – presentity is available
36
The role of presence for call routing
• Two modes:– watcher uses presence
information to select suitable contacts
• advisory – caller may not adhere to suggestions and still call when you’re in a meeting
– user call routing policy informed by presence
• likely less flexible – machine intelligence
• “if activities indicate meeting, route to tuple indicating assistant”
• “try most-recently-active contact first” (seq. forking)
LESS
translateRPID
CPL
PA
PUBLISH
NOTIFY
INVITE
37
Presence and privacy
• All presence data, particularly location, is highly sensitive
• Basic location object (PIDF-LO) describes– distribution (binary)– retention duration
• Policy rules for more detailed access control– who can subscribe to
my presence– who can see what
when
<tuple id="sg89ae">
<status>
<gp:geopriv>
<gp:location-info>
<gml:location>
<gml:Point gml:id="point1“
srsName="epsg:4326">
<gml:coordinates>37:46:30N 122:25:10W
</gml:coordinates>
</gml:Point>
</gml:location>
</gp:location-info>
<gp:usage-rules>
<gp:retransmission-allowed>no
</gp:retransmission-allowed>
<gp:retention-expiry>2003-06-23T04:57:29Z
</gp:retention-expiry>
</gp:usage-rules>
</gp:geopriv>
</status>
<timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>
38
Privacy policy relationships
geopriv-specific presence-specific
common policy
RPID CIPID
future
39
Privacy rules
• Conditions– identity, sphere– time of day– current location– identity as <uri> or <domain>
+ <except>
• Actions– watcher confirmation
• Transformations– include information– reduced accuracy
• User gets maximum of permissions across all matching rules– privacy-safe composition:
removal of a rule can only reduce privileges
• Extendable to new presence data– rich presence– biological sensors– mood sensors
40
Example rules document
<identity><id>[email protected]</id></identity>
<sub-handling>allow</sub-handling>
<provide-services> <service-uri-scheme>sip</service-uri-scheme> <service-uri-scheme>mailto</service-uri-scheme></provide-services><provide-person>true</provide-person><provide-activities>true</provide-activities><provide-user-input>bare</provide-user-input>
<ru
lese
t>
<rule id=1>
<co
ndit
ions>
<tr
ansf
orm
ati
on
s>
<act
ions>
41
Creating and manipulating rules
• Uploaded in whole or part via XCAP• XML not user-visible• Web or application UI, similar to mail filtering• Can also be location-dependent
– “if at home, colleagues don’t get presence information”
• Possibly implementation-defined “privacy levels”
Location-based services
43
Location-based services
• Finding services based on location– physical services (stores, restaurants, ATMs, …)– electronic services (media I/O, printer, display, …)– not covered here
• Using location to improve (network) services– communication
• incoming communications changes based on where I am
– configuration• devices in room adapt to their current users
– awareness• others are (selectively) made aware of my location
– security• proximity grants temporary access to local resources
44
Location-based SIP services
• Location-aware inbound routing– do not forward call if time at callee location is [11 pm, 8 am]– only forward time-for-lunch if destination is on campus– do not ring phone if I’m in a theater
• outbound call routing– contact nearest emergency call center– send [email protected] to nearest branch
• location-based events– subscribe to locations, not people– Alice has entered the meeting room– subscriber may be device in room our lab stereo changes
CDs for each person that enters the room
45
Location delivery
DHCP
HTTP
GPS
HELD
LLDP-MED
wiremap
46
Location-based service language
false
true
NOTIFY
action alert
conditions
proximity
occupancy
time
IM
actions
alert
message
log
call
transfer
join
events
incoming
outgoing
notify
message
subscription
47
Program location-based services
48
49 *) - Verizon Service Assurance Business Intelligence Toolkit
Application: Verizon SABIT PALS
• SABIT = web-based mobile employee productivity management system
• PALS - Presence-Aware Location-Based Service– Advanced communication services based on aggregation of
presence information– Enhanced vehicle management system
• Presence/availability information of a user is combined with the location information (of the vehicle) to achieve an integrated communication environment– “only call when vehicle is stopped”
50
SABIT PALS Solution
Integrates:
• Status and diagnostic information of the vehicle
• Mobile employee’s location data obtained from a GPS device in a vehicle
• Mobile employee’s presence information data obtained from his/her cell-phone
• Laptop-based IM/VoIP soft client
51
GPSEVDO
WiFi
VZ Data/Real TimeVZ VPN
Field Tech Laptop-Connect
via WiFi or Ethernet
Components of PALS architecture
• Integrated In-Vehicle Device (IIVD – Vehicle Events)
• SABIT System
• HTTP-SIP Gateway (LBS Presence User Agent)
• Media Server
• Watcher or Supervisor Application
• Presence Server (PS)
52
SABIT PALS Architecture
PUBLISH PresenceServer
NOTIFY
DB
MSC/HLR
SUBSCRIBE Watcher
Watcher
SABIT System
Mobile Employee’s status is relayed through multiple devices
EVDO
GPS
SIP Proxy
Systems View
DB
HTTP/ SIPGateway
HTTP
Location from vehicle
PUBLISH
Media ServerGateway
SABIT Supervisor “sees” mobile employees via the web-interface
53
SABIT PALS Supervisor Application
54
Communications Webpage
55
Roadmap
• Introduction
• Presence
• Location-based services
• Server scaling
• P2P SIP
• Standardization and interoperability
56
SIP server overload
• Proxies will return 503 --> retry elsewhere• Just adds more load• Retransmissions exacerbate the problem
overloaded
overloaded
overloaded
INVITE
503
Springsteen tickets!!earthquake
vote for your favorite…
57
Avalanche restart
• Large number of terminals all start at once• Typically, after power outage• Overwhelms registrar• Possible loss of registrations due to retransmission time-out
#300,000
#1
reboot afterpower outage
REGISTER
58
Overload control
• Current discussion in design team• Feedback control: rate-based or window-based• Avoid congestion collapse• Deal with multiple upstream sources
capacity
goodput
offered load
S5
S1
S2
S3
S4
UA
UA
59
Coordinated Overload Control Architecture
Sending Entity (SE) Receiving Entity (RE)
Load Sample
Feedback
Throttle
SIP SIP
Control Function
MonitorActuator
Control Function
Coordinated overload control with explicit feedback ietf-hilt draft model
SIP
Overload Control
Sending Entity (SE)
SIP
Overload Control
Overload Feedback
Overload DetectionOverload Enforcement
Receiving Entity (RE)
Feedback scope: explicit feedback treated hop-by-hop vs. end-to-end
hop-by-hop feedback is generally believed to be more feasible
60
Scaling servers & TCP
• Need TCP– TLS support: customer
privacy, theft of service, …• particularly for WiFi
– many SIP messages now exceed reasonable UDP size (fragmentation)
• e.g., INVITE for IMS: 1182 bytes
• Concern: UA support– improving: 82% of systems at
recent SIPit’19 had TCP support
– only 45% support TLS
• Concern: TCP (and TLS) much less efficient than UDP
– running series of tests to identify differences
– difference mainly in• connection setup cost
• message splitting (may need pre-parsing or incremental parsers)
• thread count (one per socket?)
• Our model: – 300,000 customers/servers
• 0.1 Erlang, 180 sec/call
– 600,000 BHCA --> 167 req/sec– 300,000 registrations --> 83
req/sec– $0.001/subscriber
61
SIP server measurements
• Initial INVITE measurements– OpenSER
– 400 calls/sec for TCP
– roughly 260 calls/sec for TLS
sipd REGISTER test
Kumiko Ono, Charles Shen, Erich Nahum
TCP
62
Roadmap
• Introduction
• Presence
• Location-based services
• Server scaling
• P2P SIP
• Standardization and interoperability
63
LAN
P2P SIP
• Why?– no infrastructure available: emergency
coordination– don’t want to set up infrastructure: small
companies– Skype envy :-)
• P2P technology for– user location
• only modest impact on expenses• but makes signaling encryption cheap
– NAT traversal• matters for relaying
– services (conferencing, …)• how prevalent?
• New IETF working group formed– likely, multiple DHTs– common control and look-up protocol?
P2P provider A
P2P provider B
p2p network
traditional provider
DNS
zeroconf
generic DHT service
64
P2P SIP -- components
• Multicast-DNS (zeroconf) SIP enhancements for LAN– announce UAs and their
capabilities
• Client-P2P protocol– GET, PUT mappings– mapping: proxy or UA
• P2P protocol– get routing table, join, leave, …– independent of DHT?– replaces DNS for SIP, not proxy
65
Zeroconf: solution for bootstrapping
• Three requirements for zero configuration networks:1) IP address assignment without a DHCP server
2) Host name resolution without a DNS server
3) Local service discovery without any rendezvous server
• Solutions and implementations:– RFC3927: Link-local addressing standard for 1)
– DNS-SD/mDNS: Apple’s protocol for 2) & 3)
– Bonjour: DNS-SD/mDNS implementation by Apple
– Avahi: DNS-SD/mDNS implementation for Linux and BSD
66
DNS-SD/mDNS overview
• DNS-Based Service Discovery (DNS-SD) adds a level of indirection to SRV using PTR:_daap._tcp.local. PTR Tom’s Music._daap._tcp.local._daap._tcp.local. PTR Joe’s Music._daap._tcp.local.
Tom’s Music._daap._tcp.local. SRV 0 0 3689 Toms-machine.local.
Tom’s Music._daap._tcp.local. TXT "Version=196613" "iTSh Version=196608" "Machine ID=6070CABB0585" "Password=true”
Toms-machine.local. A 160.39.225.12
• Multicast DNS (mDNS)– Run by every host in a local link– Queries & answers are sent via multicast– All record names end in “.local.”
1:n mapping
67
z2z: Zeroconf-to-Zeroconf interconnection
rendezvous point - OpenDHT
z2z
Import/exportservices
Zeroconf subnet A
z2z
Import/exportservices
Zeroconf subnet B
68
Demo: global iTunes sharing
• Exporting iTunes shares under key “columbia”:$ z2z --export:opendht _daap._tcp --key “columbia”
• Importing services stored under key “columbia”:$ z2z --import:opendht --key “columbia”
69
How z2z works (exporting)
OpenDHT
z2z
Send browse request (i.e., PTR query) for service type: _daap._tcp
1)
Tom’s Music._daap._tcp.local
Joe’s Music._daap._tcp.local
Send resolve request (i.e., SRV, A, and TXT query) for each service
2)
160.39.225.12Tom’s ComputerPassword=true……
160.39.225.13Joe’s ComputerPassword=false……
Export them by putting into OpenDHT
3)
put:key= z2z._daap._tcp.columbiavalue= Tom’s Music 160.39.225.12:3689 Password=true ……
70
How z2z works (importing)
OpenDHT
z2z
Issue get call into OpenDHT
1)
Add “A” record into mDNS
2)
Import services by registering them (i.e., add PTR, SRV, TXT records to the local mDNS)
3)
get:key=z2z._daap._tcp.columbiavalue=Tom’s Music
160.39.225.12:3689……
value=Joe’s Music…… mDNS
“A” record for 160.39.225.12
Tom’s Music._daap._tcp.local_remote-160.39.225.12.local……
71
z2z implementation
• C++ Prototype using xmlrpc-c for OpenDHT access– Proof of concept– Porting problem due to Bonjour and Cygwin incompatibility
• z2z v1.0 released – Rewritten in Java from scratch– Open-source (BSD license)– Available in SourceForge (https://sourceforge.net/projects/z2z)
• Paper describing design and implementation detail– z2z: Discovering Zeroconf Services Beyond Local Link
• Lee, Schulzrinne, Kellerer, and Despotovic
– Submitted to IEEE Globecom’07 Workshop on Service Discovery
72
Zeroconf for SIP
• Enable SIP communication when proxy and registrar are not available– Good use case for z2z– Fill in the gap of P2P-SIP effort:
• local & small scale (10s to 100s)• high mobility• avoid construction of DHT
• Internet Draft published and presented at IETF-68– SIP URI Service Discovery using DNS-SD
• Lee, Schulzrinne, Kellerer, and Despotovic• http://tools.ietf.org/html/draft-lee-sip-dns-sd-uri-01
73
SIP URI advertisement
• Example_sipuri._udp.local. PTR sip:[email protected]._sipuri._udp.local. _sipuri._udp.local. PTR sip:[email protected]._sipuri._udp.local. sip:[email protected]._sipuri._udp.local. SRV
0 0 5060 bobs-host.local. sip:[email protected]._sipuri._udp.local. TXT txtvers=1 name=Bob contact=sip:[email protected].
• Service instance name: Instance.Service.Domain– Instance = ( SIP-URI / SIPS-URI ) [ SP description ]– Service = “_sipuri._udp” / “_sipuri._tcp” / “_sipuri._sctp”– E.g.) sip:[email protected] - PDA._sipuri._udp.local.
• Contact TXT record attribute– Similar to Contact SIP header except:
• It contains only a single URI• Non-SIP URIs are not allowed
– UA capabilities advertised via field parameters (RFC3840)
Peer-to-Peer Protocol (P2PP)
Salman Abdul Baset, Henning SchulzrinneColumbia University
75
Overview
• Objective: key (opaque) data– distributed data structure with O(log N) or O(1) [rarely]
• Practical issues in peer-to-peer systems• Peer-to-peer systems
– file sharing– VoIP– streaming
• P2PSIP architecture• Peer-to-peer protocol (P2PP)• P2PP design issues• Implementation
76
Practical issues in peer-to-peer systems
• Bootstrap / service discovery
• NAT and firewall traversal• TCP or UDP?
• Routing-table management• Operation during churn
• Availability and replication
• Identity and trust management
77
Peer-to-peer systems
File sharing VoIP Streaming
Low
Medium
High
NAT
NAT
NAT
Data size
Data size
Data size
Pe
rfo
rman
ce im
pa
ct /
req
uire
me
nt
Service discovery
Replication
Replication
Replication
78
P2PSIP: Concepts
• Decentralized SIP– Replace SIP proxy and registrar with p2p
endpoints
• Supernode architecture– P2PSIP peers
• participate in the p2p overlay
– P2PSIP clients• use peers to locate users and resources
79
P2PSIP architecture
SIP
P2P STUN
TLS / SSL
A peer in P2PSIP
NAT
NAT
A client
[ Bootstrap / authentication server ]
Overlay1
Overlay2
80
Peer-to-Peer Protocol (P2PP)
• P2P applications have common requirements such as discovery, NAT traversal, relay selection, replication, and churn management.
• Goals– A protocol to potentially implement any structured or unstructured
protocol.– Not dependent on a single DHT or p2p protocol
• Not a new DHT!
• It is hard!– Too many structured and unstructured p2p protocols– Too many design choices!
• Lets consider DHTs
81
DHTs
DHT GeometryDistance function
Lookup correctness
(neighbor table)
Lookup performance
(routing table)
ChordAccordion
RingModulo numeric
differenceSuccessor list Finger table
Tapestry, Pastry,
Bamboo
Hybrid =
Tree + Ring
Prefix match. If fails, then modulo
numeric difference
Leaf-set (Pastry) Routing table
Kademlia XOR XOR of two IDs None Routing table
82
Kademlia
XOR
Finger table
Parallel requests
Recursive routing Pastry
Bamboo
ChordSuccessor
Modulo additionPrefix-match
Leaf-set
Routing-table stabilization
Lookup correctness
Lookup performanceProximity neighbor selection
Proximity route selection
Routing-table size
Strict vs. surrogate routing
OneHop
Bootstrapping
Updating routing-table from lookup requests
Tapestry Ring
Tree
HybridReactive recovery
Periodic recovery Accordion
Routing-table exploration
83
How to design P2PP?
• Structured– Identify commonalities in DHTs
• Routing table (finger table)• Neighbor table (successor list, leaf-set)
– Separate core routing mechanisms from from DHT-independent issues.• Unstructured
– may not always find all keys• Incorporate mechanisms for
– discovery– NAT / firewall traversal– churn, identity and trust management– request routing (recursive / iterative / parallel)
84
Parallel requests
Recursive routing
Routing-table stabilization
Proximity neighbor selection
Proximity route selection
Bootstrapping
Reactive vs. periodic recovery
DHT-independent
Kademlia
XOR
Pastry
Bamboo Chord
Modulo addition
Prefix-match
OneHop
Tapestry
Ring
Tree
Hybrid
DHT-specific
Accordion
Finger table / routingtable
Successor / leaf-set
Lookup correctness
Lookup performance
Routing-table size
Strict vs. surrogate routing
Updating routing-table from lookup requests
DHT-specific Not restricted toone DHT
Routing-table exploration
Geometry
How to design P2PP?
85
Chord (Strict routing-table management)
Neighbor table(successor)
Node
x+2i
x+2i+1
x+2i+2
x+2i+3
id=x
Routing table
Immediately succeeds routing-table id
86
Peer-to-Peer Protocol (P2PP)
• A binary protocol• Geared towards IP telephony but equally applicable to file sharing,
streaming, and p2p-VoD• Multiple DHT and unstructured p2p protocol support• Application API• NAT traversal
– using STUN, TURN and ICE– ICE encoding in P2PP
• Request routing– recursive, iterative, parallel– per message
• Supports hierarchy (super nodes [peers], ordinary nodes [clients])• Reliable or unreliable transport (TCP or UDP)
87
Peer-to-Peer Protocol (P2PP)
• Security– DTLS, TLS, signatures
• Multiple hash function support– SHA1, SHA256, MD4, MD5
• Diagnostics– churn rate, messages sent/received
• Node capabilities– bw determination, CPU utilization, number of neighbors, mobility
88
Join
JP BS P5 P71. Query
2. 200
P5, P30, P2P-Options
4. Join
9. 200
N(P9, P15)
5. Join
7. 200
P9
JP(P10)
8. Join
6. 200
N(P9, P15)
10. Transfer
11. 200
3+. STUN (ICE candidate gathering)
89
Call establishment
P1 P3 P5 P71. Lookup-Peer (P7)
5. 200 (P7 Peer-Info)
2. Lookup-Peer (P7) 3. Lookup-Peer (P7)
4. 200 (P7 Peer-Info)
6. 200 (P7 Peer-Info)
7. INVITE
8. 200 Ok
9. ACK
Media
90
Implementation
• Chord, Kademlia, Bamboo (in-progress)• SHA1, SHA256, MD5, MD4• Windows, Linux• Integrated with OpenWengo (VoIP phone)
• Available for download (Linux + Windows)http://www1.cs.columbia.edu/~salman/p2pp/setupp2pp.html
91
Implementation
Transport / timers
Node
BigInt
Parser / encoder
UDP TCP
Transactions
ClientBootstrap ChordPeer KadPeer OtherPeer
Sys
insert (key, value, callback)callback (resp)
lookup (key, callback)
Routing table
Neighbor table
Distance
92
Screen snapshot
• Alice and Bob are part of Kademlia network
• Alice calls Bob• The lookup is
performed using P2PP
• Call is established using SIP
93
P2P summary
• P2P techniques now becoming mainstream– motivated by low opex, ease of deployment– building block, rather than application
• Many operational issues– interconnection: z2z– local peering: Bonjour for SIP– start-up and recovery: cf. Skype failure
• P2PP: Common platform protocol– application-neutral– extensible mechanism
94
Roadmap
• Introduction
• Presence
• Location-based services
• Server scaling
• P2P SIP
• Standardization and interoperability
95
SIP, SIPPING & SIMPLE –00 drafts
includes draft-ietf-*-00 and draft-personal-*-00
0
10
20
30
40
50
60
70
80
19992000200120022003200420052006
SIPSIPPINGSIMPLE
96
RFC publication
0
2
4
6
8
10
12
14
2001 2002 2003 2004 2005 2006
SIPSIPPINGSIMPLE
97
IETF WG: SIP in 2006 & 2007
• ~ 44 SIP-related RFCs published in 2006– BFCP, conferencing – SDP revision– rich presence
• Activities:– hitchhiker’s guide– infrastructure:
• GRUUs (random identifiers)• URI lists• XCAP configuration• SIP MIB
– services:• rejecting anonymous requests• consent framework• location conveyance• session policy
– security:• end-to-middle security• certificates• SAML• sips clarification
– NAT:• connection re-use• SIP outbound• ICE (in MMUSIC)
see http://tools.ietf.org/wg/sip’/
98
IETF WG: SIPPING
• 31 RFCs published in 2006• Policy
– media policy
– SBC functions
• Services– service examples
– call transfer
– configuration framework
– spam and spit
– text-over-IP
– transcoding
• Testing and operations– IPv6 transition
– race condition examples
– IPv6 torture tests
– SIP offer-answer examples
– overload requirements
– configuration
– voice quality reporting
99
Interoperability
• Generally no interoperability problems for basic SIP functionality– basic call, digest registration (mostly...), call transfer, voice mail
• Weaker in advanced scenarios and backward compatibility– handling TCP, TLS– NAT support (symmetric RTP, ICE, STUN, ...)– multipart bodies– SIP torture tests– call transfer, call pick-up– video and voice codec interoperability (H.264, anything beyond G.711)
• SIPit useful, but no equivalent of WiFi certification– most implementations still single-vendor (enterprise, carrier) or vendor-
supplied (VSP)– SFTF (test framework) still limited
• Need profiles to guide implementers
SIPREAL BOFat IETF 70?
100
Trouble in Standards Land
• Proliferation of transition standards: 2.5G, 2.6G, 3.5G, …
– true even for emergency calling…
• Splintering of standardization efforts across SDOs
– primary:• IEEE, IETF, W3C, OASIS, ISO
– architectural:• PacketCable, ETSI, 3GPP, 3GPP2, OMA,
UMA, ATIS, …
– specialized:• NENA
– operational, marketing:• SIP Forum, IPCC, …
OASIS
IEEE
IETF
W3CISO (MPEG)
L2.5-L7protocols
dataexchange
dataformats
L1-L2
3G
PP
Pack
etC
abl
e
101
IETF issues
• SIP WGs: small number (dozen?) of core authors (80/20)
– some now becoming managers…– or moving to other topics
• IETF: research engineering maintenance
– many groups are essentially maintaining standards written a decade (or two) ago
• DNS, IPv4, IPv6, BGP, DHCP; RTP, SIP, RTSP
• constrained by design choices made long ago
– often dealing with transition to hostile & “random” network
– network ossification
• Stale IETF leadership– often from core equipment
vendors, not software vendors or carriers
• fair amount of not-invented-here syndrome
• late to recognize wide usage of XML and web standards
• late to deal with NATs• security tends to be per-protocol
(silo)– some efforts such as SAML and
SASL
• tendency to re-invent the wheel in each group
102
IETF issue: timeliness
• Most drafts spend lots of time in 90%-complete state
– lack of energy (moved on to new -00)– optimizers vs. satisfiers
• multiple choices that have non-commensurate trade-offs
• Notorious examples:– SIP request history: Feb. 2002 – May
2005 (RFC 4244)– Session timers: Feb. 1999 – May 2005
(RFC 4028)– Resource priority: Feb. 2001 – Feb
2006 (RFC 4412)• New framework/requirements phase
adds 1-2 years of delay• Three bursts of activity/year, with
silence in-between– occasional interim meetings
• IETF meetings are often not productive
– most topics gets 5-10 minutes lack context, focus on minutiae
– no background same people as on mailing list
– 5 people discuss, 195 people read email
• No formal issue tracking– some WGs use tools, haphazardly
• Gets worse over time:– dependencies increase,
sometimes undiscovered– backwards compatibility issues– more background needed to
contribute
103
IETF issues: timeliness
• WG chairs run meetings, but are not managing WG progress– very little control of deadlines
• e.g., all SIMPLE deadlines are probably a year behind– little push to come to working group last call (WGLC)– limited timeliness accountability of authors and editors– chairs often provide limited editorial feedback
• IESG review can get stuck in long feedback loop– author – AD – WG chairs– sometimes lack of accountability (AD-authored documents)
• RFC editor often takes 6+ months to process document– dependencies; IANA; editor queue; author delays– e.g., session timer: Aug. 2004 – May 2005
104
Conclusion
• Even after 10+ years, VoIP mostly still “cheaper calls”• New services and models:
– (rich) presence– location-based services– user-programmable services– P2P SIP
• Scaling to carrier-scale and under duress• Current standardization processes slow and complexity-
inducing
