The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science...
-
date post
20-Dec-2015 -
Category
Documents
-
view
212 -
download
0
Transcript of The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science...
![Page 1: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/1.jpg)
The SIMPLE Presence and Event Architecture
Henning Schulzrinne (*)Dept. of Computer Science
Columbia University
(*) The SIMPLE architecture is a collaboration of many individuals.
![Page 2: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/2.jpg)
Overview
• Motivation• The SIMPLE architecture
and data structure• Privacy• Composition• Location-based services• Interaction with service
creation
![Page 3: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/3.jpg)
An eco system, not just a protocol
SIP
XCAP(config)
RTSP
SIMPLEpolicyRPID
….
SDP
XCON(conferencing)
STUNTURN
RTP
configures
initiates carries
carriescontrols provide addresses
![Page 4: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/4.jpg)
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 routinglocation events
activity/availability presence
sensor data (mood, bio) privacy issues similar to location data
![Page 5: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/5.jpg)
The role of presence• “Is the callee likely to be reachable?” user-level
presence• glue logic for loosely-coupled systems• events related to calls:
– voicemail notification– call transfer notification
• Events are a superset of presence:– publish, subscribe & notify– in SIMPLE, just differ in their
• event type and bodies (typically, XML)• privacy policies
– unlike other event systems, cross-domain, with security• but no content-dependent replication (Siena,
Elvin, …)
![Page 6: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/6.jpg)
The role of presence: user-reachability• 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
![Page 7: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/7.jpg)
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
![Page 8: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/8.jpg)
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
![Page 9: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/9.jpg)
GEOPRIV and SIMPLE architectures
targetlocationserver
locationrecipient
rulemaker
presentity
caller
presenceagent
watcher
callee
GEOPRIV
SIPpresence
SIPcall
PUBLISHNOTIFY
SUBSCRIBE
INVITE
publicationinterface
notificationinterface
XCAP(rules)
INVITE
DHCP
![Page 10: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/10.jpg)
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
![Page 11: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/11.jpg)
Presence data architecture
candidatepresencedocument
watcherfilter
rawpresencedocument
post-processingcomposition(merging)
finalpresencedocument
differenceto previous notification
SUBSCRIBE
NOTIFY
remove data not of interest
watcher
![Page 12: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/12.jpg)
Presence data model
“calendar” “cell” “manual”
[email protected], video, text
person(presentity)
(views)
services
devices
![Page 13: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/13.jpg)
Rich presence
• Rich presence = more information than open/closed
• 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, …)
![Page 14: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/14.jpg)
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
![Page 15: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/15.jpg)
RPID: rich presence
<person> <tuple> <device>
<activities>
<class>
<mood>
<place-is>
<place-type>
<privacy>
<relationship>
<service-class>
<sphere>
<status-icon>
<time-offset>
<user-input>
![Page 16: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/16.jpg)
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>
![Page 17: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/17.jpg)
Privacy policy relationships
geopriv-specific presence-specific
common policy
RPID CIPID
future
![Page 18: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/18.jpg)
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
![Page 19: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/19.jpg)
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>
![Page 20: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/20.jpg)
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
![Page 21: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/21.jpg)
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
![Page 22: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/22.jpg)
Presence Composition• composition = combines multiple presence or event
sources into one view– remove information: stale, contradictory,
redundant– create new information (e.g., new composite
services)• Tries to resolve information conflicts
– update diligence, multiple devices in different places, no sensor data, …
• Focus on PIDF/RPID, but probably applicable to other event sources
• Depends on presentity, but not on watcher– i.e., provides maximum information set for later
stages
![Page 23: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/23.jpg)
Sources of presence data• Reported current
– added manually a brief time ago– assumed correct when entered, but decays
• Reported scheduled– from a calendar
• Measured device information– communication status
• Measured by sensors– location, type of location, activity, …– sensors = GPS, acceleration sensors,
PIRs, ...• Derived
– from other presence data
![Page 24: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/24.jpg)
Composition steps
• Working on policy language that describes desired composition policy
• Complicated policies will require “real” languages
source
source
union withreplacement
discardclosed +
old
combineidenticalcontacts
resolveambiguities
![Page 25: The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration.](https://reader030.fdocuments.us/reader030/viewer/2022032800/56649d485503460f94a23dd9/html5/thumbnails/25.jpg)
Conclusion• Presence = core service enabler for VoIP• Presence = necessary for location-based services• Presence = (special case of) event notification• IETF SIMPLE architecture = first comprehensive
attempt to standardize presence– but some techniques likely applicable to other
systems (e.g., XMPP)• Presence needs
– PUBLISH/SUBSCRIBE/NOTIFY– data structures for presence data– rich presence information– privacy controls– composition