SIP SIMPLE Client SDK

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

On boot

 * Locate XCAP server by doing DNS TXT lookup for _xcap._tls.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