1. IMTC Forum 20051 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)

2. IMTC Forum 20052 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

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

4. IMTC Forum 20054 SIP is PBX/Centrex ready call waiting/multiple calls RFC 3261 holdRFC 3264 transferRFC 3515/Replaces conferenceRFC 3261/callee caps message waitingmessage summary package call forwardRFC 3261 call parkRFC 3515/Replaces call pickupReplaces do not disturbRFC 3261 call coverageRFC 3261 from Rohan Mahy’s VON Fall 2003 talk simultaneous ringing RFC 3261 basic shared linesdialog/reg. package barge-inJoin “Take”Replaces Shared-line “privacy” dialog package divert to adminRFC 3261 intercomURI convention auto attendantRFC 3261/2833 attendant consoledialog package night serviceRFC 3261 centrex-style features boss/admin features attendant features

5. IMTC Forum 20055 An eco system, not just a protocol SIP XCAP (config) RTSP SIMPLE policy RPID …. SDP XCON (conferencing) STUN TURN RTP configures initiatescarries controls provide addresses

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

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

8. IMTC Forum 20058 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

9. IMTC Forum 20059 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

10. IMTC Forum 200510 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 timeCPL capabilitiescaller preferences locationlocation-based call routing location events activity/availabilitypresence sensor data (mood, bio)privacy issues similar to location data

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

12. IMTC Forum 200512 The role of presence 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) Prediction: almost all (professional) communication will be presence-initiated or pre-scheduled

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

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

15. IMTC Forum 200515 RPID: rich presence

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

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

18. IMTC Forum 200518 The role of presence for call routing 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) LESS translate RPID CPL PA PUBLISH NOTIFY INVITE

19. IMTC Forum 200519 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 <gml:Point gml:id="point1“ srsName="epsg:4326"> 37:46:30N 122:25:10W no 2003-06-23T04:57:29Z 2003-06-22T20:57:29Z

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

21. IMTC Forum 200521 Program location-based services

22. IMTC Forum 200522 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

23. IMTC Forum 200523 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?)?

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

25. IMTC Forum 200525 The conference tree 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 all Acme Widget conferences weekly eng. mtg. instance 1

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

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

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

29. IMTC Forum 200529 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

30. IMTC Forum 200530 Backup slides

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

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

33. IMTC Forum 200533 RPID: rich presence