Henning Schulzrinne Columbia University (Sprint Labs, Burlingame, CA)

1. Global Ubiquitous Computing Henning Schulzrinne Columbia University (Sprint Labs, Burlingame, CA)

2. Agenda • SIP overview • SIP for ubiquitous computing • Location-based services • Emergency calling • Services, carriers and service creation • Security issues

3. SIP Overview

4. Internet services – the missing entry

5. Filling in the protocol gap

6. Rendezvous protocol lets users find each other by only knowing a permanent identifier Mobility enabler: personal mobility one person, multiple terminals terminal mobility one terminal, multiple IP addresses session mobility one user, multiple terminals in sequence or in parallel service mobility services move with user SIP as service enabler

7. 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 (RFC 3261-3265 et al) • 3GPP (for 3G wireless) • PacketCable • About 60 companies produce SIP products • Microsoft’s Windows Messenger (≥4.7) includes SIP

8. Philosophy • Session establishment & event notification • Any session type, from audio to circuit emulation • Provides application-layer anycast service • Provides terminal and session mobility • Based on HTTP in syntax, but different in protocol operation • Peer-to-peer system, with optional support by proxies • even stateful proxies only keep transaction state, not call (session, dialogue) state • transaction: single request + retransmissions • proxies can be completely stateless

9. Basic SIP message flow

10. SIP trapezoid destination proxy (identified by SIP URI domain) outbound proxy 1st request SIP trapezoid 2nd, 3rd, … request a@foo.com: 128.59.16.1 registrar voice traffic RTP

11. response request request line INVITE sip:bob@there.com SIP/2.0 SIP/2.0 200 OK Via: SIP/2.0/UDP here.com:5060 From: Alice <sip:alice@here.com> To: Bob <sip:bob@there.com> Call-ID: 1234@here.com CSeq: 1 INVITE Subject: just testing Contact: sip:alice@pc.here.com Content-Type: application/sdp Content-Length: 147 Via: SIP/2.0/UDP here.com:5060 From: Alice <sip:alice@here.com> To: Bob <sip:bob@there.com> Call-ID: 1234@here.com CSeq: 1 INVITE Subject: just testing Contact: sip:alice@pc.here.com Content-Type: application/sdp Content-Length: 134 header fields v=0 o=alice 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 v=0 o=bob 2890844527 2890844527 IN IP4 there.com s=Session SDP c=IN IP4 110.111.112.113 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 messagebody SIP message format SDP

12. RFC 3261 • Backward compatible with RFC 2543 – no new version • Major changes: • specification behavior-oriented, not header-oriented • e.g., separation into ‘layers’ • mandate support for UDP and TCP • formal offer/answer model for media negotiation • uses both SRV and NAPTR for server location, load balancing and redundancy • much more complete security considerations • “sips:’’ for secured (TLS) path • PGP removed due to lack of use • Basic authentication removed as unsafe • S/MIME added for protecting message bodies (and headers, via encapsulation) • Route/Record-Route simplified

13. PSTN vs. Internet Telephony PSTN: Signaling & Media Signaling & Media China Internet telephony: Signaling Signaling Media Australia Belgian customer, currently visiting US

14. SIP addressing • Users identified by SIP or tel URIs • sip:alice@example.com • tel: URIs describe E.164 number, not dialed digits (RFC 2806bis) • tel URIs  SIP URIs by outbound proxy • A person can have any number of SIP URIs • The same SIP URI can reach many different phones, in different networks • sequential & parallel forking • SIP URIs can be created dynamically: • GRUUs • conferences • device identifiers (sip:foo@128.59.16.15) • Registration binds SIP URIs (e.g., device addresses) to SIP “address-of-record” (AOR) tel:110 sip:sos@domain domain  128.59.16.17 via NAPTR + SRV

15. 3G Architecture (Registration) mobility management signaling serving interrogating interrogating CSCF proxy home IM domain registration signaling (SIP)_ visited IM domain

16. SIP is PBX/Centrex ready boss/admin features centrex-style features attendant features from Rohan Mahy’s VON Fall 2003 talk

17. Example SIP phones about $85

18. International  no national variants Internet = intranet separation of data and signaling signaling nodes can be anywhere end-to-end security where possible, hop-by-hop otherwise S/MIME bodies TLS (sips:) end system control of information proxies can inspect, modify and add headers may be able to inspect the message body (if not encrypted) should not modify the message body  may break end-to-end integrity no security by obscurity don’t rely on address or network hiding SIP architecture biases

19. SIP, SIPPING & SIMPLE –00 drafts includes draft-ietf-*-00 and draft-personal-*-00

20. Ubiquitous computing Location-based services Emergency calling

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

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

23. Context-aware communications • Traditional emphasis: communicate anywhere, anytime, any media  largely possible today • New challenge: tailor reachability • 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

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

25. “Legacy” IM & presence systems  SIP-based systems • centralized systems (single name space) • federated systems, similar to email • mostly instant text messages • media-agnostic – transmit any media object • separate from session-based services (VoIP, video conferencing) • integrated: • use IM as part of media sessions • use presence to facilitate session setup • limited presence status, mostly manually set • rich presence, with time information • imported from sensors, calendars, backend systems, … • proprietary systems (AOL, Yahoo!, MSN, ICQ, …) • standards-based systems

26. Presence = special case of event notification “user Alice is available for communication” Human users: multiple contacts per presentity device (cell, PDA, phone, …) service (“audio”) activities, current and planned surroundings (noise, privacy, vehicle, …) contact information composing (typing, recording audio/video IM, …) Multimedia systems: REFER (call transfer) message waiting indication conference floor control conference membership push-to-talk system configuration General events: emergency alert (“reverse 911”) industrial sensors (“boiler pressure too high”) business events (“more than 20 people waiting for service”) Presence and event notification

27. IETF efforts • SIP, SIPPING and SIMPLE working groups • but also XCON (conferencing) • Define SIP methods PUBLISH, SUBSCRIBE, NOTIFY • GEOPRIV: • geospatial privacy • location determination via DHCP • information delivery via SIP, HTTP, … • privacy policies • SIMPLE: • architecture for events and presence • configuration (XCAP) • session-oriented IM (↔ page mode) • filtering, rate limiting and authorization

28. RPID: rich presence • Provide watchers with better information about the what, where, how of presentities • facilitate appropriate communications: • “wait until end of meeting” • “use text messaging instead of phone call” • “make quick call before flight takes off” • designed to be derivable from calendar information • or provided by sensors in the environment • allow filtering by “sphere” – the parts of our life • don’t show recreation details to colleagues

29. Classification: contact-type device, in-person, service, presentity class for labeling sphere “work”, “home”, … relationship “family”, “associate”, “assistant”, “supervisor” Activities: activity “on-the-phone”, “away”, “appointment”, … idle last usage of device Surroundings: placetype “home”, “office”, “industrial”, … privacy “public”, “private” RPID: rich presence

30. CIPID: Contact Information • More long-term identification of contacts • Elements: • card – contact Information • home page • icon – to represent user • map – pointer to map for user • sound – presentity is available

31. Presence is about here & now but often only have (recent) past – e.g., calendar or future “will be traveling in two hours” “will be back shortly” allows watcher to plan communication loose synchronization of calendars <tuple id="7c8dqui"> <contact> sip:bob@example.com </contact> <status> <basic>open</basic> </status> <fs:timed-status from="2003-08-15T10:20:00.000-05:00“ until="2003-08-22T19:30:00.000-05:00"> <basic>closed</basic> </fs:timed-status> </tuple> <note>I'll be in Tokyo next week</note> Timed Status

32. GEOPRIV and SIMPLE architectures rule maker DHCP XCAP (rules) 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

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

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

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

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

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

38. Policy relationships common policy geopriv-specific presence-specific future RPID CIPID

39. Conditions identity, sphere, validity time of day current location identity as <uri> or <domain> + <except> Actions watcher confirmation Transformations include information reduced accuracy User gets maximum of permissions across all matching rules Extendable to new presence data rich presence biological sensors mood sensors Privacy rules

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

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

42. Location-based IM & presence

43. Old wireline and wireless models don’t work any more All wireline systems are potentially mobile (nomadic) device bought in Belgium place call in Canada with VSP in Mexico and maybe a VPN for extra excitement… Customer may not have a traditional voice carrier at all corporate residential  VSP in a different country Needs to work internationally same standards no custom configuration Components: universal identifier  “sos” configure local emergency numbers find right PSAP identify and verify PSAP On-going effort in IETF and NENA Emergency (911) services

44. Location-based call routing – UA knows its location GPS INVITE sips:sos@ 40.86N 73.98E CN=us A1=NJ A2=Bergen leonia.nj.us.sos.arpa POLY 40.85 73.97 40.86 73.99 NAPTR … firedept@leoniaboro.org outbound proxy server provided by local ISP? 40.86N 73.98E: Leonia, NJ fire dept. DHCP

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

46. Service creation

47. PSTN vs. VoIP and the role of carriers • PSTN: only carriers can get full signaling functionality (SS7) • UNI vs. NNI signaling • VoIP: same signaling, same functionality • Application-layer service providers (VSP) ≠ network-layer service provider • enterprise may run its own services • Columbia doesn’t use an ‘email service provider’…

48. Network vs. end system services • Really two meanings: • services implemented in user agent (instead of proxy) • services implemented in server run by end user (instead of carrier)  • business • residential • Variation on old Centrex vs. PBX argument • except that media routing no longer an issue • Often, services require or can use both: • e.g., the history of speed dial • CLASS service: translation in CO • (semi)intelligent end systems: locally, possibly with hotsync to PC • intelligent end system, but network-synchronized

49. Call routing services • Outsourcing allows temporarily disconnected end users • Staged service: carrier proxy user proxy personal preferences basic call routing

50. Carrier services: Identity management • Identity assertion (notary) services • best done by larger organization • server certificates • name recognition • recourse • Anonymity services • needs to have large user population to provide effective hiding • Portable services • high availability and universal reachability