Ubiquitous SIP

1. Ubiquitous SIP Henning Schulzrinne (with Stefan Berger, Stelios Sidiroglou, Kundan Singh, Xiaotao Wu, Weibin Zhao and the RPIDS authors) Columbia University IRT Lab Hewlett Packard – March 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. Locations • Geographic location • latitude, longitude, altitude, velocity, heading • Civil location (≠ postal location!) • 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”

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

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

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

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

26. Location-based 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

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

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

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

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

31. RPIDS: Rich presence data • Integrates caller preferences information into presence announcements • <class>: presentity, group, device • <category>: 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 • <activity>, <idlesince>: activity for device • <relationship>: family, associate, assistant, supervisor • <label>: permanent label, not to be modified

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

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

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

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

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

37. CINEMA system

38. All-SIP implementation

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

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

41. sip-cgi examples • Block *@vinylsiding.com: if (defined $ENV{SIP_FROM} && $ENV{SIP_FROM} =~ "sip:*@vinylsiding.com") { print "SIP/2.0 600 I can't talk right now\n\n"; } • Make calls from boss urgent: if (defined $ENV{SIP_FROM} && $ENV{SIP_FROM} =~ /sip:boss@mycompany.com/) { foreach $reg (get_regs()) { print "CGI-PROXY-REQUEST $reg SIP/2.0\n"; print "Priority: urgent\n\n"; } }

42. Call Processing Language (CPL) • XML-based “language” for processing requests • intentionally restricted to branching and subroutines • no variables (may change), no loops • thus, easily represented graphically • and most bugs can be detected statically • termination assured • mostly used for SIP, but protocol-independent • integrates notion of calendaring (time ranges) • structured tree describing actions performed on call setup event • top-level events: incoming and outgoing

43. CPL • Location set stored as implicit global variable • operations can add, filter and delete entries • Switches: • address • language • time, using CALSCH notation (e.g., exported from Outlook) • priority • Proxy node proxies request and then branches on response (busy, redirection, noanswer, ...) • Reject and redirect perform corresponding protocol actions • Supports abstract logging and email operation

44. CPL example

45. CPL example <?xml version="1.0" ?> <!DOCTYPE call SYSTEM "cpl.dtd"> <cpl> <incoming> <lookup source="http://www.example.com/cgi-bin/locate.cgi?user=jones" timeout="8"> <success> <proxy /> </success> <failure> <mail url="mailto:jones@example.com&Subject=lookup%20failed" /> </failure> </lookup> </incoming> </cpl>

46. CPL example: anonymous call screening <cpl> <incoming> <address-switch field="origin" subfield="user"> <address is="anonymous"> <reject status="reject" reason="I don't accept anonymous calls" /> </address> </address-switch> </incoming> </cpl>

47. Service creation – a comparison

48. Service creation for presence services (work-in-progress) • Accept or deny subscriptions • Shape presence notifications • different level of detail for family, friends and colleagues • particularly important for geo data • Subscriber can filter detail • primarily, wireless bandwidth constraints • rate limit notifications • XPath? • Mostly, condition/reaction  CPL can be extended to most of these functions

49. Pushing context-sensitive data to users • User with mobile device should get location information when entering city, campus or building • flight and gate information • maps and directions • local weather forecast • special advisories (“choose security checkpoint 2”) • Often does not require knowing user • but interface with (e.g.) calendar • Example Columbia implementation: • OBEX data exchange over BlueTooth • PDA pushes current appointment or event name • base station delivers directions and map

50. Conclusion • SIP + auxiliary protocols supports many of the core requirements for ubiquitous computing and communications: • mobility modalities: terminal, user, session, service • service negotiation for devices with different capabilities • automatic configuration and discovery • with SLP or similar • event notification and triggered actions • automatic actions: event filtering, CPL, LESS (for end system services) • SIP offers a loosely-coupled approach (cf. Jini or object models) • Also need data push functionality • Avoid tendency to assume SIP users are human – want to interconnect different components and devices • SIP device configuration needs automation, rather than screen-scraping