Making Multimedia Services LocationAware Henning Schulzrinne with Knarig

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 n Context-aware communications n n context-aware services n n n voluntary and automatic location-based services privacy concerns n n n leveraging local resources awareness of other users sources of location information n n modify when, how, where to be reached machine: context-dependent call routing human: convey as part of call for human usage applies to other personal information activity, reachability, capabilities, bio sensor data, … emergency services as a location-based service

Context n n n 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-based call routing location events activity/availability presence sensor data (mood, bio) not yet, but similar in many aspects to location data

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

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

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

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

Location-based services n Finding services based on location n n physical services (stores, restaurants, ATMs, …) electronic services (media I/O, printer, display, …) not covered here Using location to improve (network) services n communication n n configuration n n devices in room adapt to their current users awareness n n incoming communications changes based on where I am others are (selectively) made aware of my location security n proximity grants temporary access to local resources

Location-based SIP services n Location-aware inbound routing n n outbound call routing n n n 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 contact nearest emergency call center send delivery@pizza. com to nearest branch location-based events n subscribe to locations, not people n Alice has entered the meeting room n subscriber may be device in room our lab stereo changes CDs for each person that enters the room

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

Architectures for (geo) information access n n n Claim: all using protocols fall into one of these categories Presence or event notification n “circuit-switched” model n subscription: binary decision Messaging n email, SMS n basically, event notification without (explicit) subscription n but often out-of-band subscription (mailing list) n n Request-response n RPC, HTTP; also DNS, LDAP n 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 rule maker rule interface target presentity caller publication interface PUBLISH INVITE location server presence agent notification interface location recipient GEOPRIV watcher SIP presence SUBSCRIBE NOTIFY INVITE callee SIP call

RPIDS: rich presence data n Basic IETF presence (CPIM) only gives you n n contact information (SIP, tel URI) priority “open” or “closed” Want to use presence to guide communications everything watcher PUA PA watcher PUBLISH NOTIFY "vague" watcher INVITE CPL

Context RPID (Rich presence data) n n 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 n <from>, <until>: status validity <idle>: activity for device <relationship>: family, associate, assistant, n <class>: grouping n n supervisor

RPID example <tuple id="7 c 8 dqui"> <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>

Policy rules n n n 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 n n “only my cardiologist may see heart rate, but notify everybody in building if heart rate = 0” Thus, generic policies are necessary

Presence/Event notification n Three places for policy enforcement n subscription binary n notification content filtering, suppression n n 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 only policy, no geo information third-party notification n e. g. , event aggregator can convert models: gateway subscribes to event source, distributes by email both policy and geo data

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

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

Location filtering language n n SIP presence information will be updated using REGISTER and UPDATE Need to constrain n n who is allowed to see what detail presentity privacy who wants to see what detail n n how often what granularity of change Proposal to allow SUBSCRIBE to include frequency limitation Working on CPL-like language invoked (logically) at publication time n n classes of users, e. g. , based on entry in my address book classes get mapped to restriction n “ 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: n n n location difference > threshold entering or leaving certain area entering or leaving category or behavioral type

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

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

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

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

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

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