The SIMPLE Presence and Event Architecture Henning Schulzrinne (*) Dept. of Computer Science Columbia University (*) The SIMPLE architecture is a collaboration of many individuals.

Overview Motivation The SIMPLE architecture and data structure Privacy Composition Location-based services Interaction with service creation

An eco system, not just a protocol SIP XCAP (config) RTSP SIMPLE policy RPID …. SDP XCON (conferencing) STUN TURN RTP configures initiatescarries controls provide addresses

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 timeCPL capabilitiescaller preferences locationlocation-based call routing location events activity/availabilitypresence sensor data (mood, bio)privacy issues similar to location data

The role of presence “Is the callee likely to be reachable?”  user-level presence glue logic for loosely-coupled systems events related to calls: –voic 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, …)

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 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

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 translate RPID CPL PA PUBLISH NOTIFY INVITE

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

GEOPRIV and SIMPLE architectures target location server location recipient rule maker presentity caller presence agent watcher callee GEOPRIV SIP presence SIP call PUBLISH NOTIFY SUBSCRIBE INVITE publication interface notification interface XCAP (rules) INVITE DHCP

Presence data architecture raw presence document create view (compose) privacy filtering draft-ietf-simple-presence-data-model composition policy privacy policy presence sources XCAP (not defined yet) depends on watcher select best source resolve contradictions PUBLISH

Presence data architecture candidate presence document watcher filter raw presence document post-processing composition (merging) final presence document difference to previous notification SUBSCRIBE NOTIFY remove data not of interest watcher

Presence data model “calendar”“cell”“manual” audio, video, text video person (presentity) (views) services devices

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, …)

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

RPID: rich presence

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

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 <gml:Point gml:id="point1“ srsName="epsg:4326"> 37:46:30N 122:25:10W no T04:57:29Z T20:57:29Z

Privacy policy relationships geopriv-specificpresence-specific common policy RPIDCIPID future

Privacy rules Conditions –identity, sphere –time of day –current location –identity as or + 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

Example rules document allow sip mailto true bare

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 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

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 to nearest 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

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

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

Composition steps Working on policy language that describes desired composition policy Complicated policies will require “real” languages source union with replacement discard closed + old combine identical contacts resolve ambiguities

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