The Future of SIP and Presence Jonathan Rosenberg
The Future of SIP and Presence Jonathan Rosenberg Chief Scientist
A Brief IETF History March 1998 IETF begins investigating IM and presence in the PIPR Bo. F. August 1998 Idea of SIP for Presence is first proposed to PIPR. SIP 2003 2
Where Are We Now? l SIP for Instant Messaging (aka the MESSAGE Method) Completed n RFC 3428 issued December 2002 l Instant Messaging Sessions Making Progress n Could not agree on a transport for a long time (almost 9 months) n Finally agreed on CPIM/TCP l SIP for Presence Specifications Completed in May 2002 and Submitted to IESG for Approval n Baseline presence spec (draft-ietf-simple-presence) n Watcherinfo spec (draft-ietf-simple-winfo-package) n Watcherinfo XML format (draft-ietf-simple-winfo-format) n Work is progressing well on details l “Buddy List Package” n Subscribe to a list of users n Has received continuous attention for a year but had not stabilized n Finally stabilized on a satisfactory approach SIP 2003 3
Where Are We Going? l The Main Goal Is to Develop a Set of Component Capabilities for Building a Variety of Presence-based Systems l Guiding Principles n Presence will drive many applications, not just IM n Presence will be used as an integral part of any communications system n Wireless is a key customer l Main Activities in 2003 n Application configuration data manipulation n Generic IM features l is. Typing l Delivery status notification n Presence filtering n Presence document enhancements n Completion of buddy list package, messaging sessions n BCP for IM systems SIP 2003 4
Data Manipulation l l Presence and IM Systems Make Significant Use of Application Configuration Data (ACD) n The buddy list n White/black lists, authorization policy ACD Is Read and Written by End Users l ACD Is Read and Written by Network Applications l Example: Buddy List n User adds Joe to Buddy List using ACD manipulation protocol n ACD server stores new list n User subscribes to their buddy list n Presence server fetches the buddy list from the ACD server n Presence server fans out subscriptions ACD Server Get Buddy List Fanned Out Subscriptions Add Joe to Buddy List SUBSCRIBE to Buddylist SIP 2003 5
ACD Needs l ACD Is Needed in Other Areas in the SIP Universe n Conferencing policies l Who can and cannot join l Who can be moderator l Creating conferences n Group calling n Network speed dials l All ACD Usages Share Common Requirements n Synchronization with end device n End user authentication n Extensive authorization support l Only Joe can write his own buddy list, but his department can read it n ACID (Atomicity, Consistency, Isolation, Durability) n Support lots of clients n Work for wireless devices n Manipulation by end user clients n Usage by a single user across multiple devices n General editing – add elements, remove elements, change elements, list elements SIP 2003 6
Approaches for ACD l Two Approaches n Vertical protocols n General protocol l General Protocol and Server n Single protocol and server for managing ACD for all applications n Server itself is schema l Vertical Protocols n Design a specific protocol for managing the specific data for each application n This is the Wireless Village, PRIM, XMPP approaches independent and ignorant n Protocol is schema independent n Hard to design generically n BUT, works famously for multi-application networks l Easier to share data across applications l Easy to add new applications (no server changes – just publish a new schema, used only by the application) l Easy to tie in to customer care, operations n Easy to design a specific protocol n BUT, network complexity is horrible when you get multiple applications l Hard to share data l Expensive to add new applications l Needs tie in to customer care, operations, etc. SIP 2003 7
What Are the Challenges? l The Data Model n Generic enough to support a broad set of applications n Simple enough to be implementable in a wide variety of devices n Example data models l l l Structure of Managed Information (SMI) from SNMP ACAP data model SQL relational Database l Authorization n Who is allowed to l l l Extensibility n Making sure future applications can be supported without requiring server or database changes l Synchronization n Handling the case of multiple clients each updating the same data n Need a notification mechanism to indicate changes in data Read Write Search Delete Create n Are user groups needed? SIP 2003 8
is. Typing l What Is It? Existing IM feature that lets users know whether the other user is typing a reply n Very useful in non-streaming interactive applications n l Generalization n “Typing” represents non- streaming interactive text n There are other media types – voice, video l Solution Possibilities n SIP Events – SUBSCRIBE to it, get notified when the typing state changes l Hard to work with page mode l Hard to sequence with the actual messages n Would like to generalize is. Typing to general composition of nonstreaming media n Useful for voice IM, for example n MESSAGE body type l Works with page and session mode l Will work through CPIM gateways l In same sequence space as actual messages l Use SDP to signal capability to use it SIP 2003 9
Delivery Status Notifications l DSNs Indicate That a Message Was Ultimately Received or Failed l Common in Email (RFC 1894) l Several Uses in IM n In Session Mode, used to indicate whether message is received by the endpoint or fails l RFC 1894 Is Almost Perfect, but Not Quite n Specific to email n DSNs are quite large, would like something smaller for wireless l Work Will Be in Determining the Level of Reuse of RFC 1894 for IM n In session or page mode, handles delivery through gateways (SMS gateway) where final status is unknown at time of sending n In page mode, handles delivery when recipient is not online, and logs on later to retrieve their IM SIP 2003 10
Presence Filtering l Presence Is All About POLICY l There Are Three Players Who Have Policy Inputs l l n The watcher n The presentity n The administrator A Complete System Needs to Allow All Three Parties to Express Their Policy Requirements Presentity Policy n l Watcher Policy Overall Policy Through ACD manipulation – set specific policies Administrator Policy n l Presentity Policy Through operational and provisioning interfaces, usually not standardized But, How Does the Watcher Indicate Their Policies? Admin Policy SIP 2003 11
Presence Filtering l Examples of Watcher Policies l Task Is to Specify a Document Format for Presence Policy n Send me only geoloc information n Send me presence updates only when the status goes from offline to online l Main Challenge: Scope n Potentially unbounded: n Don’t send me notifications faster than once per minute “Send me only geoloc information when the basic status changes from online to offline if there are four tuples but only if one of those tuples supports IM and at least one of the remaining three indicates a SIP URI” l RFC 3265 Leaves a Space for This Problem n SUBSCRIBE bodies contain policy document, called a “filter” n No documents currently defined l Two Axes of Filtering n On what state changes are l Main Issue: Presence Specific or Generic for All SIP-events n Conclusion: most of it is package specific notifications sent n What is the content of the notifications that get sent SIP 2003 12
Presence Document Enhancements l Current PIDF Document Is Minimalistic n OPEN/CLOSED status n Multiple tuples, each with its own address, status and display note n l l l n l That’s it n Tuple naming extensions n Device capabilities n General status n Static content l n Example: “send me only the PC tuple” Media types Codecs SIP Methods Would like to reflect this information in presence documents l Indicate that tuple 1 supports audio and video General Status Busy, in a meeting, out to lunch, etc. n Do these need to be standardized, or does a textual note suffice? n Main issue: what is needed for an automata to process n Tuple Naming Extensions Need a way to refer to a tuple for policy reasons SIP Caller Preferences extension allows a device to indicate its capabilities l Several Potential Areas of Extension n Device Capabilities l Static Content v. Card, Image Thumbnail, recording of my name n Indirection or inline content n SIP 2003 13
Putting It All Together l l l The Challenge: Build a Consumergrade IM/buddylist Application Using IETF Protocols, Comparable to Yahoo, AOL, MSN in Features l n SIP for presence n MESSAGE method, messaging sessions n Data manipulation n IMAP (IM message store) n HTTP (content indirection) n Whois++ (profile searches) n HTML (emoticons) Verify that we have all the pieces standardized to do so n SIP (PC to phone, webcams) n SIP Conferencing (IM conferences) Instruct operators on how to fit all the pieces together n Floor control protocols (IM conferences) n Content Indirection (file sharing) SIMPLE to Generate a Document Explaining How Serves Several Purposes n n Makes Use of Many Protocols l Will Provide Guidelines on How to Use Some of These Protocols l System Integration Is the Hardest Part SIP 2003 14
Resources l SIMPLE Charter: http: //www. ietf. org/html. charters/simple-charter. html l Advanced IM Requirements: http: //www. ietf. org/internet-drafts/draft- rosenberg-simple-messaging-requirements-00. txt l SIMPLE Components Model: http: //www. jdrosen. net/papers/draft- rosenberg-simple-components-00. txt SIP 2003 15
Information Resource Jonathan Rosenberg Chief Scientist +1 973. 952. 5000 jdrosen@dynamicsoft. com
- Slides: 16