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 IIT VoIP Conference and Expo Wheaton, Illinois October 25, 2007

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

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

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

33. Location-based service language NOTIFY true false action alert IM alert incoming proximity message outgoing log conditions occupancy actions events notify call message time transfer subscription join

34. Program location-based services

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

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

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

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

40. SABIT PALS Supervisor Application

41. Communications Webpage

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

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

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

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

46. Coordinated Overload Control Architecture Coordinated overload control with explicit feedback ietf-hilt draft model • Feedback scope: explicit feedback treated hop-by-hop vs. end-to-end • hop-by-hop feedback is generally believed to be more feasible

47. Need TCP TLS support: customer privacy, theft of service, … particularly for WiFi many SIP messages now exceed reasonable UDP size (fragmentation) e.g., INVITE for IMS: 1182 bytes Concern: UA support improving: 82% of systems at recent SIPit’19 had TCP support only 45% support TLS Concern: TCP (and TLS) much less efficient than UDP running series of tests to identify differences difference mainly in connection setup cost message splitting (may need pre-parsing or incremental parsers) thread count (one per socket?) Our model: 300,000 customers/servers 0.1 Erlang, 180 sec/call 600,000 BHCA --> 167 req/sec 300,000 registrations --> 83 req/sec $0.001/subscriber Scaling servers & TCP

48. Initial INVITE measurements OpenSER 400 calls/sec for TCP roughly 260 calls/sec for TLS SIP server measurements TCP sipd REGISTER test Kumiko Ono, Charles Shen, Erich Nahum

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

50. P2P SIP generic DHT service • Why? • no infrastructure available: emergency coordination • don’t want to set up infrastructure: small companies • Skype envy :-) • P2P technology for • user location • only modest impact on expenses • but makes signaling encryption cheap • NAT traversal • matters for relaying • services (conferencing, …) • how prevalent? • New IETF working group formed • likely, multiple DHTs • common control and look-up protocol? p2p network P2P provider B DNS P2P provider A traditional provider zeroconf LAN