From anywhere, anytime communications to personalized communication

1. From anywhere, anytime communications to personalized communication Henning Schulzrinne (with Ron Shacham, Xiaotao Wu, Jonathan Lennox and others) Department of Computer Science Columbia University hgs@cs.columbia.edu IMTC Forum May 11, 2005 (Eibsee, Germany) IMTC Forum 2005

2. Overview • Basic multimedia communication ready • … but implementation lags • Ring-and-hope  presence-mediated communications • Uses for presence: • Old: “I’m on-line” • Location-based services • Presence-derived call handling • Presence-derived trust • Presence and privacy • Other open issues in conferencing IMTC Forum 2005

3. 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 IMTC Forum 2005

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

5. 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 IMTC Forum 2005

6. SIP, SIPPING & SIMPLE –00 drafts includes draft-ietf-*-00 and draft-personal-*-00 IMTC Forum 2005

7. 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 IMTC Forum 2005

8. Does it have to be that complicated? • highly technical parameters, with differing names • inconsistent conventions for user and realm • made worse by limited end systems (configure by multi-tap) • usually fails with some cryptic error message and no indication which parameter • out-of-box experience not good IMTC Forum 2005

9. Aside: Why is Skype successful? • All the advantages of a proprietary protocol • Peer-to-peer coincidental • only need 6 servers to support 10 million users • Good out-of-box experience  it just works • Software vendor = service provider • Didn’t know that you couldn’t do voice quality beyond PSTN • others too focused on PSTN interoperability – why do better voice than PSTN? • Simpler solutions for NAT traversal • use TCP if necessary • use port 80 • Did encryption from the very beginning • Kazaa marketing vehicle IMTC Forum 2005

10. 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 IMTC Forum 2005

11. 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- IMTC Forum 2005

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 IMTC Forum 2005

13. 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 IMTC Forum 2005

14. 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, …) IMTC Forum 2005

15. RPID: rich presence IMTC Forum 2005

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

17. 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 IMTC Forum 2005

18. 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 IMTC Forum 2005

19. 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> IMTC Forum 2005

20. 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 IMTC Forum 2005

21. Program location-based services IMTC Forum 2005

22. Presence for spam prevention • VoIP spam (“spit”) and IM spam (“spim”) likely to be more annoying than email spam • Subscription to another person is indication of mutual trust • other person allows me to see their status  trusts me • Thus, use watcher list (who is watching me) as trust vector IMTC Forum 2005

23. Open issues for conferencing standardization • Multi-device systems and session mobility • Conference floor control  BFCP • simple RPC-like protocol • Centralized conference control (XCON WG) • still struggling with control model • set + get variables (~SNMP) • RPC-like model ( SOAP, XML-RPC, NETCONF) • send descriptions? • forms (XForms?)? IMTC Forum 2005

24. Session mobility Local Devices Transcoder Internet SLP DA SLP UA SLP SA SIP SM SIP UA SIP UA Correspondent Node (CN) SLP SIP RTP SIP SM SIP UA SLP UA IMTC Forum 2005 Mobile Node (MN)

25. Tree  inheritance Each level can be addressed via a URL Each layer links to parents and children Lowest layer information wins Parent can designate variables that cannot be overridden (“forced global”) Easily supports (corporate) policies recurring events with exceptions modifying the active conference only Probably also supports side bars and other multi-policy configurations permanent text chat rooms Each node can reference scheduling information but may not The conference tree all Acme Widget conferences weekly eng. mtg. instance 1 IMTC Forum 2005

26. Logical XCON Server • TEMPLATE • Of the SYSTEM: • Pre-configured • Initial/Default values • TEMPLATE Policy: • Of TYPE RULES • RESERVATION • Of the INSTANCE: • Of TYPE CONFERENCE-INFO • RESERVATION Policy: • Of TYPE RULES • CURRENT Policy: • Of TYPE RULES • STATE • Of the CURRENT INSTANCE: • Of TYPE CONFERENCE-INFO CCCP Server • Conf Event • Notification • Server • Floor • Control • Server • CPCP • Server Focus SIP/ PSTN/ H.323 T.120/ Etc. SIP NOTIFY/ Etc. CCCP CPCP BFCP CPCP Client CCCP Client Notification Client Floor Control Client Call Signaling Client Logical XCON Client XCON System IMTC Forum 2005

27. 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 IMTC Forum 2005

28. 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 IMTC Forum 2005

29. Conclusion • Basic multimedia communication solutions available • scalable, secure, good quality • Media delivery  controlled interaction • Binary presence  rich presence • Presence as enabler of loosely-coupled advanced services • location-based services • serve as service script inputs • trust indicator for spit/spim prevention • Application sharing as missing link • Harder to maintain focus in the IETF • exhaustion, moving on to other things IMTC Forum 2005

30. Backup slides IMTC Forum 2005

31. 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 IMTC Forum 2005

32. 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 IMTC Forum 2005

33. RPID: rich presence IMTC Forum 2005