DesignBuddyList
Version 106 (Adrian Georgescu, 08/20/2010 12:46 pm)
1 | 106 | Adrian Georgescu | = Presence Requirements = |
---|---|---|---|
2 | 2 | Adrian Georgescu | |
3 | 55 | Adrian Georgescu | [[TOC(DesignBuddyList, depth=2)]] |
4 | 1 | Adrian Georgescu | |
5 | 88 | Adrian Georgescu | This is a high level design for implementing the SIP SIMPLE standards related to ''presence'' and ''presence.winfo'' event packages into the ''SIP SIMPLE client'' that achieves the following goals: |
6 | 1 | Adrian Georgescu | |
7 | 94 | Adrian Georgescu | 1. Manages a ''Contacts List'' |
8 | 94 | Adrian Georgescu | 1. Controls the presence information published by a ''SIP account'', handles the Subscriptions and Notifications for the ''Contacts'' |
9 | 94 | Adrian Georgescu | 1. Manages an ''Icon'' (a small size picture of the end user using the client) |
10 | 100 | Adrian Georgescu | 1. Managed the ''Policy'' that described who has access to what part of the published PIDF |
11 | 1 | Adrian Georgescu | |
12 | 86 | Adrian Georgescu | The design requires a ''Presence Agent'' and an ''XCAP server'' serving the domain of the SIP account for which this functionality is desired. |
13 | 86 | Adrian Georgescu | |
14 | 1 | Adrian Georgescu | == Contacts List == |
15 | 1 | Adrian Georgescu | |
16 | 86 | Adrian Georgescu | ''Contacts List'' contains is a list of discrete contacts displayed by the GUI. It must be managed by the SIP client at a global level above the individual SIP account level. |
17 | 59 | Adrian Georgescu | |
18 | 86 | Adrian Georgescu | The ''Contacts List'' is organized into ''Groups''. The ''SIP client'' maintains this central ''Groups List'' by merging all found groups on local and remote storage(s) and populates each group with all contacts found for them. |
19 | 70 | Adrian Georgescu | |
20 | 86 | Adrian Georgescu | Some contacts are marked to Subscribe to them for ''Event: presence''. Based on received Notify messages for ''Event: presence'', each Contact has a ''presentity'' attribute that contains its own published information as pidf xml payload, the GUI can display attributes of it. |
21 | 1 | Adrian Georgescu | |
22 | 78 | Adrian Georgescu | The following presence related payloads as used to generate the presentity payload used for publish: |
23 | 78 | Adrian Georgescu | |
24 | 78 | Adrian Georgescu | * Presence Data Model RFC4479 |
25 | 78 | Adrian Georgescu | * Rich Presence Extensions RFC4480 |
26 | 78 | Adrian Georgescu | * Contact Information for the Presence Information Data Format RFC4482 |
27 | 78 | Adrian Georgescu | * User Agent Capability Extension to Presence Information Data Format RFC5196 |
28 | 78 | Adrian Georgescu | |
29 | 78 | Adrian Georgescu | > Same Contact may end up belonging to different Groups if the same SIP address is stored on multiple XCAP servers in different groups. |
30 | 1 | Adrian Georgescu | |
31 | 79 | Adrian Georgescu | The ''SIP client'' builds the ''Contacts List'' by concatenating the individual lists stored locally or on the ''resource-lists'' documents stored on the XCAP server corespondent to each SIP account. |
32 | 1 | Adrian Georgescu | |
33 | 79 | Adrian Georgescu | When a Contact is added/modified/deleted the corespondent remote XCAP storage documents are also updated. The remote storage is set per Contact in the Add/Edit Contact dialog of the SIP client. This remote server storage is used for initializing the locally cached Contacts List between restarts and to synchronize changes between multiple SIP UAs configured for the same SIP account. |
34 | 79 | Adrian Georgescu | |
35 | 1 | Adrian Georgescu | [[Image(BuddyList-Aggregation.png)]] |
36 | 1 | Adrian Georgescu | |
37 | 78 | Adrian Georgescu | == Account == |
38 | 1 | Adrian Georgescu | |
39 | 79 | Adrian Georgescu | Each SIP Account has settings in the middleware that affect the way it interacts with its correspondent Contacts |
40 | 78 | Adrian Georgescu | |
41 | 79 | Adrian Georgescu | * Subscribes to information related to who has subscribed to its own presence information and generate a policy document that is used for subsequent subscriptions and notifications by the Presence Agent |
42 | 79 | Adrian Georgescu | * Stores its data into the XCAP server corespondent with the SIP account or locally if no XCAP server is available |
43 | 1 | Adrian Georgescu | |
44 | 98 | Adrian Georgescu | [[Image(contact-details.jpg)]] |
45 | 98 | Adrian Georgescu | |
46 | 87 | Adrian Georgescu | === Storage === |
47 | 78 | Adrian Georgescu | |
48 | 1 | Adrian Georgescu | If ''account.xcap'' is enabled |
49 | 1 | Adrian Georgescu | |
50 | 60 | Adrian Georgescu | * If ''account.xcap.xcap_root'' is not set, locate XCAP root by doing a DNS TXT lookup for xcap.example.com |
51 | 1 | Adrian Georgescu | * GET XCAP application xcap-caps |
52 | 1 | Adrian Georgescu | * GET XCAP application xcap-directory |
53 | 1 | Adrian Georgescu | * For all supported applications returned by above step, GET their files and cache them locally |
54 | 78 | Adrian Georgescu | |
55 | 57 | Adrian Georgescu | If ''Icon'' application is enabled |
56 | 78 | Adrian Georgescu | |
57 | 78 | Adrian Georgescu | * GET the previous icon using HTTP request |
58 | 87 | Adrian Georgescu | * Refresh the location of the XCAP server based on DNS TTL |
59 | 78 | Adrian Georgescu | |
60 | 87 | Adrian Georgescu | === Publish === |
61 | 78 | Adrian Georgescu | |
62 | 105 | Adrian Georgescu | If ''account.presence.enabled'' is True |
63 | 78 | Adrian Georgescu | |
64 | 1 | Adrian Georgescu | * Send Publish with the current pidf if pidf_manipulation is not set, let the user change his state manually if pidf_manipulation is set |
65 | 78 | Adrian Georgescu | |
66 | 105 | Adrian Georgescu | If ''account.xcap'' is enabled and ''account.presence.enabled'' is True |
67 | 1 | Adrian Georgescu | |
68 | 54 | Adrian Georgescu | * Initialize the ''Contacts List'' by using the content of the XCAP document ''resource-lists'', filename ''index''. Initialize the ''Subscriptions List'' using the Contacts marked for ''Subscribe to Presence'' |
69 | 1 | Adrian Georgescu | |
70 | 105 | Adrian Georgescu | If ''account.xcap'' is enabled and ''account.presence.use_rls_services'' is enabled |
71 | 1 | Adrian Georgescu | |
72 | 1 | Adrian Georgescu | * Put the content of ''Subscription List'' initialized above to the XCAP document ''rls-services'' identified by SIP URI account-buddies@domain. |
73 | 54 | Adrian Georgescu | |
74 | 102 | Adrian Georgescu | === PIDF manipulation === |
75 | 1 | Adrian Georgescu | |
76 | 104 | Adrian Georgescu | 1. Add menu item with ''Offline status'' that brings up dialog window with Presence Activity and Note to be displayed while offline. |
77 | 103 | Adrian Georgescu | 1. Add a reminder icon on main interface so that we know we have set this offline status |
78 | 1 | Adrian Georgescu | |
79 | 102 | Adrian Georgescu | === Subscribe === |
80 | 1 | Adrian Georgescu | |
81 | 104 | Adrian Georgescu | If ''account.xcap'' is enabled and ''account.xcap.use_xcap_diff'' is enabled |
82 | 87 | Adrian Georgescu | |
83 | 78 | Adrian Georgescu | * Sent Subscribe for ''Event: xcap-diff'' to the account own SIP address |
84 | 90 | Adrian Georgescu | |
85 | 104 | Adrian Georgescu | If ''account.presence.enabled'' is True |
86 | 1 | Adrian Georgescu | |
87 | 104 | Adrian Georgescu | * Send Subscribe for ''presence.winfo'' to the account own SIP address |
88 | 87 | Adrian Georgescu | |
89 | 104 | Adrian Georgescu | If ''account.presence.use_rls_services'' is True |
90 | 90 | Adrian Georgescu | |
91 | 104 | Adrian Georgescu | * Send one Subscribe for ''Event: presence'', and header ''Supported: eventlist'' to sip:account-buddies@domain |
92 | 104 | Adrian Georgescu | |
93 | 104 | Adrian Georgescu | else |
94 | 104 | Adrian Georgescu | |
95 | 104 | Adrian Georgescu | * For each contact in the ''Subscriptions List'' send individual Subscribe for ''Event: presence'' |
96 | 87 | Adrian Georgescu | |
97 | 78 | Adrian Georgescu | === Notify === |
98 | 78 | Adrian Georgescu | |
99 | 78 | Adrian Georgescu | * On Notify for ''Event: xcap-diff'' that a supported XCAP document has been changed by other SIP UA GET the new document |
100 | 78 | Adrian Georgescu | * On Notify for ''Event: presence'' update the presentity of affected Contacts |
101 | 87 | Adrian Georgescu | * On Notify for ''Event: presence.winfo'' trigger notifications end user to update its policy |
102 | 1 | Adrian Georgescu | |
103 | 59 | Adrian Georgescu | > Each individual contact list stored in a resource-lists document is indexed by a unique SIP URI, a random SIP URI must be generated for Contacts that do not have a real SIP URI and we must mark the contacts that we want to Subscribe to for presence information. Additional, one can store full names and other attributes related to remote recipient by using extensions to PIDF for contact information (cipid extension). |
104 | 54 | Adrian Georgescu | |
105 | 91 | Adrian Georgescu | === Policy change === |
106 | 62 | Adrian Georgescu | |
107 | 87 | Adrian Georgescu | * Based on Notify for ''Event: presence.winfo'' alert the user about new watchers |
108 | 87 | Adrian Georgescu | * If ''account.xcap'' is enabled PUT ''pres-rules'' document on the XCAP server |
109 | 32 | Adrian Georgescu | |
110 | 1 | Adrian Georgescu | Transformations are required to support the following functionality: |
111 | 56 | Adrian Georgescu | |
112 | 1 | Adrian Georgescu | 1. First degree watchers - access to entire PIDF |
113 | 1 | Adrian Georgescu | 1. Second degree watchers - access to subset of PIDF |
114 | 59 | Adrian Georgescu | 1. Third degree watchers - access to basic presence online/offline |
115 | 32 | Adrian Georgescu | |
116 | 96 | Adrian Georgescu | === Notifications === |
117 | 96 | Adrian Georgescu | |
118 | 96 | Adrian Georgescu | The SIP client must be notified by the middleware when a network event related to Presence occurs: |
119 | 96 | Adrian Georgescu | |
120 | 96 | Adrian Georgescu | 1. ''Watcher list'' has changed |
121 | 96 | Adrian Georgescu | 1. Account has activated/deactivated to update the ''Contacts List'' |
122 | 96 | Adrian Georgescu | 1. Presence information of a Contact has changed |
123 | 96 | Adrian Georgescu | 1. A conflict exists between the server version and the local version of an XCAP document |
124 | 96 | Adrian Georgescu | |
125 | 96 | Adrian Georgescu | Each ''Contact'' can publish properties related to his device capabilities (e.g. chat, audio, video). This is conveyed via ''caps'' extension to ''pidf'' and can be used to drive the contextual menu presented for each Contact related to what kind of action can be initiated to it. |
126 | 96 | Adrian Georgescu | |
127 | 96 | Adrian Georgescu | === Actions === |
128 | 96 | Adrian Georgescu | |
129 | 96 | Adrian Georgescu | 1. Display and manages the ''Contacts List'' |
130 | 96 | Adrian Georgescu | 1. Display attributes of the Presence information of each Contact |
131 | 96 | Adrian Georgescu | 1. Manage the content of the ''Policy'' document |
132 | 96 | Adrian Georgescu | 1. Update the ''Icon'' of the SIP account |
133 | 96 | Adrian Georgescu | |
134 | 92 | Adrian Georgescu | == Icon == |
135 | 84 | Adrian Georgescu | |
136 | 92 | Adrian Georgescu | Publishing end-point: |
137 | 1 | Adrian Georgescu | |
138 | 91 | Adrian Georgescu | 1. Generate a new random filename: XYZ |
139 | 91 | Adrian Georgescu | 1. Build URL http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/XYZ |
140 | 84 | Adrian Georgescu | 1. PUT the new icon document to XCAP server |
141 | 84 | Adrian Georgescu | 1. Update <icon> element of pidf and PUBLISH new pidf |
142 | 1 | Adrian Georgescu | 1. DELETE any previously uploaded icon file |
143 | 84 | Adrian Georgescu | |
144 | 84 | Adrian Georgescu | Subscribing end-point: |
145 | 92 | Adrian Georgescu | |
146 | 84 | Adrian Georgescu | 1. Parse <icon> element of pidf cipid extension received in Notify |
147 | 84 | Adrian Georgescu | 2. HTTP GET http://xcap.example.com/xcap-root/org.openmobilealliance.pres-content/users/sip:alice@example.com/oma_status-icon/XYZ |
148 | 91 | Adrian Georgescu | 3. Cache picture until next Notify with diferent <icon> element is received |
149 | 84 | Adrian Georgescu | |
150 | 84 | Adrian Georgescu | The icon is common across all accounts, it must be put on all XCAP servers for all active accounts. |
151 | 99 | Adrian Georgescu | |
152 | 99 | Adrian Georgescu | |
153 | 99 | Adrian Georgescu | == Policy == |
154 | 99 | Adrian Georgescu | |
155 | 101 | Adrian Georgescu | All PIDF attributes that can be published must register themselves with the Policy manager. This Policy Manager renders these PIDF attributes in a Window where the user can associate the attributes with Contacts that subscribe to his presentity. |
156 | 101 | Adrian Georgescu | |
157 | 101 | Adrian Georgescu | |
158 | 1 | Adrian Georgescu | [[Image(PresencePolicy.png)]] |
159 | 106 | Adrian Georgescu | |
160 | 106 | Adrian Georgescu | = Presence Design = |
161 | 106 | Adrian Georgescu | |
162 | 106 | Adrian Georgescu | 1. Contact management |
163 | 106 | Adrian Georgescu | 1. local vs xcap (resourcelist) storage |
164 | 106 | Adrian Georgescu | 1. Incoming presence |
165 | 106 | Adrian Georgescu | 1. Subscribe to presence |
166 | 106 | Adrian Georgescu | 1. Subscribe to dialog-event |
167 | 106 | Adrian Georgescu | 1. RLS Services document management |
168 | 106 | Adrian Georgescu | 1. Outgoing presence |
169 | 106 | Adrian Georgescu | 1. Publish presence, dialog-event |
170 | 106 | Adrian Georgescu | 1. PIDF-manipulation |
171 | 106 | Adrian Georgescu | 1. Subscribe .winfo |
172 | 106 | Adrian Georgescu | 1. Pres-rules, dialog-rules |
173 | 106 | Adrian Georgescu | 1. Icon |
174 | 106 | Adrian Georgescu | |
175 | 106 | Adrian Georgescu | == Published items == |
176 | 106 | Adrian Georgescu | |
177 | 106 | Adrian Georgescu | 1. presence activity |
178 | 106 | Adrian Georgescu | 1. presence note |
179 | 106 | Adrian Georgescu | 1. icon |
180 | 106 | Adrian Georgescu | 1. location URL |
181 | 106 | Adrian Georgescu | 1. display name |
182 | 106 | Adrian Georgescu | 1. idle status (keyboard idle) |
183 | 106 | Adrian Georgescu | 1. privacy information |
184 | 106 | Adrian Georgescu | 1. time offset from UTC |
185 | 106 | Adrian Georgescu | 1. device capabilities |
186 | 106 | Adrian Georgescu | |
187 | 106 | Adrian Georgescu | == Design notes == |
188 | 106 | Adrian Georgescu | |
189 | 106 | Adrian Georgescu | * XCAPManager (needs to be highly robust!) |
190 | 106 | Adrian Georgescu | * offers high-level API for accessing different types of resources (resource-lists, rls-services, pres-rules, dialog-rules, pidf) |
191 | 106 | Adrian Georgescu | * keeps cached copies of XCAP-stored files in case there is lack of connectivity |
192 | 106 | Adrian Georgescu | * keeps journal with high-level described changes made to files (in case of lack of connectivity, these will be retried later) |
193 | 106 | Adrian Georgescu | * Example: Add contact luci@umts.ro to list Friends in resource-list file of account luci@ag-projects.com |
194 | 106 | Adrian Georgescu | * Resolve possible conflicts when pushing/pulling changes (maybe based on timestamps?) |
195 | 106 | Adrian Georgescu | * subscribes to xcap-diff so it can be informed of changes to xcap files |
196 | 106 | Adrian Georgescu | * estimated time of development: 2-3 weeks |
197 | 106 | Adrian Georgescu | * Contact list in middleware |
198 | 106 | Adrian Georgescu | * communicates with XCAPManager (uses resource-lists) |
199 | 106 | Adrian Georgescu | * estimated time of development: 3 days |
200 | 106 | Adrian Georgescu | * Contact list in application |
201 | 106 | Adrian Georgescu | * uses middleware API to aggregate internally stored contact list with the contact lists of all accounts |
202 | 106 | Adrian Georgescu | * how should the contacts be stored if the user has more than one SIP account? |
203 | 106 | Adrian Georgescu | * estimated time of development: blink-qt 4 days, blink-cocoa ? |
204 | 106 | Adrian Georgescu | * Incoming presence in middleware |
205 | 106 | Adrian Georgescu | * integrate with contact list: contacts should have attributes with various information that can be retrieved by subscribing to presence and dialog events (tree structure most likely, rather than having all attributes at the same level) |
206 | 106 | Adrian Georgescu | * should try to use RLS (via XCAPManager) |
207 | 106 | Adrian Georgescu | * probably quite coupled with contact list management |
208 | 106 | Adrian Georgescu | * solve conflicts and aggregate information from multiple publishing agents |
209 | 106 | Adrian Georgescu | * estimated time of development: 1-2 weeks |
210 | 106 | Adrian Georgescu | * Incoming presence in application |
211 | 106 | Adrian Georgescu | * think how to display the various information obtained from the contact objects |
212 | 106 | Adrian Georgescu | * estimated time of development: blink-qt 1 week, blink-cocoa ? |
213 | 106 | Adrian Georgescu | * Outgoing presence in middleware |
214 | 106 | Adrian Georgescu | * information published via presence and dialog events |
215 | 106 | Adrian Georgescu | * accounts should have attributes which can store information to be published (probably similar to contacts) |
216 | 106 | Adrian Georgescu | * accounts should publish this information automatically if configured to |
217 | 106 | Adrian Georgescu | * manage persistent presence information via xcap pidf-manipulation |
218 | 106 | Adrian Georgescu | * publish icon via xcap |
219 | 106 | Adrian Georgescu | * subscribe to .winfo of presence and dialog events and manage information about active, pending and blocked subscriptions (integrate with contact list) |
220 | 106 | Adrian Georgescu | * offer API for fine-grained control of published info (pres-rules and dialog-rules) |
221 | 106 | Adrian Georgescu | * be able to understand any valid policy because it can be changed by another client and notify the application when the policy is changed |
222 | 106 | Adrian Georgescu | * estimated time of development: 2 weeks |
223 | 106 | Adrian Georgescu | * Outgoing presence in application |
224 | 106 | Adrian Georgescu | * push presence information to middleware for publishing |
225 | 106 | Adrian Georgescu | * notify user of new subscription requests |
226 | 106 | Adrian Georgescu | * manage policy in an intuitive interface |
227 | 106 | Adrian Georgescu | * estimated time of development: blink-qt 2 weeks, blink-cocoa ? |