SIP SIMPLE Client SDK

= Presence design =

<abbr title="Design*, depth=1">TOC</abbr>

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