[OpenSIPS-Devel] [ opensips-Bugs-2822319 ] presence: "active" -> "pending" is not allowed transition
SourceForge.net
noreply at sourceforge.net
Thu Aug 6 17:46:37 CEST 2009
Bugs item #2822319, was opened at 2009-07-16 11:21
Message generated for change (Settings changed) made by anca_vamanu
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: Closed
>Resolution: Fixed
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: Anca Vamanu (anca_vamanu)
Date: 2009-08-06 18:46
Message:
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
----------------------------------------------------------------------
Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-07-25 16:19
Message:
Hi Anca, just curiosity: any new on this issue? :)
----------------------------------------------------------------------
Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-07-20 13: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 12: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 22: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 18: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 12: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 12: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 11: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