Moving VoIP beyond the phone

1. Moving VoIP beyond the phone Henning Schulzrinne Dept. of Computer Science Columbia University September 2005

2. Overview • The big transitions in VoIP • Voice, media  meta data • rich presence, caller preferences, events, … • Programmable VoIP services • servers and end systems • Spam and spit • Emergency calling (“9-1-1”) • beyond PSTN replacement • Maintaining reliable systems • administratively distributed systems

3. Philosophy transition PC era cell phone era One computer/phone, many users One computer/phone, one user mainframe era home phone party line Many computers/phones, one user ~ ubiquitous computing  embedded VoIP anywhere, any time any media right place (device), right time, right media

4. Collaboration in transition inter-organization multiple technology generations diverse end points intra-organization; small number of systems (meeting rooms) standards-based solutions proprietary (single-vendor) systems

5. Evolution of VoIP “how can I make it stop ringing?” long-distance calling, ca. 1930 “does it do call transfer?” going beyond the black phone “amazing – the phone rings” catching up with the digital PBX 1996-2000 2000-2003 2004-

6. Internet services – the missing entry

7. Filling in the protocol gap

8. An eco system, not just a protocol configures XCAP (config) XCON (conferencing) SIMPLE policy RPID …. initiates carries SIP RTSP SDP carries controls provide addresses RTP STUN TURN

9. SIP – a bi-cultural protocol • multimedia • IM and presence • location-based service • user-created services • decentralized operation • everyone equally suspect • overlap dialing • DTMF carriage • key systems • notion of lines • per-minute billing • early media • ISUP & BICC interoperation • trusted service providers

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

11. SIP design objectives • new features and services • support features not available in PSTN • e.g., presence and IM, session mobility • not a PSTN replacement • not just SS7-over-IP • even similar services use different models (e.g., call transfer) • client heterogeneity • clients can be smart or dumb (terminal adapter) • mobile or stationary • hardware or software • client multiplicity • one user – multiple clients – one address • multimedia • nothing in SIP assumes a particular media type Rosenberg/Schulzrinne: draft-rosenberg-sipping-sip-arch-00

12. Interconnection approaches

13. Guess, ring and annoy high probability of failure: “telephone tag” inappropriate time (call during meeting) inappropriate media (audio in public place) current solutions: voice mail  tedious, doesn’t scale, hard to search and catalogue, no indication of when call might be returned automated call back  rarely used, too inflexible  most successful calls are now scheduled by email Presence-based facilitates unscheduled communications provide recipient-specific information only contact in real-time if destination is willing and able appropriately use synchronous vs. asynchronous communication guide media use (text vs. audio) predict availability in the near future (timed presence) The role of presence Prediction: almost all (professional) communication will be presence-initiated or pre-scheduled

14. Context-aware communication • 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

15. Basic presence • Role of presence • initially: “can I send an instant message and expect a response?” • now: “should I use voice or IM? is my call going to interrupt a meeting? is the callee awake?” • Yahoo, MSN, Google, Skype presence services: • on-line & off-line • useful in modem days – but many people are (technically) on-line 24x7 • thus, need to provide more context • + simple status (“not at my desk”) • entered manually  rarely correct • if user has time to update presence, they are not busy enough to use presence • does not provide enough context for directing interactive communications

16. Presence data model “calendar” “cell” “manual” person (presentity) (views) alice@example.com audio, video, text r42@example.com video services devices

17. Presence data architecture presence sources PUBLISH raw presence document privacy filtering create view (compose) depends on watcher XCAP select best source resolve contradictions XCAP privacy policy composition policy (not defined yet) draft-ietf-simple-presence-data-model

18. Presence data architecture candidate presence document raw presence document post-processing composition (merging) watcher filter remove data not of interest SUBSCRIBE difference to previous notification final presence document watcher NOTIFY

19. Rich presence • More information • automatically derived from • sensors: physical presence, movement • electronic activity: calendars • Rich information: • 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, …)

20. RPID: rich presence

21. The role of presence for call routing PUBLISH • Two modes: • watcher uses presence information to select suitable contacts • advisory – caller may not adhere to suggestions and still call when you’re in a meeting • user call routing policy informed by presence • likely less flexible – machine intelligence • “if activities indicate meeting, route to tuple indicating assistant” • “try most-recently-active contact first” (seq. forking) PA NOTIFY translate RPID CPL LESS INVITE

22. Presence and privacy • All presence data, particularly location, is highly sensitive • Basic location object (PIDF-LO) describes • distribution (binary) • retention duration • Policy rules for more detailed access control • who can subscribe to my presence • who can see what when <tuple id="sg89ae"> <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point gml:id="point1“ srsName="epsg:4326"> <gml:coordinates>37:46:30N 122:25:10W </gml:coordinates> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no </gp:retransmission-allowed> <gp:retention-expiry>2003-06-23T04:57:29Z </gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> <timestamp>2003-06-22T20:57:29Z</timestamp> </tuple>

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

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

25. Program location-based services

26. Service creation • Tailor a shared infrastructure to individual users • traditionally, only by vendors (and sometimes carriers) • learn from web models: killer app vertical apps

27. A different view of presence • Presence is problematic for facilitating calls • rapid changes + large watcher lists  high notification volume • privacy: don’t want to tell whole life story to all watchers •  on-demand presence information • just before communication • = SUBSCRIBE with zero duration • aggregate presence  synchronized calendars • either centralized or peer-to-peer • Likely uses shifting to true events • environment changes (traffic, weather, …) • people changes (visitor stuck in traffic)

28. Programming VoIP clients • Precursor: CTI • but rarely used outside call centers • Call external programs • e.g., Google/MSN maps, local search • Scripting APIs • e.g., call Tcl or PHP scripts  sip-cgi • Controllable • COM, XML RPC • used for media agents in sipc • Embeddable • no UI, just signaling and media

29. Automating media interaction – service examples • If call from my boss, turn off the stereo  call handling with device control • As soon as Tom is online, call him  call handling with presence information • Vibrate instead of ring when I am in movie theatre  call handling with location information • At 9:00AM on 09/01/2005, find the multicast session titled “ABC keynote” and invite all the group members to watch  call handling with session information • When incoming call is rejected, send email to the callee  call handling with email

30. LESS: simplicity • Generality (few and simple concepts) • Uniformity (few and simple rules) • Trigger rule • Switch rule • Action rule • Modifier rule • Familiarity (easy for user to understand) • Analyzability (simple to analyze) modifiers trigger switches actions

31. LESS: Decision tree • No loops • Limited variables • Not necessarily • Turing-complete

32. LESS: Safety • Type safety • Strong typing in XML schema • Static type checking • Control flow safety • No loop and recursion • One trigger appear only once, no feature interaction for a defined script • Memory access • No direct memory access • LESS engine safety • Ensure safe resource usage • Easy safety checking • Any valid LESS scripts can be converted into graphical representation of decision trees.

33. LESS snapshot incoming call <less> <incoming> <address-switch> <address is=“sip:myboss@abc.com"> <device:turnoff device=“sip:stereo_room1@abc.com”/> <media media=“audio”> <accept/> </media> </address> </address-switch> </incoming> </less> If the call from my boss Turn off the stereo Accept the call with only audio trigger, switch, modifier, action

34. SIP user agent SIP Device agent Presence agent Basic user agent presence Generic Media UI Event x10 vcr LESS packages • Use packages to group elements im email web calendar conference session location

35. When Tom is online, … <less> <EVENT:notification> <address-switch> <address is="sip:tom@example.com"> <EVENT:event-switch> <EVENT:event is="open"> <location url="sip:tom@example.com"> <IM:im message="Hi, Tom"/> </location> </EVENT:event> </EVENT:event-switch> ……… </less>

36. When I am in a movie theatre, … <less> <incoming> <location-switch> <location placetype=“quiet”> <alert sound=“none” vibrate=“yes”/> </location> </location-switch> </incoming> </less>

37. Interfacing with Google 911: caller location IM/presence: location of friends call: “I’m here”

38. Interfacing with Google show all files from caller Xiaotao Wu

39. Embedding VoIP: FAA training controls pilot and ATC agents – using multicast and unicast (“landlines”)

40. Open issues: application sharing • Current: T.120 • doesn’t integrate well with other conference control mechanisms • hard to make work across platforms (fonts) • ill-defined security mechanisms • Current: web-based sharing • hard to integrate with other media, control and record • generally only works for Windows • mostly limited to shared PowerPoint • Current: vnc • whole-screen sharing only • can be coerced into conferencing, but doesn’t integrate well with control protocols

41. IETF effort: standardized application sharing • Remote access = application sharing • Four components: • window drawing ops  PNG • keyboard input • mouse input • window operations (raise, lower, move) • Uses RTP as transport • synchronization with continuous media • but typically, TCP • allow multicast  large group sessions

42. SIP unsolicited calls and messages • Possibly at least as large a problem • more annoying (ring, pop-up) • Bayesian content filtering unlikely to work •  identity-based filtering • PKI for every user unrealistic • Use two-stage authentication • SIP identity work mutual PK authentication (TLS) home.com Digest

43. Domain Classification • Classification of domains based on their identity instantiation and maintenance procedures plus other domain policies. • Admission controlled domains • Strict identity instantiation with long term relationships • Example: Employees, students, bank customers • Bonded domains • Membership possible only through posting of bonds tied to a expected behavior • Membership domains • No personal verification of new members but verifiable identification required such as a valid credit card and/or payment • Example: E-bay, phone and data carriers • Open domains • No limit or background check on identity creation and usage • Example: Hotmail • Open, rate limited domains • Open but limits the number of messages per time unit and prevents account creation by bots • Example: Yahoo

44. Reputation service (“Trust paths”) David Carol has sent IM to has sent email to Frank Emily is this a spammer? Bob Alice for people and domains

45. Emergency calling • FCC mandate: all interconnected VoIP providers must provide E911 service by 11/05 • switch calls to right PSAP (via ESGW attached to switches) • deliver location information to PSAP for dispatch • location entered manually • Problems: • user-entered location  no nomadic, mobile users • PSAP infrastructure brittle (38 PSAPs out after Katrina)  fully IP-based allow relocation

46. What makes VoIP 112/911 hard?

47. Location, location, location • Location  locate right PSAP & speed dispatch • In the PSTN, local 9-1-1 calls remain geographically local • In VoIP, no such locality for VSPs • most VSPs have close to national coverage • Thus, unlike landline and wireless, need location information from the very beginning • Unlike PSTN, voice service provider doesn’t have wire database information • VSP needs assistance from access provider (DSL, cable, WiMax, 802.11, …)

48. Options for location delivery • L2: LLDP-MED (standardized version of CDP + location data) • periodic per-port broadcast of configuration information • L3: DHCP for • geospatial (RFC 3825) • civic (draft-ietf-geopriv-dhcp-civil) • L7: proposals for retrievals • by IP address • by MAC address • by identifier (conveyed by LLDP, DHCP or PPP) • via HTTP or maybe SIP

49. Architecture VSP ISP SIP config DHCP PSAPs outbound proxy DHCP home

50. LUMP mapping architecture carrier X customers knows all trees; caches results R R R R R R flooding nj.us ny.us bergen.nj.us leonia.bergen.nj.us generalizes to other location-based services