Upload
seanna
View
31
Download
0
Embed Size (px)
DESCRIPTION
VoIP - beyond replicating the limitations of the past. Henning Schulzrinne Dept. of Computer Science, Columbia University, New York - PowerPoint PPT Presentation
Citation preview
VoIP - beyond replicating the limitations of the past
Henning SchulzrinneDept. of Computer Science, Columbia University, New York
(based on work in collaboration with IRT students including Salman Baset, Jae Lee, Kundan Singh, Xiaotao Wu, Jonathan Lennox, Vishal Singh & staff, as well as the IETF SIP,
GEOPRIV and SIMPLE WGs)
Oracle
October 30, 2007
Oct. 2007 2
Outline
• VoIP maturing: vision vs. reality• Advanced VoIP services
– user-programmable services– presence and location-based services– peer-to-peer systems
• VoIP challenges– scaling– spam/SPIT– emergency calling– complexity & interoperability
Oct. 2007 3
The three Cs of Internet applications
communications communitycommerce
grossly simplified...
researchfocus
what users care aboutwhat users care about
Oct. 2007 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
Oct. 2007 5
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
Oct. 2007 6
IETF VoIP efforts
SIP(protocol)
BLISS(common services)
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)
usesSIPPING(usage, requirements)
P2PSIP(peer-to-pper)
Oct. 2007 7
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
Oct. 2007 8
SIP Overview
Oct. 2007 9
Internet services – the missing entry
Service/delivery synchronous asynchronous
push instant messaging
presence
event notification
session setup
media-on-demand
messaging
pull data retrieval
file download
remote procedure call
peer-to-peer file sharing
Oct. 2007 10
Filling in the protocol gap
Service/delivery synchronous asynchronous
push SIP
RTSP, RTP
SMTP
pull HTTP
ftp
SunRPC, Corba, SOAP
(not yet standardized)
Oct. 2007 11
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
Oct. 2007 12
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• Verizon FiOS, Vonage, Yahoo, ...
Oct. 2007 13
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
Oct. 2007 14
Basic SIP message flow
Oct. 2007 15
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)
Oct. 2007 16
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]: 1 INVITESubject: just testingContact: sip:[email protected]: application/sdpContent-Length: 147
v=0o=alice 2890844526 2890844526 IN IP4 here.coms=Session SDPc=IN IP4 100.101.102.103t=0 0m=audio 49172 RTP/AVP 0a=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]: 1 INVITESubject: just testingContact: sip:[email protected]: application/sdpContent-Length: 134
v=0o=bob 2890844527 2890844527 IN IP4 there.coms=Session SDPc=IN IP4 110.111.112.113t=0 0m=audio 3456 RTP/AVP 0a=rtpmap:0 PCMU/8000m
essa
ge b
ody
head
er fi
elds
requ
est l
ine
request response
Oct. 2007 17
PSTN vs. Internet Telephony
Signaling & Media Signaling & Media
Signaling Signaling
Media
PSTN:
Internettelephony:
China
Belgian customer,currently visiting US
Australia
Oct. 2007 18
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.17via NAPTR + SRV
Oct. 2007 19
3G Architecture (Registration)
visited IM domain
home IM domain
servingCSCF
interrogating
proxy
interrogating
mobility managementsignaling
registration signaling (SIP)_
Oct. 2007 20
SIP is PBX/Centrex ready
call waiting/multiple calls RFC 3261
hold RFC 3264
transfer RFC 3515/Replaces
conference RFC 3261/callee caps
message waiting message summary package
call forward RFC 3261
call park RFC 3515/Replaces
call pickup Replaces
do not disturb RFC 3261
call coverage RFC 3261
from Rohan Mahy’s VON Fall 2003 talk
simultaneous ringing RFC 3261
basic shared lines dialog/reg. package
barge-in Join
“Take” Replaces
Shared-line “privacy” dialog package
divert to admin RFC 3261
intercom URI convention
auto attendant RFC 3261/2833
attendant console dialog package
night service RFC 3261
centr
ex-s
tyle
featu
res
boss/admin features
attendant features
Oct. 2007 21
SIP – a bi-cultural protocol
• overlap dialing• DTMF carriage• key systems• notion of lines• per-minute billing• early media• ISUP & BICC interoperation• trusted service providers
• multimedia• IM and presence• location-based service• user-created services• decentralized operation• everyone equally suspect
Service Creation
Oct. 2007 23
Overview
• Communication services and where to run the services• Call Processing Language (CPL)• End system services
– Programmable – Service creation– Analyzable – Feature interaction handling– Intelligent – Feature learning– Ubiquitous – Context-based services
• Implementations
Oct. 2007 24
Where to run services?
Internet
Oct. 2007 25
Service creation
programmer, carrier end user
network servers SIP servlets, sip-cgi, echarts
CPL
end system VoiceXML VoiceXML (voice),
LESS
• Tailor a shared infrastructure to individual users• traditionally, only vendors (and sometimes carriers)• learn from web models
Oct. 2007 26
Call Processing Language (CPL)
• XML-based “language” for processing requests• intentionally restricted to branching and subroutines• no variables (may change), no loops• thus, easily represented graphically
– and most bugs can be detected statically
– termination assured
• mostly used for SIP, but protocol-independent• integrates notion of calendaring (time ranges)• structured tree describing actions performed on call setup event• top-level events: incoming and outgoing
Oct. 2007 27
CPL
• Location set stored as implicit global variable– operations can add, filter and delete entries
• Switches:– address– language– time, using CALSCH notation (e.g., exported from Outlook)– priority
• Proxy node proxies request and then branches on response (busy, redirection, noanswer, ...)
• Reject and redirect perform corresponding protocol actions
• Supports abstract logging and email operation
Oct. 2007 28
CPL example
String-switchfield: from
match:*@example.com
otherwise
proxytimeout: 10s
locationurl: sip:jones@
example.comvoicemail.
merge: clear
locationurl: sip:jones@
example.com
redirect
Call
busy
timeout
failure
Oct. 2007 29
CPL example
<?xml version="1.0" ?><!DOCTYPE call SYSTEM "cpl.dtd">
<cpl> <incoming> <lookup source="http://www.example.com/cgi-bin/locate.cgi?
user=jones" timeout="8"> <success> <proxy /> </success> <failure> <mail url="mailto:[email protected]&Subject=lookup
%20failed" /> </failure> </lookup> </incoming></cpl>
Oct. 2007 30
Service creation environment for CPL and LESS
Oct. 2007 31
Run services on end systems
End devices End servers Net UAs Proxy Back-to-back user agent
Number of users Call states
Media ?
Number of devices User interaction
Direct Indirect* Indirect Indirect Indirect
Managing End user End user Admin. Admin. Admin.
IPTS ‘00
Oct. 2007 32
End system service programming
• What do we need?– A language and a tool
• End system service creation language– Easy to understand– Automatic service creation– Portable
• Create once, run on different devices
– Easy to manage• Facilitate feature interaction handling
– CPL, CCXML, APPEL, SPL…
Oct. 2007 33
How to represent services?
• ECA (event – condition – action)
Natural thinking of a decision making – a policy/rule set
When I am in a conference, I will vibrate my device for my boss’s calls and reject all the other calls.
Using decision trees to represent policy/rule sets(O(logN) execution time)
For an incoming call
If I am in a conference
Vibratemy device
Rejectthe call
YES
YES
NO
If the call is from my boss
Oct. 2007 34IEEE ICC’03RFC3880
Use LESS effort to create more services
• LESS: Language for End System Services – CPL: Call Processing Language (Jonathan, Henning, and myself)
• Simplicity– Four kinds of elements: trigger, switch, action, modifier– Tree-like structure, easy for feature interaction analysis
• Safety– Type safety: XML-based, no user defined variables– Control flow safety: tree-like structure without back-reference– No direct memory access– Default behavior for every tree branch
• Portability• Handle user interactions and media operations• Extensibility
– not just new elements, but can apply existing algorithms
Oct. 2007 35
LESS elements
trigger an incoming call
switch
check the caller
switchcheck time
switch
check priority
action
redirect
action
accept
action
reject
modifier
to Bob
= ≠
= ≠ ≠
Oct. 2007 36
CUTE (Columbia University Telecommunication service Editor)
Oct. 2007 37
Use CUTE to create services
0%
20%
40%
60%
80%
100%
Overall Group 1 Group 2 Group 3
Group
Percentage ofparticipants
Other
Don't know how
Some difficulties
Easily
Very comfortable
Survey on end user service creation
Group1: IRT members, Group2: CS undergraduates, Group3: Other people85% would like to create their own services,
90% like to use CUTE to create services90% can correctly create service-1, 65% srv-2, 80% srv-3, 65% easy to understand LESS code
Oct. 2007 38
ring
ring
What is FI and how to handle it?
• Tree merging
+ =If time is between
10:00AM and 11:00AMIf address is hgs
Forward to conf
Incoming call Incoming call
Incoming call
If time is between 10:00AM and 11:00AM
If address is hgs
rejectForward to conf
rejectaccept
Take actions from both scripts. Simply setting precedence rules cannot work.
Oct. 2007 39
FI handling for LESS
• Action conflict tables– Services conflict only if their actions conflict
• Tree merging algorithm– Detect and help to resolve
• Resolve conflicts
ICFI’05 (FIW)JCN
Oct. 2007 40
Pre-condition and expected results
pre-condition expected results
accept Call setup pending.
Audio device available.
Call setup is finalize.
Session is setup.
Audio device busy.
reject Call setup pending. Call setup finalized.
redirect Call setup pending. Call setup finalized on current UA.
call Audio device available. If callee accepts call, session is setup, audio device is busy.
Oct. 2007 41
Action conflict table
accept reject redirect call
accept A(media) C C R
reject C A(reason) C -
redirect C C A(target) -
call R - - A(target)
-: no interaction, A: attribute conflict, C: action conflict,E: enabling, R: resource competition
Oct. 2007 42
Resolving interactions
condition
decision
options withlower risks
Oct. 2007 43
No idea about services?
• Learning burden caused by new services– What and how– Help, not bypass
• Causal relationship between call information and call decisions– SIP headers– Different information sources– Examples
• Spam filtering, calendar-based services
Oct. 2007 44
What (learn from), what (generate), how
• Users’ communication history – LESS decision trees – decision tree induction
– find switches that can best partition actions
• Algorithm– Incremental– Prune– Quality measurement
30*3+10*2+7=117 30*2+3*2+10*3+4*3=108
Oct. 2007 45
Incremental Tree Induction
• Incremental– Incorporating– Transposition
• Virtual prune• Direct metrics
– Expected number of tests– Leaf counts– Minimum description length– Expected misclassification cost
address=a1
time=t1 time=t1
B DCA
Y N
Y N Y N
time=t1
address=a1 address=a1
A DCB
Y N
Y N Y N
Oct. 2007 46
Simulation
40 servicesEach for 300 calls80% match10% different way10% mismatch
Oct. 2007 47
Performance
Fast vs. incremental (20 samples) training
IBM ThinkPad, Linux 1GHz PIII Mobile256MB memory
Oct. 2007 48
How to handle service risks?
• Identify– Lose connection: reject, redirect, transfer, accept on wrong branch
– Lose privacy: accept, call, notify
– Lose money: accept, transfer to higher rate endpoint
– Lose attention: alert, accept, appliance control
• Analyze– Possibility: number of occurrence in the decision tree
– Impact: (connection, privacy) > money > attention, customizable
• Resolve– Change communication methods– Change communication targets– Reduce overall risk: avoiding high impact risks, though may cause low impact risks
• Contingency plan– Backup
Presence and event notification
Oct. 2007 50
Event notification as service enabler
• 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
Oct. 2007 51
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
parameter used by
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
Oct. 2007 52
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
Oct. 2007 53
GEOPRIV and SIMPLE architectures
targetlocationserver
locationrecipient
rulemaker
presentity
caller
presenceagent
watcher
callee
GEOPRIV
SIPpresence
SIPcall
PUBLISHNOTIFY
SUBSCRIBE
INVITE
publicationinterface
notificationinterface
XCAP(rules)
INVITE
DHCP
Oct. 2007 54
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
Oct. 2007 55
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
Oct. 2007 56
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
Oct. 2007 57
Presence data architecture
candidatepresencedocument
watcherfilter
rawpresencedocument
post-processingcomposition(merging)
finalpresencedocument
differenceto previous notification
SUBSCRIBE
NOTIFY
remove data not of interest
watcher
Oct. 2007 58
Presence data model
“calendar” “cell” “manual”
[email protected], video, text
person(presentity)
(views)
services
devices
Oct. 2007 59
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, …)
Oct. 2007 60
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
Oct. 2007 61
RPID: rich presence
<person> <tuple> <device>
<activities>
<class>
<mood>
<place-is>
<place-type>
<privacy>
<relationship>
<service-class>
<sphere>
<status-icon>
<time-offset>
<user-input>
Oct. 2007 62
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
Oct. 2007 63
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
Oct. 2007 64
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>
Oct. 2007 65
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
Oct. 2007 66
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>
Oct. 2007 67
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
Oct. 2007 69
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
Oct. 2007 70
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
Oct. 2007 71
Location delivery
DHCP
HTTP
GPS
HELD
LLDP-MED
wiremap
Oct. 2007 72
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
Oct. 2007 73
Program location-based services
Oct. 2007 74
Oct. 2007 75 *) - 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”
Oct. 2007 76
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
Oct. 2007 77
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)
Oct. 2007 78
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
Oct. 2007 79
SABIT PALS Supervisor Application
Oct. 2007 80
Communications Webpage
Server scaling
Oct. 2007 82
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…
Oct. 2007 83
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
Oct. 2007 84
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
Oct. 2007 85
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
Oct. 2007 86
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
Oct. 2007 87
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
Oct. 2007 88
Roadmap
• Introduction
• Service creation
• Presence
• Location-based services
• Server scaling
• P2P SIP
Oct. 2007 89
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
Oct. 2007 90
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
Oct. 2007 91
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
Oct. 2007 92
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
Oct. 2007 93
z2z: Zeroconf-to-Zeroconf interconnection
rendezvous point - OpenDHT
z2z
Import/exportservices
Zeroconf subnet A
z2z
Import/exportservices
Zeroconf subnet B
Oct. 2007 94
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”
Oct. 2007 95
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 ……
Oct. 2007 96
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……
Oct. 2007 97
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
Oct. 2007 98
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
Oct. 2007 99
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
Oct. 2007 101
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
Oct. 2007 102
Practical issues in p2p systems
• Bootstrap / service discovery• NAT and firewall traversal• TCP or UDP?• Routing-table management• Operation during churn• Availability and replication• Identity and trust management
Oct. 2007 103
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
Oct. 2007 104
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
Oct. 2007 105
P2PSIP architecture
SIP
P2P STUN
TLS / SSL
A peer in P2PSIP
NAT
NAT
A client
[ Bootstrap / authentication server ]
Overlay1
Overlay2
Oct. 2007 106
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
Oct. 2007 107
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
Oct. 2007 108
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
Oct. 2007 109
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)
Oct. 2007 110
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?
Oct. 2007 111
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
Oct. 2007 112
Peer-to-Peer Protocol (P2PP)
• 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)
Oct. 2007 113
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
Oct. 2007 114
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)
Oct. 2007 115
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
Oct. 2007 116
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
Oct. 2007 117
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
Oct. 2007 118
OpenWengo implementation
• Alice and Bob are part of Kademlia network
• Alice calls Bob• The lookup is
performed using P2PP
• Call is established using SIP
Oct. 2007 119
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
Oct. 2007 120
Conclusion
• Even after 10+ years, VoIP mostly still “cheaper calls”• New services and models:
– user-programmable services– (rich) presence– location-based services– P2P SIP
• Scaling to carrier-scale and under duress• Current standardization processes slow and complexity-
inducing
Backup slides
Oct. 2007 122
Timer triggered outgoing call <?xml version="1.0" encoding="UTF-8"?>
<less xmlns="urn:ietf:params:xml:ns:less“
xmlns:IM="urn:ietf:params:xml:ns:less:im“
xmlns:xsi=“…" xsi:schemaLocation=“…">
<timer dtstart="20050307T110000Z">
<status-switch uri="sip:[email protected]"
status-name="presence">
<status is="open">
<location url="sip:[email protected]">
<call>
<busy>
<location url="sip:[email protected]">
<IM:sendmsg>
Hi, please call me back. I am in office
</IM:sendmsg>
</location>
…………….
Oct. 2007 123
LESS elements (triggers)
• Triggers– incoming: incoming call handling– outgoing: user invoked outgoing call – timer: timer triggered actions– UI:command: user interaction commands– IM:message: incoming instant messaging– Event:subscription: incoming subscription– Event:notification: incoming notification
Oct. 2007 124
LESS elements (switches)
• Switches– time-switch: make decisions based on time– address-switch: make decisions based on caller, callee– priority-switch: make decisions based on call priority– string-switch: make decisions based on subject, …– language-switch: make decisions based on languages– status-switch: make decisions based on users’ status (remote user or
local user, status includes presence, activity, mood, …, as listed in RPID)
– Event:event-switch: check values in event notifications– LOC:where-switch: check users’ physical location information
(remote or local user)– LOC:where-relation-switch: check relative physical locations between
two people
Oct. 2007 125
LESS elements (actions)
• Actions– accept: accept an incoming call– reject: reject an incoming call– redirect: redirect an incoming call– authenticate: authenticate an incoming request– call: make an outgoing call– terminate: disconnect a call– wait: wait for a certain time before next
action
– mail: send email– log: log request handling process– Media:mediaupdate: update media attributes– Midcall:transfer: transfer a call
– Midcall:merge: merge multiple calls– UI:alert: alert user– UI:getinput: get user input– IM:sendmsg: send an instant message– Event:approve: approve subscription– Event:deny: deny event subscription– Event:defer: defer the decision on event
subscription
– Event:subscribe: send subscription out– Event:notify: send notification out– Queue:enqueue: put a call and its context into a
queue
– Queue:dequeue: get a call and its context from a queue
Oct. 2007 126
LESS elements (modifiers)
• Two smaller concepts might be simpler and more flexible than one more powerful but complicated concept
• Modifiers– location: to which a request to be directed– lookup: lookup locations from a source– remove-location: remove locations from location set– Media:media: provide media attributes
Oct. 2007 127
Oct. 2007 128
LESS script customization
xsl:if
LESS editor
service.less(template)
XSLT
less.xsl
configurationeditor
service.html
translate.cgi
service_foo.less
address is=$var
Oct. 2007 129
LESS elements
Oct. 2007 130
Example: Automatic Call Back (ACB)
<less xmlns="urn:ietf:params:xml:ns:less“ xmlns:Event="urn:ietf:params:xml:ns:less:event“ xmlns:Queue="urn:ietf:params:xml:ns:less:queue“ xmlns:xsi=“….“ xsi:schemaLocation=“……"><incoming> <status-switch status-name=“activity”> <status is=“on-the-phone"> <reject reason=“busy”> <next> <Queue:enqueue queue="callback"/> </next> </reject> </status> </status-switch></incoming>
In ITU Q.1211
“This feature allows the called party to automatically call back the calling party of the last call directed to the called party.”
Check my activity for an incoming call
Use Event and Queue extension
If I am on-the-phoneReject and enqueue
Oct. 2007 131
<Event:notification> <address-switch field="origin"> <address uri="{agent.uri}"> <Event:event-switch> <Event:event package=“presence" name=“activity" is=“normal"> <Queue:dequeue queue="callback"> <Queue:success> <call/> </Queue:success> </Queue:dequeue> </Event:event> </Event:event-switch> </address> </address-switch> </Event:notification></less>
A event notification for myself
I am available
Dequeue and make a call
Automatic Call Back (ACB) (cont.)
Oct. 2007 132
Oct. 2007 133
<?xml version="1.0"?><less> <incoming> <address-switch field="origin"> <address is="sip:[email protected]"> <accept/> </address> <otherwise> <location url="sip:[email protected]"> <redirect/> </location> </otherwise> </address-switch> </incoming></less>
Oct. 2007 134
Rich signaling information
• Rich signaling information– SIP headers– Caller preference and callee capabilities– MIME contents– Event notification– Other means
• Web calendar, Directory services
Oct. 2007 135
Rich services
• Be able to handle services in PSTN networks– ITU Q.1211
• ABD, ACB, CFC, CHA, QUE, CRG, OCS, …– Services in 5ESS switches
• Attendant camp-on, Automatic recall, …– Services in CSTA Phase III
• defined as signaling actions in LESS, e.g., mediaupdate– Emergency
• provide location information
• New services– Interact with existing Internet services
• web, email, SLP, SAP, IM, presence, location, networked appliance control, directory service, calendar service, conferencing
– Not named services, but programmable services– Programmable conferencing services
Oct. 2007 136
Definition
• What is service learning– Automatically generate user desired services– Help users, not bypass users– Services on both proxy servers and end systems
• What is service risk management– Risk caused by automation– How to reduce the overall risks
IEEE ICC’05
Oct. 2007 137
Decision tree induction
• Entropy: -Σ P log2P – 30 rejects, 17 accepts
-30/47*log2(30/47)-17/47*log2(17/47) = 0.944087
– Split on caller=Bob-30/33*log2(30/33)-3/33*log2(3/33)-14/14*log2(14/14) = 0.439497
• Information gain: entropy change after splitting– Information gain on the splitting is 0.50459
Oct. 2007 138
Decision tree induction
• Find the splitting that can get the largest information gain• Repeat for all sub-trees until no more information gain• Noisy data and prune
– Splitting causes higher error
Oct. 2007 139
Why not just a service creation tool
• Portability– Java and scripting languages are also “portable”
• “I am happy to see a piece of technology that works so well that I’m free to ignore its inner details.”– Maybe not some complicated work
• ”I also want to have the low-level innards visible, controllable when possible, and modifiable by anyone who’s willing and able to do that work.”– Lower the bar for understanding the low-level innards