#160 presence: "active" -> "pending" is not allowed transition

trunk
closed-fixed
modules (454)
5
2009-08-06
2009-07-16
No

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".

Discussion

  • Iñaki Baz Castillo

    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).

     
  • Iñaki Baz Castillo

    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.

     
  • Iñaki Baz Castillo

    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".

     
  • Anca Vamanu

    Anca Vamanu - 2009-07-17
    • assigned_to: nobody --> anca_vamanu
    • status: open --> open-accepted
     
  • Anca Vamanu

    Anca Vamanu - 2009-07-17

    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

     
  • Iñaki Baz Castillo

    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.

     
  • Anca Vamanu

    Anca Vamanu - 2009-07-20

    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

     
  • Iñaki Baz Castillo

    > 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.

     
  • Iñaki Baz Castillo

    Hi Anca, just curiosity: any new on this issue? :)

     
  • Anca Vamanu

    Anca Vamanu - 2009-08-06

    Hi Inaki,

    I have followed this suggestion also and deleted the record in watchers table when the status switches to terminated, deactivated.
    I will close this bug report.

    Thanks and regards,
    Anca

     
  • Anca Vamanu

    Anca Vamanu - 2009-08-06
    • status: open-accepted --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks