DesignBuddyList » History » Revision 27
Revision 26 (Adrian Georgescu, 07/13/2009 07:07 PM) → Revision 27/115 (Adrian Georgescu, 07/13/2009 07:08 PM)
= Presence blueprint design = [[TOC(Design*, depth=1)]] This is a high level class that can be used to manage a buddy list driven interface of a SIP client graphical user interface. It implements a combination of SIP SIMPLE standards related to presence event package, its storage and policy. * Account * Address-book * Buddy list * Presence watcher list * Presence rules * Dialog watcher list * Dialog rules * Icon exchange == Account == This is the same entity that Registers and does other operations in behalf of the SIP account. On boot * Initialize the '''buddy list''' from XCAP documents cache if any, otherwise build an empty list to be used by the GUI at boot time * Initialize '''presentity''' from local cache * Locate XCAP server by doing a DNS TXT lookup for xcap.example.com, deal with DNS timeout * GET XCAP application xcap-caps * Dependent on the content of xcap-caps, GET the default filename for pres-rules, resource-lists, pidf-manipulation, rls-services, dialog-rules, icon, xcap-directory applications from XCAP server and cache all documents, deal with HTTP timeout * If '''pres-rules''' application is supported by XCAP server, send Subscribe for event presence.info and initialize presence '''watchers''' list * If '''icon''' application is supported by XCAP server, GET curent icon image from the xcap server * If '''dialog-rules''' application is supported by XCAP server, send Subscribe for event dialog.info and initialize dialog '''watchers''' list * if '''pidf-manipulation''' application is supported by XCAP server, update the '''presentity''' with '''pidf-manipulation''' document * Send PUBLISH for '''Event: presence''' * If '''account.message_summary.enabled''' SUBSCRIBE for '''Event: message-summary''' * If '''account.presence.subscribe_xcap_diff.enabled''' SUBSCRIBE for '''Event: xcap-diff''' * Load '''buddy list''' While running * Refresh XCAP server location based on DNS TTL * Refresh PUBLISH for event '''presence''' * Refresh SUBSCRIBE to '''presence.winfo''' * Refresh SUBSCRIBE to '''dialog.winfo''' * Refresh SUBSCRIBE to '''xcap-diff''' * Refresh SUBSCRIBE to '''message-summary''' * Reload XCAP documents based on '''xcap-diff''' xcap-diff NOTIFYs * Update '''presentity''' based on GUI actions or automatica sensors and cache it On shutdown * Cache last '''presentity''' == Address book == Use the OS standard address book. == Buddy list == Contains a list of buddies we subscribe to. The buddylist is indexed by a unique SIP URI. Additional, one can store full names and other attributes. Based on NOTIFY for event=presence each buddy has a '''Presentity''' attribute that contains published information. GUI displays various attributes of each presentity. * The buddy list is stored in the main '''resource-lists''' XCAP document '''index''' * Maintain a '''presentity''' attribute with what is received in the Notify for each buddy * If '''account.presence.subscribe_rls_services''' is true, a RLS document that contains a list of discrete SIP URIs we subscribe to and PUT it on the server under SIP URI account-buddies@domain. Then a Subscribe is sent with Supported: eventlist for this SIP URI. /otherwise send SUBSCRIBVE to each buddy for '''Event: presence''' * On buddy lists change, PUT resource-lists and rls-services documents on the XCAP server and cache them locally * account.presence.subscribe_rls_services must be normalized when set to '''auto''' == Presence watcher lists == Built based on the body of NOTIFY for event=presence.winfo. == Presence rules == * Based on NOTIFY for event watcher.info we update the policy * PUT pres-rules document on the XCAP server and cache locally == Dialog watcher lists == Built based on the body of NOTIFY for event=dialog.winfo. To be built in OpenSIPS. == Dialog rules == Based on NOTIFY for event dialog.info we update the policy and PUT dialog-rules document on the XCAP server. To be built in OpenXCAP server. == Icon exhange == Support in OpenXCAP server is necessary, see http://openxcap.org/ticket/100 Publishing end-point, on boot: 1. HTTP GET for xcap-directory and locate previously uploaded icon (e.g. ABC.png) 1. HTTP GET http://xcap.example.com/xcap-root/icon/users/sip:alice@example.com/ABC.png Publishing end-point, on change: 1. Generate a new random filename: XYZ 1. Build URL http://xcap.example.com/xcap-root/icon/users/sip:alice@example.com/XYZ.png 1. HTTP PUT to xcap server 1. Update <icon> element of pidf and PUBLISH new pidf 1. HTTP DELETE any previous icon file ABC.png Subscribing end-point: 1. Parse <icon> element of pidf received in Notify 2. HTTP GET http://xcap.example.com/xcap-root/icon/users/sip:alice@example.com/XYZ.png 3. Cache picture until next NOTIFY with diferent <icon> element is received