[OpenSIPS-Devel] [ opensips-Bugs-2822319 ] presence: "active" -> "pending" is not allowed transition

[SourceForge.net]

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: None
Priority: 5
Private: No
Submitted By: Iñaki Baz Castillo (ibc_sf)
Assigned to: Nobody/Anonymous (nobody)
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-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