DesignBuddyList » History » Revision 14
« Previous |
Revision 14/115
(diff)
| Next »
Adrian Georgescu, 07/13/2009 05:40 PM
= Buddy list =
<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.
- Account
- Address-book
- Buddy list
- Presence watcher list
- Dialog watcher list
- Presence rules
- Dialog rules
Image(sipsimple-buddy-list-design.png,width=600)
Account * GET XCAP documents xcap-caps, pres-rules, resource-lists, pidf-manipulation, rls-services, icon, xcap-directory * 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 bookUse the OS standard address book
Buddy listContains 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.
Built based on the body of NOTIFY for event=presence.winfo.
Dialog watcher listsBuilt based on the body of NOTIFY for event=dialog.winfo. Need to be built in OpenSIPS.
Presence rulesBased on NOTIFY for event watcher.info we update the policy and PUT pres-rules document on the XCAP server.
Dialog rulesBased on NOTIFY for event dialog.info we update the policy and PUT dialog-rules document on the XCAP server.
Icon exhange flowSupport 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
Updated by Adrian Georgescu over 15 years ago · 14 revisions