[OpenSIPS-Devel] [ opensips-Bugs-3069214 ] presence expires_offset breaks resiprocate
noreply at sourceforge.net
Fri Sep 17 19:13:17 CEST 2010
Bugs item #3069214, was opened at 2010-09-17 10:13
Message generated for change (Tracker Item Submitted) made by kennardwhite
You can respond by visiting:
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.
Submitted By: Kennard White (kennardwhite)
Assigned to: Nobody/Anonymous (nobody)
Summary: presence expires_offset breaks resiprocate
We previously used the presence module's "expires_offset" parameter.
Unfortunately, the current behavior of that parameter interact VERY
badly with resiprocate-based clients. Resiprocate caches the value of
Expires header provided within the SUBSCRIBE response, and uses that
value on subsequent reSUBSCRIBEs. Each time this happens, opensips
subtracts the offset value, leading to smaller subscription durations
on each reSUB. Eventually the requested subscription duration hits zero
(or a very small value), and the client can no longer get a subscription.
As a result, it is critical that the expires value returned in the
SUBSCRIBE response not be offset to smaller on each reSUB. (It can be
reduce to the configured maximum value, but that only happens the first
time, not continuously).
There are two patches possible:
1. Change behavior of expires_offset so that the actual subscription
duration is extended by that value, and the reported value is decreased
by that same value. This would implement the "GUARD" mode described below.
Net result is that the Expires value in response is unchanged from request,
but provides protection for clients that don't initiate the rePUB or reSUB
2. Add new parameter to allow explicit control of the extension. This
is described below. Advantage of this patch is that it is backwards
I have idea #2 implemented, and it is described below. I would like
your direction regarding if you would like to have the simpler, but
non-backward compatbile #1, or the backward-compat, but complex #2.
The presence modules supports two parameters that control how the
Expires header of both SUBSCRIBE and PUBLISH are used: expires_offset
and expires_extra_secs. Both parameters are in units of seconds, both
default to 0, and neither allows negative numbers.
The expires_extra_secs parameter controls the offset between actual
expiration duration and requested expiration duration (SUBSCRIBE or
PUBLISH request), while the expires_offset parameter controls the offset
between the actual expiration duration and the reported (via SUBSCRIBE
response, PUBLISH response, and NOTIFY messages) expiration duration:
actual_expires = requested_expires + expires_extra_secs
reported_expires = actual_expires - expires_offset
There are 4 combination of settings:
expires_offset = expires_extra_secs = 0 (DEFAULT)
This should work with any "good" client.
expires_offset = expires_extra_secs > 0 (GUARD)
The actual expiration is increased to give "dumb" clients time to
reSUB or rePUB prior to expiration. The client is not informed
of this increase: it is silent increase. This should be safe
for all clients.
expires_offset=0, expires_extra_secs > 0 (INC-ONLY)
The actual expiration is increased as above, and the client
is informed of this increase via the response and NOTIFY messages.
This is a violation of RFC 3265 sec 3.1.1 which prohbits
increasing the duration.
expires_offset >0, expires_extra_secs = 0 (DEC-ONLY)
The actual expiration isn't modified, but the reported time is.
This setting is DANGEROUS. Some clients (including those
resiprocate-based) cache the reported expires duration and use
it on the next SUB. This parameter will cause the subscription
interval to decrease each time until it gets to zero.
The expires_extra_secs parameter was added in Sep 2010, and was
added in this way for backwards compatibility. The last two modes
should not be used.
You can respond by visiting:
More information about the Devel