Bugs item #2822319, was opened at 2009-07-16 10:21 Message generated for change (Comment added) made by ibc_sf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2822319&group_id=232389
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: trunk Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Iñaki Baz Castillo (ibc_sf) Assigned to: Anca Vamanu (anca_vamanu) Summary: presence: "active" -> "pending" is not allowed transition Initial Comment: imagine alice is subscribed to presence on bob. bob allows it (via XCAP) so alice sees his status ("open" in this case). alice displays a happy icon meaning "online" in the buddy list so alice (the human) knows that bob is online. Now bob uses XCAP to block alice. This could be by addid alice in a "block" action or by removing her from the "allow" rules. So the OpenSIPS presence agent sends a NOTIFY to alice containing: Subscription-State: pending;expires=2107 Does it make sense to receive a NOTIFY with "Subscription-State: pending" if previously the watcher received (in the same subscription dialog) a NOTIFY with "Subscription-State: active"? Is it a valid transition from "active" to "pending"? The fact is that I've tested varios common softphones and they don't react on the above case (and remain showing bob as "online"). I've checked RFC 3265 and it's not clear if "active"->"pending" makes sense, however RFC 3857 makes it clear: http://tools.ietf.org/html/rfc3857#section-4.7.1 subscribe, policy= +----------+ reject | |<------------------------+ +------------>|terminated|<---------+ | | | | | | | | | |noresource | | +----------+ |rejected | | ^noresource |deactivated | | |rejected |probation | | |deactivated |timeout |noresource | |probation | |rejected | |giveup | |giveup | | | |approved +-------+ +-------+ +-------+ | | |subscribe| |approved| | | | init |-------->|pending|------->|active | | | |no policy| | | | | | | | | | | | +-------+ +-------+ +-------+ | | | ^ | | subscribe, | | | +-----------------------------------+ | policy = accept | +-------+ | | | | | | |waiting|----------+ +----------->| | timeout | | +-------+ Figure 1: Subscription State Machine This is, "active"->"pending" is not allowed. It must transition to "terminated" state with some appropiate reason parameter. IMHO it should be "terminated;status=deactivated": http://tools.ietf.org/html/rfc3265#section-3.2.4 deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. The "retry-after" parameter has no semantics for "deactivated". ---------------------------------------------------------------------- >Comment By: Iñaki Baz Castillo (ibc_sf) Date: 2009-07-20 12:11 Message: > However, the Subscription will remain in this > status=terminated;reason=deactivated until the OpenSIPS PA will receive and > MI command announcing it that the document has changed and then it will > reanalyze the statuses. Do you see a problem in this behavior? Hum, wouldn't be just easier if PA sends the NOTIFY "terminated;reason=deactivated" and deletes the subscription? When the client receives such a NOTIFY it will try to retry the subscription again and then OpenSIPS PA should create a new subscription in state "pending". But if the new SUBSCRIBE from the client receives again "terminated;reason=deactivated" it would retry again and again. IMHO "terminated;reason=deactivated" only makes sense when the subscription was previously active. ---------------------------------------------------------------------- Comment By: Anca Vamanu (anca_vamanu) Date: 2009-07-20 11:52 Message: Hi Inaki, Sorry I did not pay attention when I wrote the post. I really wanted to write there about the transition from active to "terminated;reason=deactivated". I make the commit on Friday so you can update and test. However, the Subscription will remain in this status=terminated;reason=deactivated until the OpenSIPS PA will receive an MI command announcing it that the document has changed and then it will reanalyze the statuses. Do you see a problem in this behavior? regards, Anca ---------------------------------------------------------------------- Comment By: Iñaki Baz Castillo (ibc_sf) Date: 2009-07-17 21:42 Message: Hi Anca, you talk about a transition from "pending" to "terminated;reason=deactivated", but what I mean is that if OpenSIPS PA receives a MI notification from the XCAP server and a watcher which was previously allowed is not no (now is blocked or doesn't appear as allowed), then PA should generate a NOTIFY with "Subscription-State: terminated;reason=deactivated" for that watcher. This would force the watcher to subscribe again so it would receive the "pending" state. But what you suggest ("pending" -> new pres-rules update not allowing it -> "terminated;deactivated") could also be good. ---------------------------------------------------------------------- Comment By: Anca Vamanu (anca_vamanu) Date: 2009-07-17 17:31 Message: Hi Inaki, I think you are right. If the user was previously in pending state and no rule if found no more the the privacy rules document, then I will move the subscription into terminated state with reason deactivated. I will make the fix and let you know when to update and test again. Thanks and regards, Anca ---------------------------------------------------------------------- Comment By: Iñaki Baz Castillo (ibc_sf) Date: 2009-07-16 11:47 Message: Forget this text from my previous comment: > However, if alice wan't previously alloweb by bob and subscribes to him, > which should be the response from PA? "terminated;reason=rejected" would > terminate the subscription and alice wouldn't retry it :( If alice is *blocked* by bob, she should receive "terminated;status=rejected". If alice was not blocked, neither allowed, she should receive "pending". ---------------------------------------------------------------------- Comment By: Iñaki Baz Castillo (ibc_sf) Date: 2009-07-16 11:38 Message: Update: The PA behaviour is different depending on the case. Let's suppose alice was "allowed" by bob. Two casees: 1) Bob puts a new pres-rules in which alice appears as blocked. Then OpenSIPS PA sends a NOTIFY "terminated;status:rejected" to alice. 2) Bob puts a new pres-rules in which alice doesn't appear. Then PA sends a NOTIFY "pending" to alice. Case 1 produces that alice won't subscribe again to bob according to "rejected" meaning: ---------------------------- rejected: The subscription has been terminated due to change in authorization policy. Clients SHOULD NOT attempt to re-subscribe. The "retry-after" parameter has no semantics for "rejected". --------------------------- This isn't very nice since if later bob allows alice, alice won't receive the notification (she is not subscribed now). Perhaps it would be better to send "terminated;reason=deactivated" in this case? In the case 2, transition from "active" to "pending" is not allowed by RFC 3857 so the watcher doesn't react. In both cases (alice was *previously* alloweb by bob) I suggest to send "terminated;reason=deactivated" so future authorization changes in bob pres-rules would be received by alice. However, if alice wan't previously alloweb by bob and subscribes to him, which should be the response from PA? "terminated;reason=rejected" would terminate the subscription and alice wouldn't retry it :( Perhaps "terminated;reason=deactivated" is the best choice for all the cases? I am 100% sure that MSN, Yahoo, Skype or GTalk watchers are always subscribed to the presence of buddies so they receive status notifications when they are approved. ---------------------------------------------------------------------- Comment By: Iñaki Baz Castillo (ibc_sf) Date: 2009-07-16 10:56 Message: So what I propose is the following: If OpenSIPS PA receives a MI notification from the XCAP server and a watcher which was previously allowed is not now, then PA should generate a NOTIFY with "Subscription-State: terminated;reason=deactivated" for that watcher. This would force the watcher to re-subscribe and now it would receive "pending" state so it would update the icon status (from "online" to uknown or pending). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2822319&group_id=232389 _______________________________________________ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel