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

SourceForge.net noreply at sourceforge.net
Fri Jul 17 21:42:58 CEST 2009


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



More information about the Devel mailing list