Making Multimedia Services Location-Aware

1. Making Multimedia Services Location-Aware Henning Schulzrinne (with Knarig Arabshian, Stefan Berger, Stelios Sidiroglou, Kundan Singh, Xiaotao Wu, Weibin Zhao and the RPIDS and GEOPRIV authors) Columbia University IRT Lab SIP 2004 – January 2004 Paris, France

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

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

4. Location information • geospatial • longitude, latitude, altitude • civil • time zone, country, city, street, room, … • categorical • type of location • properties of location • privacy (“no audio privacy”) • suitability for different communication media

5. Determining location • Determine (person, location) tuple • Two modes: • end-system based • GPS, beacons, 802.11 triangulation (STA) • infrastructure, but explicit user action • swipe card, RFID (maybe), biometrics • network-based • 802.11 triangulation (AP), face recognition • GPS may not be practical (cost, power, topology) • A-GPS for indoor use – leverages cell infrastructure • Add location beacons • extrapolate based on distance moved • odometer, pedometer, time-since-sighting • idea: meet other mobile location beacons • estimate location based on third-party information

6. 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 DHCP for locations • modified dhcpd (ISC) to generate location information • use MAC address backtracing to get location information

7. DHCP for locations • Proposal: DHCP extensions for geographic and civil location • geographic: resolution (bits), long/lat, altitude (meters or floors) • civil: • what: end system, switch or DHCP server • hierarchical subdivisions, from country to street, landmark name, occupant • Also, some LAN switches broadcast port and switch identification • CDP for Cisco, EDP for Extreme Networks • Can also use backtracking via SNMP switch tables • locally implemented for emergency services (Perl sip-cgi script)

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

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

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

11. Claim: all using protocols fall into one of these categories Presence or event notification “circuit-switched” model subscription: binary decision Messaging email, SMS basically, event notification without (explicit) subscription but often out-of-band subscription (mailing list) Request-response RPC, HTTP; also DNS, LDAP typically, already has session-level access control (if any at all) Presence is superset of other two GEOPRIV IETF working group looking generically at location services (privacy) SIMPLE and SIP: event notification, presence Architectures for (geo) information access

12. GEOPRIV and SIMPLE architectures rule maker rule interface 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. RPIDS: rich presence data • Basic IETF presence (CPIM) only gives you • contact information (SIP, tel URI) • priority • “open” or “closed” • Want to use presence to guide communications watcher everything PA PUA watcher "vague" PUBLISH watcher NOTIFY CPL INVITE

14. Context  RPID (Rich presence data) • Integrates caller preferences information into presence announcements • <activity>: on-the-phone, away, appointment, holiday, meal, meeting, steering, in-transit, travel, vacation, busy, permanent-absence • <placetype>: home, office, public • <privacy>: public, private, quiet • <from>, <until>: status validity • <idle>: activity for device • <relationship>: family, associate, assistant, supervisor • <class>: grouping

15. RPID example <tuple id="7c8dqui"> <status> <basic>open</basic> <contact>sip:secretary@example.com</contact> <cap:capabilities> <cap:feature name="Media"> <cap:value>voice</cap:value> <cap:value negated="true">message</cap:value> </cap:feature> </cap:capabilities> </status> <ep:relationship>assistant</ep:relationship> <note>My secretary</note> </tuple>

16. Policy rules • There is no sharp geospatial boundary • Presence contains other sensitive data (activity, icons, …) and others may be added • Example: future extensions to personal medical data • “only my cardiologist may see heart rate, but notify everybody in building if heart rate = 0” • Thus, generic policies are necessary

17. Presence/Event notification • Three places for policy enforcement • subscription  binary • only policy, no geo information • subscriber may provide filter  could reject based on filter (“sorry, you only get county-level information”)  greatly improves scaling since no event-level checks needed • notification  content filtering, suppression • only policy, no geo information • third-party notification • e.g., event aggregator • can convert models: gateway subscribes to event source, distributes by email • both policy and geo data

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

19. Processing models • Sequential model: • for each subscriber, apply rules to new data • doesn’t scale well to large groups • Relational database model: • re-use indexing and other query optimizations • well-defined query and matching semantics • e.g., mySQL and PostGres have geo extensions • At time of subscription: • SELECT address FROM policies WHERE person=$subscriber (AND now() between(starttime,endtime) OR starttime is null) AND (a3=$a3 or a3 is null) …

20. Location filtering language • SIP presence information will be updated using REGISTER and UPDATE • Need to constrain • who is allowed to see what detail  presentity privacy • who wants to see what detail • how often • what granularity of change • Proposal to allow SUBSCRIBE to include frequency limitation • Working on CPL-like language invoked (logically) at publication time • classes of users, e.g., based on entry in my address book • classes get mapped to restriction • “12 bits of long/lat resolution, 6 bits of altitude resolution, 0 bits of velocity” • “time zone only”, “category only” • watchers can then add filters that restrict the delivery: • location difference > threshold • entering or leaving certain area • entering or leaving category or behavioral type

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

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

23. Emergency calling as an LBS • Emergency calling (“911’’, “112”) = • call identification  sip:sos@domain or tel:112 • destination identification • is this really an emergency call center? • special call handling • priority handling of signaling or media packets  • bypass authentication and authorization  • call routing to nearest emergency call center (ECC) • Call routing is hardest • must work internationally • end system + network-based location determination • Once solved: • roadside emergency (AAA, ADAC, …) • pizza emergency (nearest PizzaHut) • but different privacy trade-offs  voluntary disclosure

24. Location-based call routing – UA knows its location GPS INVITE sips:sos@ 48° 49' N 2° 29' E outbound proxy server DHCP 48° 49' N 2° 29' E  Paris fire department

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

26. Conclusion • SIP was designed for context-aware call routing • caller preferences • callee capabilities • location-based call routing • location as rich source of context • location information allows emergency calling • but leverage for other services • privacy  user control of information • disclosure • propagation • avoid tendency to assume SIP users are human – want to interconnect different components and devices • SIP device configuration needs automation, rather than screen-scraping