SIP SIMPLE Client SDK

= Presence blueprint =

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

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
• Buddy list (Contacts)
• 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

• If '''account.presence.xcap_root''' is not defined, locate XCAP root by doing a DNS TXT lookup for xcap.example.com, deal with DNS timeout
• GET XCAP application xcap-caps
• GET the default filename for the applications supported in xcap-caps and cache them locally * 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
• Initialize the '''buddy list'''
• Initialize own '''presentity'''
• 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'''

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
• Update '''presentity''' based on GUI actions or automatic sensors and cache it

Long term state

• Update '''pidf-manipulation document''' and '''presentity'''

Buddy list

Contains a list of buddies we SUBSCRIBE to for '''Event: presence'''. The buddy list is indexed by a unique SIP URI, a random SIP URI must be generated for contacts that do not have a SIP URI and e must musk buddies we want to subscribe to by setting a particular flag for each of them. Additional, one can store full names and other attributes for each buddy by using extensions to pidf for contact information. Based on NOTIFY for Event=presence each buddy has a '''presentity''' attribute that contains its published information. The GUI displays various attributes of each '''presentity'''.

• The buddy list displayed as Contacts 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'''

A buddy has properties related to his device capabilities (e.g. can_chat, can_share, can_talk, can_video). This is conveyed via '''presence caps'''

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.winfo''' we update the policy and PUT '''dialog-rules''' document on the XCAP server. To be built in OpenXCAP server.

Icon exhange

There is how OMA has specified such XCAP application:

'"Presence Content XDM Specification'"

http://www.openmobilealliance.org/technical/release_program/docs/PresenceSIMPLE/V2_0-20081223-C/OMA-TS-Presence_SIMPLE_Content_XDM-V1_0-20081223-C.pdf

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)
 1. HTTP GET http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/ABC

Publishing end-point, on change:

1. Generate a new random filename: XYZ
 1. Build URL http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/XYZ
 1. HTTP PUT to xcap server
 1. Update <icon> element of pidf and PUBLISH new pidf
 1. HTTP DELETE any previous icon file ABC

Subscribing end-point:

1. Parse <icon> element of pidf received in Notify
 2. HTTP GET http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/XYZ
 3. Cache picture until next NOTIFY with diferent <icon> element is received