History

« Previous - Version 16/115 (diff) - Next » - Current version
Adrian Georgescu, 07/13/2009 05:43 pm

= Buddy list =

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

  • Account
  • Address-book
  • Buddy list
  • Presence watcher list
  • Presence rules
  • Dialog watcher list
  • Dialog rules
  • Icon exchange
Account * GET XCAP documents xcap-caps, pres-rules, resource-lists, pidf-manipulation, rls-services, dialog-rules, icon, xcap-directory * After boot, build current state based on pidf-manipulation document, if present * Sends Publish for event presence * Maintains a '''Presentity''' attributed that is sent as body to Publish * Sends Subscribe for event presence.info * Sends Subscribe for event presence with Supported=eventlist Address book

Use the OS standard address book

Buddy list

Contains list of buddies. The buddylist is indexed by SIP URIs. Additional one can store full name or 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.
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 and PUT pres-rules document on the XCAP server.

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 &lt;icon&gt; 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 &lt;icon&gt; 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

contact-details.jpg (45.6 kB) Adrian Georgescu, 02/01/2010 12:56 am

BuddyList-Aggregation.png (109.4 kB) Adrian Georgescu, 02/01/2010 01:16 am

PresencePolicy.png (38.8 kB) Adrian Georgescu, 02/12/2010 10:26 am