Sigrid Thijs wrote: > Anca Vamanu wrote: >> Hi, >> >> >> I know it is useless but this is what the RFC says: a successful >> Subscribe must be followed by a Notify with the presence state(none >> in this case). >> > > But in this case, no SUBSCRIBE is sent by the watcher. The presentity > changes his presence (which issues a PUBLISH), and the presence module > sends notifications on all active watcher dialogs. Also those that are > 'polite-block'-ed (who receive always a NOTIFY with the same content). > I'm not saying it's wrong, it's just one thing we noticed. > > kind regards, > > Sigrid > I did not understood correctly. You are right. There should be no Notify in this case. I will take a look.
Thanks, Anca >> regards, >> Anca >> >> >> Sigrid Thijs wrote: >>> Just a remark: one more thing we noticed is that when a presentity >>> has 'polite-block'ed a watcher, the presence module sends a NOTIFY >>> to the watcher each time the presentity changes his presence, >>> although the content of the NOTIFY stays the same (no body). >>> >>> kind regards, >>> >>> Sigrid >>> >>> Sigrid Thijs wrote: >>>> Hi, >>>> >>>> we've installed version 1.3.2 and it works now. >>>> >>>> Thanks, >>>> >>>> Sigrid >>>> >>>> Anca Vamanu wrote: >>>>> Hi, >>>>> >>>>> I have fixed it now. Please update, test and reply if it works. >>>>> >>>>> regards, >>>>> Anca Vamanu >>>>> >>>>> >>>>> Sigrid Thijs wrote: >>>>>> Hi, >>>>>> >>>>>> Sigrid Thijs wrote: >>>>>> >>>>>>> But now we noticed another problem. When the subscription >>>>>>> handling is set to "polite-block", a NOTIFY should be sent >>>>>>> containing a presence document that indicates that the >>>>>>> presentity is unavailable. But the presence module sends a >>>>>>> NOTIFY containing a presence description with the current >>>>>>> presence state of the presentity. So there's no difference >>>>>>> between setting the subscription handling to "allow" and >>>>>>> "polite-block". >>>>>>> >>>>>> did you get any chance to take a look at this issue? >>>>>> >>>>>> kind regards, >>>>>> >>>>>> Sigrid >>>>>> >>>>>>> kind regards, >>>>>>> >>>>>>> Sigrid >>>>>>> >>>>>>>> As a note, unless you are using more that one presence servers, >>>>>>>> the fallback to db mode is not really needed and inefficient. >>>>>>>> >>>>>>>> Thanks and regards, >>>>>>>> Anca Vamanu >>>>>>>> >>>>>>>> Sigrid Thijs wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> we've configured OpenSER 1.3.0 on a FreeBSD server, together >>>>>>>>> with OpenXCAP 0.9.9. >>>>>>>>> When testing presence rules (RFC 5025) with our UA, we noticed >>>>>>>>> the following behavior: >>>>>>>>> >>>>>>>>> - Subscription Handling is set to "block" in the presence rules: >>>>>>>>> When a watcher subscribes for presence, it receives a NOTIFY >>>>>>>>> with the Subscription-State set to >>>>>>>>> "terminated;reason=rejected". This is as expected. >>>>>>>>> When the presentity changes it's presence, the watcher doesn't >>>>>>>>> receive any NOTIFY requests with the presence update (also OK). >>>>>>>>> But, when the presentity changes the subscription handling to >>>>>>>>> "allow" in the presence-rules document, the server sends an >>>>>>>>> in-dialog NOTIFY request on the subscription dialog that was >>>>>>>>> previously terminated. This is not ok. See the attached file >>>>>>>>> presence_rules_01.txt. >>>>>>>>> >>>>>>>>> - Subscription Handling is set to "allow" in the presence rules: >>>>>>>>> When the presentity changes the subscription handling to >>>>>>>>> "block" in the presence-rules document, the server sends a >>>>>>>>> NOTIFY with the Subscription-State set to >>>>>>>>> "terminated;reason=timeout" to the watchers. >>>>>>>>> When the presentity changes his presence, the presence server >>>>>>>>> will still send NOTIFY requests to the watchers. >>>>>>>>> See the attached file presence_rules_02.txt. >>>>>>>>> >>>>>>>>> kind regards, >>>>>>>>> >>>>>>>>> Sigrid >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Users mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>>>>> _______________________________________________ >>>>>>> Users mailing list >>>>>>> [email protected] >>>>>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>>> >> >> _______________________________________________ Users mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/users
