DesignBuddyList » History » Revision 23
Revision 22 (Adrian Georgescu, 07/13/2009 06:04 PM) → Revision 23/115 (Adrian Georgescu, 07/13/2009 06:06 PM)
= Buddy list = [[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 a SIP account. On boot * Locate XCAP server by doing DNS TXT lookup for xcap.example.com * GET documents xcap-caps, pres-rules, resource-lists, pidf-manipulation, rls-services, dialog-rules, icon, xcap-directory from XCAP server * Cache documents * Send Subscribe for event presence.info * Send Subscribe for event dialog.info * Send Subscribe for event message-summary * Retrieve curent icon image from the xcap server icon auid * Build presentity based on pidf-manipulation document, if present * Send Publish for event presence * If rls-services present in xcap-caps, enable RLS and send Subscribe for event presence with Supported=eventlist While running * Refresh XCAP server location based on DNS time to live * Refresh Publish for event presence * Refresh subscription to presence.info * Refresh subscription to dialog.info * Refresh subscription to message-summary * Maintain a '''Presentity''' attribute received in Notify for each buddy == Address book == Use the OS standard address book == Buddy list == Contains list of buddies. The buddylist is indexed by the 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 parts of it. * The buddy list is stored in the main resource-lists XCAP document '''index''' * If '''account.presence.subscribe_rls_services''' is true, a RLS document that contains a list of discrete SIP URIs we subscribe to is PUT on the server under SIP URI account-buddies@domain. Then a Subscribe is sent with Supported: eventlist for this SIP URI. * On change, PUT resource-lists and rls-services documents on the XCAP server and cache locally == 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 change: 1. Generate a 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 GET for xcap-directory and locate previously uploaded icons 1. HTTP DELETE any previous icon files On reboot: 1. HTTP GET for xcap-directory and locate previously uploaded icon (e.g. XYZ) 1. HTTP GET http://xcap.example.com/xcap-root/icon/users/sip:alice@example.com/XYZ.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 and check periodically