Hello, This behavior is described in the "Implementation Guidelines for OMA XDM v1.1" ( http://www.openmobilealliance.org/Technical/release_program/docs/CopyrightClick.aspx?pck=XDM_PRS_IMPL&file=V1_0-20080627-C/OMA-WP-XDM_1_1_Implementation_Guidelines-20080627-C.pdf), with some nice graphes in the appendixes. They recommend the use of lists for RLS and Pres-Rules to avoid duplication and ease the grant of services.
Moreover, Mercuro is heavily based on the RCS specifications. In the "RCS Release 3 Technical Realisation" ( http://www.gsmworld.com/documents/Service_Realization_v1.0(1).pdf), you will find that a RCS client should only modify the lists inside the resource-lists document, once all documents have been created (chapter 6.4.3 XML Document Handling). Regards, Laurent Etiemble. 2010/4/21 Adrian Georgescu <[email protected]> > > On Apr 21, 2010, at 12:47 PM, Laurent Etiemble wrote: > > Hello, > > Mercuro does not modify the presence rules when it accepts a subscription, > because it deals with lists instead of individual entries: > 1) A subscription request is received by Mercuro and presented to the user > 2) The user accepts the subscription. Mercuro put the contact inside the > allowed list. > > > 3) The presence server detects that a list linked to a presence rule has > been changed. It sends any needed notification. > > > It could be done. > > However this requires processing in the server (potentially both Presence > Agent and XCAP) based on some heuristics criteria unless there is something > standardized about this behaviour. Different clients may also do different > things. > > Is there any normative reference for this that you know of? > > Adrian > > > > The point is that if you have presence rules that apply to lists (in > pres-rules), any modification of these lists (in resource-lists) must > trigger a computation of the presence rules, to check if notifications are > needed. > > Regards, Laurent Etiemble. > > Need an IMS Client ? > Try out Mercuro IMS Client. > More info at http://www.mercuro.net/ > > 2010/4/21 Adrian Georgescu <[email protected]> > >> If pres-rules document does not change, no call to refreshWatchers() >> will occur. >> >> The client must update his presence rules when accepting a subscription. >> >> Adrian >> >> On Apr 21, 2010, at 12:04 PM, calment wrote: >> >> > >> > >> > calment wrote: >> >> >> >> I'm not a python expert but I have some time to spend on this issue >> >> so I >> >> just plunge to the code to seek the problem. Let me know if you found >> >> something. >> >> >> > >> > Ok, I've checked the OpenXcap code. In backend/opensips.py I can see >> > that a >> > refreshWatcherMessage is sent if application_id is either "pres- >> > rules" or >> > "org.openmobilealliance.pres-rules" or "pidf-manipulation". >> > Indeed, when Mercuro Client log for the first time, it HTTP PUT a >> > org.openmobilealliance.pres-rules message (along with 2 resource- >> > lists and 1 >> > rls-services) which make openXcap send a refreshWatcher message. >> > >> > The problem is that, when Mercuro accept to be viewed by a another >> > contact >> > (after a SIP NOTIFY presence.winfo), it does not send an >> > org.openmobilealliance.pres-rules again. It justs add the contact in >> > its >> > buddylist by sending 2 "resource-lists" (index and >> > properties-resource-list.xml) and obviously it doesn't make OpenXcpa >> > to send >> > a refreshWatchers message. >> > >> > Actualy I really wonder if the problem comes from the Mercuro Bronze >> > 4.0.1624.0 client. But due to my misknowledge of xcap, I'm unable to >> > determine. >> > >> > Could somebody point me a simple explanation of this technology ? >> > >> > Regards, >> > >> > >> > -- >> > View this message in context: >> http://n2.nabble.com/Question-Regarding-Watchers-table-tp3856740p4936064.html >> > Sent from the OpenSIPS - Users mailing list archive at Nabble.com. >> > >> > _______________________________________________ >> > Users mailing list >> > [email protected] >> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
