Transcript invite - Columbia University

Moving VoIP beyond the
phone
Henning Schulzrinne
Dept. of Computer Science
Columbia University
September 2005
Overview


The big transitions in VoIP
Voice, media  meta data


Programmable VoIP services



servers and end systems
Spam and spit
Emergency calling (“9-1-1”)


rich presence, caller preferences, events, …
beyond PSTN replacement
Maintaining reliable systems

administratively distributed systems
September 2005
2
Philosophy transition
One computer/phone,
many users
mainframe era
home phone
party line
PC era
cell phone era
One computer/phone,
one user
Many computers/phones,
one user
~ ubiquitous computing
 embedded VoIP
anywhere,
any time
any media
September 2005
right place (device),
right time,
right media
3
Collaboration in transition
inter-organization
multiple
technology
generations
diverse end points
intra-organization;
small number of
systems (meeting
rooms)
standards-based
solutions
proprietary (singlevendor) systems
September 2005
4
Evolution of VoIP
“how can I make it
stop ringing?”
long-distance calling,
ca. 1930
“amazing – the
phone rings”
1996-2000
September 2005
“does it do
call transfer?”
going beyond
the black phone
catching up
with the digital PBX
2000-2003
20045
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
September 2005
6
Filling in the protocol gap
Service/delivery
synchronous
asynchronous
push
SIP
RTSP, RTP
SMTP
pull
HTTP
ftp
SunRPC, Corba, SOAP
(not yet standardized)
September 2005
7
An eco system, not just a
protocol
configures
XCAP
(config)
SIMPLE
XCON
(conferencing)
policy
RPID
….
initiates
SIP
RTSP
SDP
carries
provide addresses
controls
RTP
September 2005
carries
STUN
TURN
8
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
September 2005
• multimedia
• IM and presence
• location-based service
• user-created services
• decentralized operation
• everyone equally suspect
9
SIP is PBX/Centrex ready
centrex-style features
boss/admin features
call waiting/multiple RFC 3261
calls
simultaneous
ringing
RFC 3261
hold
RFC 3264
basic shared lines
dialog/reg. package
transfer
RFC 3515/Replaces
barge-in
Join
conference
RFC 3261/callee caps
“Take”
Replaces
message waiting
message summary
package
Shared-line
“privacy”
dialog package
call forward
RFC 3261
divert to admin
RFC 3261
call park
RFC 3515/Replaces
intercom
URI convention
call pickup
Replaces
auto attendant
RFC 3261/2833
do not disturb
RFC 3261
attendant console
dialog package
call coverage
RFC 3261
night service
RFC 3261
attendant features
from Rohan Mahy’s VON Fall 2003 talk
September 2005
10
SIP design objectives

new features and services



not a PSTN replacement





clients can be smart or dumb (terminal adapter)
mobile or stationary
hardware or software
client multiplicity


not just SS7-over-IP
even similar services use different models (e.g., call transfer)
client heterogeneity


support features not available in PSTN
e.g., presence and IM, session mobility
one user – multiple clients – one address
multimedia

nothing in SIP assumes a particular media type
Rosenberg/Schulzrinne: draft-rosenberg-sipping-sip-arch-00
September 2005
11
Interconnection approaches
Property
NGN, 3GPP
“Internet”
interconnection
per service
service neutral
end device control
carrier-controlled
user-provided
end device type
mostly hardware
software, maybe hardware
state preference
call state-full
stateless
transaction-stateful
interconnect
arrangement
pre-arranged
serendipitous
interconnect discovery
pre-configured
DNS
billing preference
per service
usage-based
bandwidth-based
services fixed-rate or adsupported
billing arrangement
clearing house
sender keeps
independent
September 2005
12
The role of presence

Guess, ring and annoy

high probability of failure:




current solutions:



“telephone tag”
inappropriate time (call during
meeting)
inappropriate media (audio in
public place)
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
September 2005
13
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
September 2005
14
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, Google, Skype presence services:

on-line & off-line



useful in modem days – but many people are (technically) online 24x7
thus, need to provide more context
+ simple status (“not at my desk”)



entered manually  rarely correct
if user has time to update presence, they are not busy enough to
use presence
does not provide enough context for directing interactive
communications
September 2005
15
Presence data model
person
“calendar”
“cell”
“manual”
(presentity)
(views)
[email protected]
audio, video, text
services
[email protected]
video
devices
September 2005
16
Presence data architecture
presence sources
PUBLISH
create
view
(compose)
raw
presence
document
XCAP
select best source
resolve contradictions
composition
policy
(not defined yet)
September 2005
privacy
filtering
depends on watcher
XCAP
privacy
policy
draft-ietf-simple-presence-data-model
17
Presence data architecture
candidate
presence
document
remove data not of
interest
watcher
September 2005
watcher
filter
raw
presence
document
post-processing
composition
(merging)
SUBSCRIBE
difference
to previous notification
NOTIFY
final
presence
document
18
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, …)
September 2005
19
RPID: rich presence
<person> <tuple>
<device>
<activities>
<class>
<mood>
<place-is>
<place-type>
<privacy>
<relationship>
<service-class>
<sphere>
<status-icon>
<time-offset>
<user-input>
September 2005
20
The role of presence for call
routing

Two modes:

watcher uses presence
information to select
suitable contacts


PUBLISH
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)
PA
translate
RPID
CPL
NOTIFY
LESS
INVITE
September 2005
21
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
September 2005
<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>
22
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


configuration


devices in room adapt to their current users
awareness


incoming communications changes based on where I am
others are (selectively) made aware of my location
security

proximity grants temporary access to local resources
September 2005
23
Location-based SIP services

Location-aware inbound routing




outbound call 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
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
September 2005
24
Program location-based services
September 2005
25
Service creation

Tailor a shared infrastructure to individual users
traditionally, only by vendors (and sometimes carriers)

learn from web models: killer app vertical apps

network
servers
end system
September 2005
programmer,
carrier
SIP servlets,
sip-cgi
end user
VoiceXML
scripting, RPC
VoiceXML (voice),
LESS
CPL
26
A different view of presence

Presence is problematic for facilitating calls



rapid changes + large watcher lists  high notification
volume
privacy: don’t want to tell whole life story to all watchers
 on-demand presence information



aggregate presence  synchronized calendars


just before communication
= SUBSCRIBE with zero duration
either centralized or peer-to-peer
Likely uses shifting to true events


environment changes (traffic, weather, …)
people changes (visitor stuck in traffic)
September 2005
27
Programming VoIP clients

Precursor: CTI


Call external programs


e.g., Google/MSN maps, local search
Scripting APIs


but rarely used outside call centers
e.g., call Tcl or PHP scripts  sip-cgi
Controllable

COM, XML RPC


used for media agents in sipc
Embeddable

no UI, just signaling and media
September 2005
28
Automating media interaction –
service examples





If call from my boss, turn off the stereo  call
handling with device control
As soon as Tom is online, call him  call handling
with presence information
Vibrate instead of ring when I am in movie theatre 
call handling with location information
At 9:00AM on 09/01/2005, find the multicast session
titled “ABC keynote” and invite all the group
members to watch  call handling with session
information
When incoming call is rejected, send email to the
callee  call handling with email
September 2005
29
LESS: simplicity


Generality (few and simple concepts)
Uniformity (few and simple rules)






Trigger rule
Switch rule
Action rule
Modifier rule
modifiers
trigger
switches
actions
Familiarity (easy for user to understand)
Analyzability (simple to analyze)
September 2005
30
LESS: Decision tree
No loops
Limited variables
Not necessarily
Turing-complete
September 2005
31
LESS: Safety

Type safety



Control flow safety



No direct memory access
LESS engine safety


No loop and recursion
One trigger appear only once, no feature interaction for a defined
script
Memory access


Strong typing in XML schema
Static type checking
Ensure safe resource usage
Easy safety checking

Any valid LESS scripts can be converted into graphical
representation of decision trees.
September 2005
32
LESS snapshot
incoming call
<less>
If the call from my boss
<incoming>
<address-switch>
<address is=“sip:[email protected]">
Turn off the stereo
<device:turnoff
device=“sip:[email protected]”/>
<media media=“audio”>
<accept/>
Accept the call with only audio
</media>
</address>
</address-switch>
</incoming>
</less>
trigger, switch, modifier, action
September 2005
33
LESS packages
Use packages to group elements

SIP user agent
im
email
web
Presence presence
agent
Event
calendar conference
session
September 2005
location
SIP
Basic user agent
Generic Media UI
x10
vcr
Device agent
34
When Tom is online, …
<less>
<EVENT:notification>
<address-switch>
<address is="sip:[email protected]">
<EVENT:event-switch>
<EVENT:event is="open">
<location url="sip:[email protected]">
<IM:im message="Hi, Tom"/>
</location>
</EVENT:event>
</EVENT:event-switch>
………
</less>
September 2005
35
When I am in a movie theatre, …
<less>
<incoming>
<location-switch>
<location placetype=“quiet”>
<alert sound=“none” vibrate=“yes”/>
</location>
</location-switch>
</incoming>
</less>
September 2005
36
Interfacing with Google
911: caller location
IM/presence: location of friends
call: “I’m here”
September 2005
38
Interfacing with Google
show all files from
caller Xiaotao Wu
September 2005
39
Embedding VoIP: FAA training
controls pilot
and ATC agents
– using
multicast and
unicast
(“landlines”)
September 2005
40
Open issues: application sharing

Current: T.120




Current: web-based sharing




doesn’t integrate well with other conference control
mechanisms
hard to make work across platforms (fonts)
ill-defined security mechanisms
hard to integrate with other media, control and record
generally only works for Windows
mostly limited to shared PowerPoint
Current: vnc


whole-screen sharing only
can be coerced into conferencing, but doesn’t integrate well
with control protocols
September 2005
41
IETF effort: standardized
application sharing


Remote access = application sharing
Four components:





window drawing ops  PNG
keyboard input
mouse input
window operations (raise, lower, move)
Uses RTP as transport



synchronization with continuous media
but typically, TCP
allow multicast  large group sessions
September 2005
42
SIP unsolicited calls and
messages

Possibly at least as
large a problem





more annoying (ring,
pop-up)
Bayesian content
filtering unlikely to
work
 identity-based
filtering
PKI for every user
unrealistic
Use two-stage
authentication

mutual
PK authentication (TLS)
Digest
home.com
SIP identity work
September 2005
43
Domain Classification

Classification of domains based on their identity instantiation and
maintenance procedures plus other domain policies.

Admission controlled domains

Strict identity instantiation with long term relationships


Bonded domains


Membership possible only through posting of bonds tied to a expected behavior
Membership domains

No personal verification of new members but verifiable identification required such as a
valid credit card and/or payment


Example: E-bay, phone and data carriers
Open domains

No limit or background check on identity creation and usage


Example: Employees, students, bank customers
Example: Hotmail
Open, rate limited domains

Open but limits the number of messages per time unit and prevents account creation by
bots

Example: Yahoo
September 2005
44
Reputation service (“Trust paths”)
Carol
has sent
IM to
David
has sent
email to
Emily
Frank
is this a spammer?
Alice
September 2005
for people and domains
Bob
45
Emergency calling

FCC mandate: all interconnected VoIP
providers must provide E911 service by 11/05




switch calls to right PSAP (via ESGW attached to
switches)
deliver location information to PSAP for dispatch
location entered manually
Problems:


user-entered location  no nomadic, mobile users
PSAP infrastructure brittle (38 PSAPs out after
Katrina)  fully IP-based allow relocation
September 2005
46
What makes VoIP 112/911
hard?
POTS
PSTN-emulation VoIP
end-to-end VoIP
(landline) phone number limited
to limited area
landline phone number
anywhere in US (cf. German
180)
no phone number or phone
number anywhere around the
world
regional carrier
national or continent-wide carrier
enterprise “carrier” or anybody
with a peer-to-peer device
voice provider = line provider (~
business relationship)
voice provider ≠ ISP
voice provider ≠ ISP
national protocols and call
routing
probably North America + EU
international protocols and
routing
location = line location
mostly residential or small
business
stationary, nomadic, wireless
September 2005
47
Location, location, location



Location  locate right PSAP & speed
dispatch
In the PSTN, local 9-1-1 calls remain
geographically local
In VoIP, no such locality for VSPs



most VSPs have close to national coverage
Thus, unlike landline and wireless, need
location information from the very beginning
Unlike PSTN, voice service provider doesn’t
have wire database information

VSP needs assistance from access provider (DSL,
cable, WiMax, 802.11, …)
September 2005
48
Options for location delivery

L2: LLDP-MED (standardized version of CDP
+ location data)


L3: DHCP for



periodic per-port broadcast of configuration
information
geospatial (RFC 3825)
civic (draft-ietf-geopriv-dhcp-civil)
L7: proposals for retrievals




by IP address
by MAC address
by identifier (conveyed by LLDP, DHCP or PPP)
via HTTP or maybe SIP
September 2005
49
Architecture
VSP
ISP
SIP
config
DHCP
outbound
proxy
PSAPs
DHCP
home
September 2005
50
LUMP mapping architecture
carrier X customers
R
R
nj.us
R
R
knows all
trees;
caches results
R
R
flooding
ny.us
bergen.nj.us
leonia.bergen.nj.us
generalizes to other
location-based services
September 2005
51
Emergency call conferencing
PSAP brings all related
parties into a conference call
Hospital
Fire
department
INVITE
INVITE
Conference
server
Recorder
3rd party
call control
media
INVITE info
REFER
INVITE
INVITE
REFER
REFER
INVITE
media
info
Caller
September 2005
PSAP
52
Managing (VoIP)
Applications – DYSWIS
Henning Schulzrinne
Dept. of Computer Science
Columbia University
July 2005
Overview




User experience for VoIP still inferior
Existing network management doesn’t work
for VoIP and other modern applications
Need user-centric rather than operator-centric
management
Proposal: peer-to-peer management


“Do You See What I See?”
Also use for reliability estimation and
statistical fault characterization
September 2005
54
VoIP user experience

Only 95-99.5% call attempt success



“Keynote was able to complete VoIP calls 96.9% of the time, compared
with 99.9% for calls made over the public network. Voice quality for VoIP
calls on average was rated at 3.5 out of 5, compared with 3.9 for publicnetwork calls and 3.6 for cellular phone calls. And the amount of delay
the audio signals experienced was 295 milliseconds for VoIP calls,
compared with 139 milliseconds for public-network calls.”
(InformationWeek, July 11, 2005)
Mid-call disruptions
Lots of knobs to turn

Separate problem: manual configuration
September 2005
55
Traditional network management
model
X
SNMP
“management from the center”
September 2005
56
Assumptions

Single provider (enterprise, carrier)



Typically, hard failures or aggregate problems



element failures
substantial packet loss
Mostly L2 and L3 elements



has access to most path elements
professionally managed
switches, routers
rarely 802.11 APs
Indirect detection

MIB variable vs. actual protocol performance
September 2005
57
Managing the protocol stack
media
RTP
UDP/TCP
IP
September 2005
echo
gain problems
VAD action
protocol problem
playout errors
protocol problem
authorization
asymmetric conn
(NAT)
SIP
TCP neg. failure
NAT time-out
firewall policy
no route
packet loss
58
Call lifecycle view
STUN
failure
auth?
registrar
?
September 2005
outbound
proxy?
dest.
proxy?
loss?
gain?
silence
suppression?
59
Types of failures

Hard failures




connection attempt fails
no media connection
NAT time-out
Soft failures (degradation)

packet loss (bursts)


delay (bursts)


access network? backbone? remote access?
OS? access networks?
acoustic problems (microphone gain, echo)
September 2005
60
Diagnostic undecidability



symptom: “cannot reach server”
more precise: send packet, but no response
causes:






5 causes  very different remedies


NAT problem (return packet dropped)?
firewall problem?
path to server broken?
outdated server information (moved)?
server dead?
no good way for non-technical user to tell
Whom do you call?
September 2005
61
Additional problems

ping and traceroute no longer
works reliably



WinXP SP 2 turns off ICMP
some networks filter all ICMP messages
Early NAT binding time-out

initial packet exchange succeeds, but then
TCP binding is removed (“web-only
Internet”)
September 2005
62
“Do You See What I See?”


Each node has a set of active measurement
tools
Nodes can ask others for their view


Iterative process, leading to:



possibly also dedicated “weather stations”
user indication of cause of failure
in some cases, work-around (application-layer
routing)  TURN server, use remote DNS servers
Nodes collect statistical information on
failures and their likely causes
September 2005
63
Failure detection tools

STUN server



what is your IP address?
ping and traceroute
Transport-level liveness


open TCP connection to
port
send UDP ping to port
media
RTP
UDP/TCP
IP
September 2005
64
Failure statistics

Which parts of the network are most likely to
fail (or degrade)








access network
network interconnects
backbone network
infrastructure servers (DHCP, DNS)
application servers (SIP, RTSP, HTTP, …)
protocol failures/incompatibility
Currently, mostly guesses
End nodes can gather and accumulate
statistics
September 2005
65
How to find management peers?


Use carrier-provided bootstrap list
Previous session partners


e.g., address book
Watcher list
September 2005
66
What’s missing?

Request diagnostic




“send this message”; return result
do specific high-level operation (ping, traceroute,
DNS resolution)
Failure statistics protocol and data exchange
format
Algorithm specification for steps


“if no response to REGISTER, check server
liveness”
“if bad voice QoS, ask subnet neighbor; then ask
somebody close to destination”
September 2005
67
Security issues

Indirect denial-of-service attacks




limit per-requestor rate
return cached results to querier
Lying
Non-participation (“leechers”)

usual P2P mechanisms such as blacklists
September 2005
68
Conclusion

Slow transition from emulating PSTN to new services



Emphasis moving from protocol mechanics to
architecture





presence-based
embedded (e.g., games)
slow transition to open systems
different combinations of software vendors, IAP/ISP, VSP,
hardware vendors
Still need to fill out infrastructure for collaboration
and presence
Protocols  systems  infrastructure replacement
Management from the center  management from
the edges
September 2005
69