Project

General

Profile

DesignBuddyList » History » Revision 25

Revision 24 (Adrian Georgescu, 07/13/2009 06:08 PM) → Revision 25/115 (Adrian Georgescu, 07/13/2009 07:02 PM)

= Presence design 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 the a 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 xcap.example.com 
  * GET XCAP application xcap-caps  
  * Dependent on the content of documents 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 Cache documents 
  * Send Subscribe for event presence.info 
  * If '''icon''' application is supported by XCAP server, GET Send Subscribe for event dialog.info 
  * Send Subscribe for event message-summary 
  * Retrieve curent icon image from the xcap server icon auid 
  * If '''dialog-rules''' application is supported by XCAP server, send Subscribe for event dialog.info 
  * if '''pidf-manipulation''' application is support by XCAP server, initialize '''presentity''' with Build presentity based on pidf-manipulation document, if exists, otherwise initialize '''presentity''' to last cached value present 
  * Send SIP PUBLISH Publish for '''Event: presence''' with '''presentity''' event presence 
  * If '''account.message_summary.enabled''' rls-services present in xcap-caps, enable RLS and send Subscribe for '''Event: message-summary''' event presence with Supported=eventlist 
  * If '''account.presence.subscribe_xcap_diff.enabled''' send Subscribe for '''Event: xcap-diff''' 
  * Load '''buddy list''' account.presence.subscribe_rls_services must be normalized when set to '''auto''' 

 While running 

  * Refresh XCAP server location based on DNS TTL time to live 
  * Refresh Publish for event '''presence''' presence 
  * Refresh subscription to '''presence.winfo''' presence.info 
  * Refresh subscription to '''dialog.winfo''' dialog.info 
  * Refresh subscription to '''xcap-diff''' message-summary 
  * Refresh subscription to '''message-summary''' 
  * Reload XCAP documents based on xcap-diff NOTIFYs 

 On shutdown 

  * Cache last '''presentity''' 
  
 Maintain a '''Presentity''' attribute received in Notify for each buddy 
 
 == Address book == 

 Use the OS standard address book. book 

 == Buddy list == 

 Contains a list of buddies we subscribe to. buddies. The buddylist is indexed by a unique 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 various attributes parts of each presentity. it. 

  * The buddy list is stored in the main '''resource-lists''' 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 is 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 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