Ubiquitous SIP

1. Ubiquitous SIP Henning Schulzrinne (with Knarig Arabshian, Stefan Berger, Stelios Sidiroglou, Kundan Singh, Xiaotao Wu, Weibin Zhao and the RPIDS authors) Columbia University IRT Lab TU Darmstadt/NEC/U Karlsruhe/NSF RI/Nokia – December 2003

2. Overview • What is ubiquitous computing? • Core ubiquitous communications functionality • Brief introduction to SIP • Ubiquitous computing in SIP and SLP • On-going work at Columbia

3. What is ubiquitous computing? • “Ubiquitous computing has as its goal the enhancing computer use by making many computers available throughout the physical environment, but making them effectively invisible to the user.” (Weiser, 1993) • “Ubiquitous computing is not virtual reality, it is not a Personal Digital Assistant (PDA) such as Apple's Newton, it is not a personal or intimate computer with agents doing your bidding. Unlike virtual reality, ubiquitous computing endeavers to integrate information displays into the everyday physical world. It considers the nuances of the real world to be wonderful, and aims only to augment them.” (Weiser, 1993)

4. Ubiquitous computing aspects • Also related to pervasive computing • Mobility, but not just cell phones • Computation and communications • Integration of devices • “borrow” capabilities found in the environment  composition into logical devices • seamless mobility  session mobility • adaptation to local capabilities • environment senses instead of explicit user interaction • from small dumb devices to PCs • light switches and smart wallpaper

5. Components of ubiquitous communications • Service discovery  discover devices • Service mobility  configuration information moves to new devices • Event notification  for context awareness • Context-awareness  location, user actions, location properties, …

6. Example “ubicomp” projects • Ambient Devices • EU IST Disappearing Computer • Project Aura, CMU  user attention • UNC “office of real soon now” • augmented surfaces [Reki99] • Microsoft Easy Living • Oxygen, MIT • Portolano, Univ. of Washington • Endeavour, Berkeley • CoolTown, HP Labs

7. Ubiquitous computing using SIP – what’s different? • Traditionally, focus on closed environments (lab, single company, home, …) • Often, proprietary protocols  self-contained environment • Here, • operate across Internet ( no Corba…) • trusted, semi-trusted and untrusted participants • use standard protocol mechanisms where possible • make minimal assumptions on homogeneity • respect user privacy

8. What is SIP? • Session Initiation Protocol  protocol that establishes, manages (multimedia) sessions • also used for IM, presence & event notification • uses SDP to describe multimedia sessions • Developed at Columbia U. (with others) • Standardized by IETF, 3GPP (for 3G wireless), PacketCable • About 60 companies produce SIP products • Microsoft’s Windows Messenger (4.7) includes SIP

9. Basic SIP message flow

10. outbound proxy SIP trapezoid a@foo.com: 128.59.16.1 registrar SIP trapezoid

11. SIP event notification • Named events • Typically, used for events within conferences (“Alice joined”) and call legs (e.g., call transfer) • Supports arbitrary notification bodies, typically XML SUBSCRIBE sip:alice@vmail.example.com SIP/2.0 To: <sip:alice@example.com> From: <sip:alice@example.com>;tag=78923 Call-Id: 1349882@alice-phone.example.com Contact: <sip:alice@alice-phone.example.com> NOTIFY sip:alice@alice-phone.example.com SIP/2.0 … Event: message-summary Subscription-State: active Messages-Waiting: yes Message-Account: sip:alice@vmail.example.com Voice-Message: 2/8 (0/2)

12. SIP event architecture • Does not try to route notifications (“application layer multicast”) as in SIENA • Filtering at PA under discussion (for low-bandwidth devices) • rate • content • But most ubicomp notification groups are probably small • and message volume not likely to provide much bandwidth saving via network-based filtering • Greatly simplifies trust model: no intermediaries that need to inspect content • can encrypt via S/MIME • However, can build redistribution “exploders” and list subscriptions (“subscribe to engineering@hp.com”)

13. a@foo.com: 128.59.16.1 SIP presence architecture REGISTER SUBSCRIBE watcher PA NOTIFY Alice Bob <?xml version="1.0" encoding="UTF-8"?> <p:presence xmlns:p="urn:…" entity="pres:alice@example.com"> <p:tuple id="sg89ae"> <p:status> <p:basic>open</p:basic> </p:status> <p:contact>tel:09012345678</p:contact> </p:tuple> </p:presence> PUAs PUBLISH

14. Session mobility • Walk into office, switch from cell phone to desk phone • call transfer problem  SIP REFER • related problem: split session across end devices • e.g., wall display + desk phone + PC for collaborative application • assume devices (or stand-ins) are SIP-enabled • third-party call control

15. Session mobility via 3PCC pc42 INVITE speakerphone m=audio c=pc42 192.0.2.1 INVITE pc42 m=video c=192.0.2.7 m=audio c=192.0.2.1 INVITE display m=video c=pc42 192.0.2.7

16. How to find services? • Two complementary developments: • smaller devices carried on user instead of stationary devices • devices that can be time-shared • large plasma displays • projector • hi-res cameras • echo-canceling speaker systems • wide-area network access • Need to discover services in local environment • SLP (Service Location Protocol) allows querying for services • “find all color displays with at least XGA resolution” • slp://example.com/SrvRqst?public?type=printer • SLP in multicast mode • SLP in DA mode • Need to discover services before getting to environment • “is there a camera in the meeting room?” • SLP extension: find remote DA via DNS SRV

17. Service Location Protocol (SLP) • Version 2 standardized June 1999 SrvRqst SA UA SA SrvRply SrvReg DA SrvReg SrvRqst DAAdvert

18. SLP attribute example

19. Other service location mechanism • DNS SRV/NAPTR • DNS TXT records (Apple Rendezvous)  DNS-SD • UPnP uses SSDP: • multicast HTTP over UDP M-SEARCH * HTTP/1.1 S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6 Host: 239.255.255.250:reservedSSDPport Man: "ssdp:discover“ ST: ge:fridge MX: 3 HTTP/1.1 200 OK S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6 Ext: Cache-Control: no-cache="Ext", max-age = 5000 ST: ge:fridge USN: uuid:abcdefgh-7dec-11d0-a765-00a0c91e6bf6 AL: <blender:ixl><http://foo/bar>

20. Service mobility • Allow access to service parameters anywhere – “payphone problem” • address book • incoming call rules • source name (SIP From) • Existing solutions: • SIM card  cumbersome to change • synchronization (e.g., Palm)  not suitable for borrowed devices • Server-based services  easier with SIP (service-routing), if carrier allows • Emerging solutions for SIP systems: • Small user token (smart card, RFID, i-button) identifying user • Temporarily download configuration from home server

21. Context-based communication services • Observable state and actions • State: • location of users • user activities • Derive state from • sensors (time, location, environment, user interaction) • data (calendars, address books) • network inputs (messages) • Actions • incoming and outgoing calls • incoming and outgoing IMs, SMS, email, … • Initially, focusing on location at key context

22. 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 • Privacy rules for access to context data

23. Location-based services • Presence-based approach: • UA publishes location to presence agent (PA) • becomes part of general user context • other users (human and machines) subscribe to context • call handling and direction • location-based anycast (“anybody in the room”) • location-based service directory • Languages for location-based services • building on experience with our XML-based service creation languages • CPL for user-location services • LESS for end system services

24. Location-based SIP services • Services: • Location-aware call 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” • “contact nearest emergency call center” • “do not ring phone if I’m in a theater” • “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 • Person + location events • We’re implementing SIP, caller-preferences and CPL extensions for these services

25. Locations • Geographic location • latitude, longitude, altitude, velocity, heading • Civil location (≠ postal location!) • time zone, street address, city • some countries are a bit difficult… • Categorical • office, library, theater, hospital, … • Behavioral • “public location, don't expect privacy” • “silence is encouraged, don't ring the phone”

26. Determining locations • SIP entities are often far away from physical user or his current network (intentionally) • For many devices, can’t afford hardware to determine location • different precision requirements: • “in Fayette County” (within driving distance of service or person) • “on campus” • “in room 815” • “in corner, talking to Bob” • GPS doesn’t work indoors, but Assisted GPS (A-GPS) may • Use location beacons: BlueTooth, 802.11 • may not offer network connectivity • see our 7DS project: offer local content + location • Physically close by network entities: • DHCP (same broadcast domain) • PPP (tail circuit) • Not always true with VPNs, but end system knows that it’s using a VPN

27. Determining location • Two types of sensors: • end system determines location • “handset-based”  GPS, 802.11 triangulation • network conveys location to end system or other component • MAC backtracking • AP-based 802.11 triangulation • swipe cards, iButtons, active badges • Two modes: • explicit user action: swipe card, touch iButton • involuntary: network-based tracking • GPS may not be practical (cost, power, topology) • 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

28. Determining locations • For many devices, can’t afford hardware to determine location • Implementing BlueTooth-based location sensor networks • CU 7DS project: offer local content + location • Developing programmable active badges with IR and RF capabilities

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

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

31. Location-based services & SIP • We’re using SIP (and SIMPLE) as generic protocols for • effecting change (“actuators”) • send MESSAGE to devices • distributing event information (“sensors”) • Advantages: • people and rooms identified by URIs • sip:hgs@cs.columbia.edu • sip:cepsr815@cs.columbia.edu • cross-domain, with extensive security mechanisms • domains don’t need to trust each other • scalable to global system • many other systems are mostly local

32. 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 • 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

33. SIP extensions for location-based services • Location information is highly sensitive • complete tracking of person • stalkers and burglars would kill for this information • IETF GEOPRIV principle: “target” can control dissemination of location information • restrict time of day, information (location, heading, velocity) resolution, number of times queried, destination, retention, … • “Alice is in time zone MET” may be ok for strangers, but “Alice is at 41.872833 N, 087.624417 W, heading NE at 45 mph” is not • GEOPRIV still defining application scenarios • in many cases, easiest to include location information “in-band” with protocol, as this avoids delegating authorization • otherwise, need to give access key to database to recipient • we propose adding SIP Location header field

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

35. Aside: SIP caller preferences • SIP core philosophy: many devices, one identifier • Address people, not plastic

36. a@foo.com: 128.59.16.1 Aside: SIP caller preferences • But caller sometimes has preferences among devices • SIP caller guides call routing: • “I hate voicemail!” • “I hate people!” • “I prefer voicemail” • Multilingual lines • “Caller proposes, callee disposes” sip:isabel@a.com;languages="es" sip:isabel@a.com;languages="en";q=0.2 INVITE sip:sales@a.com Accept-Contact: *;languages="en" REGISTER INVITE sip:bob@a.com;languages="en"

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

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

39. Event filtering • Events are core attribute of ubiquitous computing systems • tell devices about people actions • tell people about device presence • e.g., “Alice has entered Room 815” • devices that know Alice’s preferences subscribe to Alice • locations may also have presence • e.g., for occupancy sensors, switches

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

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

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

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

44. Web server Columbia SIP servers (CINEMA) Telephone switch Local/long distance 1-212-5551212 rtspd: media server Quicktime Single machine RTSP sipconf: Conference server RTSP clients Department PBX sipum: Unified messaging Internal Telephone Extn: 7040 713x sipd: Proxy, redirect, registrar server SQL database SIP/PSTN Gateway Web based configuration SNMP (Network Management) Extn: 7134 H.323 Extn: 7136 siph323: SIP-H.323 translator NetMeeting xiaotaow@cs

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

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

47. CINEMA system

48. All-SIP implementation

49. Service creation • Promise of faster service creation • traditionally, only vendors (and sometimes carriers) • learn from web models

50. sip-cgi • web common gateway interface (cgi): • oldest (and still most commonly used) interface for dynamic content generation • web server invokes process and passes HTTP request via • stdin (POST body) • environment variables  HTTP headers, URL • arguments as POST body or GET headers (?arg1=var1&arg2=var2) • new process for each request  not very efficient • but easy to learn, robust (no state) • support from just about any programming language (C, Perl, Tcl, Python, VisualBasic, ...) • Adapt cgi model to SIP  sip-cgi • RFC 3050