[OpenSIPS-Devel] [ opensips-Bugs-2822319 ] presence: "active" -> "pending" is not allowed transition
SourceForge.net
noreply at sourceforge.net
Thu Jul 16 10:21:26 CEST 2009
Bugs item #2822319, was opened at 2009-07-16 10:21
Message generated for change (Tracker Item Submitted) 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".
----------------------------------------------------------------------
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