Rich Presence & Location – more than just your teenager’s IM system Henning Schulzrinne Columbia University & SIPquest (Spring VON 2004 – Santa Clara, CA) hgs@cs.columbia.edu

Overview Limitations of existing IM systems Presence: special case of event systems Rich presence RPID for rich presence CIPID for contact information timed presence is-composing Location-based services Future challenges

“Legacy” IM & presence systems  SIP-based systems centralized systems (single name space) federated systems, similar to email mostly instant text messages media-agnostic – transmit any media object separate from session-based services (VoIP, video conferencing) integrated: use IM as part of media sessions use presence to facilitate session setup limited presence status, mostly manually set rich presence, with time information imported from sensors, calendars, backend systems, … proprietary systems (AOL, Yahoo!, MSN, ICQ, …) standards-based systems

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

Filling in the protocol gap Service/delivery synchronous asynchronous push SIP RTSP, RTP SMTP pull HTTP ftp SunRPC, Corba, SOAP (not yet standardized)

IETF efforts SIP, SIPPING and SIMPLE working groups but also XCON (conferencing) Define SIP methods PUBLISH, SUBSCRIBE, NOTIFY GEOPRIV: geospatial privacy location determination via DHCP information delivery via SIP, HTTP, … privacy policies SIMPLE: architecture for events and presence configuration (XCAP) session-oriented IM (↔ page mode) filtering, rate limiting and authorization

Presence and event notification Presence = special case of event notification “user Alice is available for communication” Human users: 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, …) Multimedia systems: REFER (call transfer) message waiting indication conference floor control conference membership push-to-talk system configuration General events: emergency alert (“reverse 911”) industrial sensors (“boiler pressure too high”) business events (“more than 20 people waiting for service”)

Context-aware communications Traditional emphasis: communicate anywhere, anytime, any media  largely possible today New challenge: tailor reachability Context-aware communications modify when, how, where to be reached  machine: context-dependent call routing  human: convey as part of call for human usage context-aware services leveraging local resources awareness of other users sources of location information voluntary and automatic location-based services  privacy concerns applies to other personal information activity, reachability, capabilities, bio sensor data, … emergency services as a location-based service

Context 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) not yet, but similar in many aspects to location data

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 delivery@pizza.com 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

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

DHCP for locations CDP + SNMP modified dhcpd (ISC) to generate location information use MAC address backtracing to get location information 8:0:20:ab:d5:d DHCP server CDP + SNMP 8:0:20:ab:d5:d  458/17 DHCP answer: sta=DC loc=Rm815 lat=38.89868 long=77.03723 458/17  Rm. 815 458/18  Rm. 816

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 Classification: Activities: Surroundings: contact-type device, in-person, service, presentity class for labeling sphere “work”, “home”, … relationship “family”, “associate”, “assistant”, “supervisor” Activities: activity “on-the-phone”, “away”, “appointment”, … idle last usage of device Surroundings: placetype “home”, “office”, “industrial”, … privacy “public”, “private”

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

Timed Status Presence is about here & now but often only have (recent) past – e.g., calendar or future “will be traveling in two hours” “will be back shortly” allows watcher to plan communication loose synchronization of calendars <tuple id="7c8dqui"> <contact> sip:bob@example.com </contact> <status> <basic>open</basic> </status> <fs:timed-status from="2003-08-15T10:20:00.000-05:00“ until="2003-08-22T19:30:00.000-05:00"> <basic>closed</basic> </fs:timed-status> </tuple> <note>I'll be in Tokyo next week</note>

Presence policy for each watcher subscription policy SUBSCRIBE subscription policy subscriber (watcher) for each watcher event generator policy subscriber filter rate limiter change to previous notification? NOTIFY

Policy relationships common policy geopriv-specific presence-specific future RPID CIPID

Privacy rules Conditions Actions Transformations identity, sphere, validity 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 Extendable to new presence data rich presence biological sensors mood sensors

Location-based services in CINEMA Initial proof-of-concept implementation Integrate devices: lava lamp via X10 controller  set personalized light mood setting Pingtel phone  add outgoing line to phone and register user painful: needs to be done via HTTP POST request stereo  change to audio CD track based on user Sense user presence and identity: passive infrared (PIR) occupancy sensor magnetic swipe card ibutton BlueTooth equipped PDA IR+RF badge (in progress) RFID (future) biometrics (future)

Location-based IM & presence

Emergency (911) services Old wireline and wireless models don’t work any more All wireline systems are potentially mobile (nomadic) device bought in Belgium place call in Canada with VSP in Mexico and maybe a VPN for extra excitement… Customer may not have a traditional voice carrier at all corporate residential  VSP in a different country Needs to work internationally same standards no custom configuration Components: universal identifier  “sos” configure local emergency numbers find right PSAP identify and verify PSAP On-going effort in IETF and NENA

Location-based call routing – UA knows its location GPS INVITE sips:sos@ 40.86N 73.98E CN=us A1=NJ A2=Bergen leonia.nj.us.sos.arpa POLY 40.85 73.97 40.86 73.99 NAPTR … firedept@leoniaboro.org outbound proxy server provided by local ISP? 40.86N 73.98E: Leonia, NJ fire dept. DHCP

Conclusion New service enabler – much more than just instant messaging Natural combination of presence and location-based services Accommodates transition from “reach me anywhere, anytime” to “reach me when it’s convenient for me” Need to take privacy into consideration

SIP, SIPPING & SIMPLE –00 drafts includes draft-ietf-*-00 and draft-personal-*-00

SIP URIs for locations location beacon Identify confined locations by a SIP URI, e.g., sip:rm815@cs.columbia.edu Register all users or devices in room Allows geographic anycast: reach any party in the room sip:rm815 Contact: bob a@foo.com: 128.59.16.1 Contact: alice Room 815

Example: user-adaptive device configuration “all devices that are in the building” RFC 3082? 802.11 signal strength  location SLP device controller HTTP PA REGISTER To: 815cepsr Contact: alice@cs tftp SUBSCRIBE to each room discover room URI REGISTER as contact for room URI SIP room 815 SUBSCRIBE to configuration for users currently in rooms

Location-based call routing – network knows location TOA outbound proxy IP include location info in 302 INVITE sips:sos@ INVITE sips:sos@paris.gendarme.fr 48° 49' N 2° 29' E map location to (SIP) domain