SIP SIMPLE Client SDK

= Presence 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 NOTIFYs

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