DesignBuddyList » History » Revision 22
Revision 21 (Adrian Georgescu, 07/13/2009 06:01 PM) → Revision 22/115 (Adrian Georgescu, 07/13/2009 06:04 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.
* 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