VoIP - beyond replicating the limitations of the past

1. VoIP - beyond replicating the limitations of the past Henning Schulzrinne Dept. of Computer Science, Columbia University, New York (based on work in collaboration with IRT students & staff, as well as the IETF GEOPRIV and SIMPLE WGs) hgs@cs.columbia.edu Lucent-Alcatel Stuttgart January 31, 2008

2. Outline • VoIP maturing: vision vs. reality • presence and location-based services • user-programmable services • VoIP challenges • scaling • peer-to-peer systems • spam/SPIT • emergency calling • The state of SIP standardization, year 11 • developments in 2006 & upcoming highlights • trouble in standards land • interoperability

3. The three Cs of Internet applications grossly simplified... communications commerce community what users care about what users care about research focus

4. Killer Application • Carriers looking for killer application • justify huge infrastructure investment • “video conferencing” (*1950 – †2000) • ? • “There is no killer application” • Network television block buster  YouTube hit • “Army of one” • Users create their own custom applications that are important to them • Little historical evidence that carriers (or equipment vendors) will find that application if it exists • Killer app = application that kills the carrier

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

6. IETF VoIP efforts ECRIT (emergency calling) ENUM (E.164 translation) SIMPLE (presence) uses SPEERMINT (peering) GEOPRIV (geo + privacy) uses may use uses XCON (conf. control) SIP (protocol) SIPPING (usage, requirements) uses provides IPTEL (tel URL) SPEECHSC (speech services) usually used with MMUSIC (SDP, RTSP, ICE) AVT (RTP, SRTP, media) SIGTRAN (signaling transport) IETF RAI area

7. Old vs. new

8. Presence and event notification

9. Left to do: glue protocols • Lots of devices and services • cars • household • environment • Generally, stand-alone • e.g., GPS can’t talk to camera • Home • home control networks have generally failed • cost, complexity • Environment • “Internet of things” • tag bus stops, buildings, cars, ...

10. Left to do: event notification • notify (small) group of users when something of interest happens • presence = change of communications state • email, voicemail alerts • environmental conditions • vehicle status • emergency alerts • kludges • HTTP with pending response • inverse HTTP --> doesn’t work with NATs • Lots of research (e.g., SIENA) • IETF efforts starting • SIP-based • XMPP

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

12. Guess-and-ring 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

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

14. Presentity and Watchers Presence Server (PS) Bob’s Presentity Watchers SUBSCRIBE Watchers Watchers PUBLISH NOTIFY Available, Busy, Somewhat available, Invisible Bob’s status, location Bob’s Filters (Rules), PIDF *) wife PUBLISH son R u there ? friend BUZZ Cell Phone PC-IM Client Bob’s play station external world Bob’s Presence User Agents (PUA) *) - PIDF = Presence Information Data Format

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, 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 • does not provide enough context for directing interactive communications

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

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

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

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

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

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

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

25. Privacy policy relationships common policy geopriv-specific presence-specific future RPID CIPID

26. Conditions identity, sphere 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 privacy-safe composition: removal of a rule can only reduce privileges Extendable to new presence data rich presence biological sensors mood sensors Privacy rules

27. Example rules document <rule id=1> <identity><id>user@example.com</id></identity> <conditions> <sub-handling>allow</sub-handling> <actions> <provide-services> <service-uri-scheme>sip</service-uri-scheme> <service-uri-scheme>mailto</service-uri-scheme> </provide-services> <provide-person>true</provide-person> <provide-activities>true</provide-activities> <provide-user-input>bare</provide-user-input> <ruleset> <transformations>

28. Creating and manipulating rules • Uploaded in whole or part via XCAP • XML not user-visible • Web or application UI, similar to mail filtering • Can also be location-dependent • “if at home, colleagues don’t get presence information” • Possibly implementation-defined “privacy levels”

29. Location-based services

30. Location-based services directions traffic management car park assistance indoor routing people & vehicle tracking emergency calls Tracking product tracking Emergency Navigation automotive assistance shopping guides banners & alerts Advertising travel & tourist guides location-based services Information mobile yellow pages road tolling Billing travel planner facility Games Infrastructure geocaching Management Leisure customer relationship mobile games fleet (scheduling) Communications instant messaging buddy finder location-aware call handling security environmental Foundations of Location-based Services (Steinger, Neun, Edwardes), modified)

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

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

33. Location determination options

34. Location delivery GPS HELD HTTP wire map DHCP LLDP-MED

35. Local Switch Automatic Number Identification Automatic Location Identification Collaboration between local phone providers and local public safety agencies

36. What makes VoIP 112/911 hard?

37. UA recognition & UA resolution location information mapping mapping may recurse DHCP LLDP-MED 9-1-1 (dial string) leonianj.gov INVITE urn:service:sos To: urn:service:sos Route: sip:fire@leonianj.gov <location> INVITE urn:service:sos To: urn:service:sos Route: sip:psap@leonianj.gov <location> identification TBD

38. LoST: Location-to-URL Mapping VSP1 cluster serving VSP1 replicate root information cluster serves VSP2 123 Broad Ave Leonia Bergen County NJ US LoST root nodes NJ US NY US sip:psap@leonianj.gov search referral Bergen County NJ US Leonia NJ US

39. Program location-based services

41. Application: Verizon SABIT PALS • SABIT = web-based mobile employee productivity management system • PALS - Presence-Aware Location-Based Service • Advanced communication services based on aggregation of presence information • Enhanced vehicle management system • Presence/availability information of a user is combined with the location information (of the vehicle) to achieve an integrated communication environment • “only call when vehicle is stopped” *) - Verizon Service Assurance Business Intelligence Toolkit

42. SABIT PALS Solution Integrates: • Status and diagnostic information of the vehicle • Mobile employee’s location data obtained from a GPS device in a vehicle • Mobile employee’s presence information data obtained from his/her cell-phone • Laptop-based IM/VoIP soft client

43. VZ Data/Real Time Field Tech Laptop-Connect via WiFi or Ethernet VZ VPN GPS EVDO WiFi Components of PALS architecture • Integrated In-Vehicle Device (IIVD – Vehicle Events) • SABIT System • HTTP-SIP Gateway (LBS Presence User Agent) • Media Server • Watcher or Supervisor Application • Presence Server (PS)

44. SABIT PALS Architecture DB DB Location from vehicle GPS SABIT System EVDO Watcher SUBSCRIBE Presence Server HTTP/ SIP Gateway Watcher PUBLISH HTTP NOTIFY Media Server Gateway MSC/HLR PUBLISH SIP Proxy SABIT Supervisor “sees” mobile employees via the web-interface Mobile Employee’s status is relayed through multiple devices Systems View

45. SABIT PALS Supervisor Application

46. Communications Webpage

47. Roadmap • Introduction • Presence • Location-based services • Server scaling • P2P SIP • Standardization and interoperability

48. SIP server overload overloaded Springsteen tickets!! earthquake vote for your favorite… • Proxies will return 503 --> retry elsewhere • Just adds more load • Retransmissions exacerbate the problem INVITE 503 overloaded overloaded

49. Avalanche restart • Large number of terminals all start at once • Typically, after power outage • Overwhelms registrar • Possible loss of registrations due to retransmission time-out #1 REGISTER #300,000 reboot after power outage

50. Overload control • Current discussion in design team • Feedback control: rate-based or window-based • Avoid congestion collapse • Deal with multiple upstream sources goodput capacity offered load