Henning Schulzrinne Columbia University & SIPquest (Spring VON 2004 – Santa Clara, CA)

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

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

3. “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

4. Internet services – the missing entry

5. Filling in the protocol gap

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

7. 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”) Presence and event notification

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

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

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

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

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

13. DHCP for locations • 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

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

15. Classification: 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” RPID: rich presence

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

17. 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> Timed Status

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

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

20. Conditions 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 Privacy rules

21. 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)

22. Location-based IM & presence

23. 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 Emergency (911) services

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

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

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

27. a@foo.com: 128.59.16.1 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 Contact: alice Room 815

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

29. IP Location-based call routing – network knows location TOA outbound proxy 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