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

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

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 timeCPL capabilitiescaller preferences locationlocation-based call routing location events activity/availabilitypresence sensor data (mood, bio)not yet, but similar in many aspects to location data

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

Determining location Determine (person, location) tuple Two modes: end-system based GPS, beacons, triangulation (STA) infrastructure, but explicit user action swipe card, RFID (maybe), biometrics network-based 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

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

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)

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

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

Architectures for (geo) information access Claim: all using protocols fall into one of these categories Presence or event notification “circuit-switched” model subscription: binary decision Messaging , 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

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 rule interface INVITE

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 PA watcher PUA watcher PUBLISH NOTIFY everything "vague" CPL INVITE

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

RPID example open voice message assistant My secretary

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

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 both policy and geo data

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

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

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

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

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)

Emergency calling as an LBS Emergency calling (“911’’, “112”) = call identification  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

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

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

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