[OpenSIPS-Devel] [ opensips-Bugs-3069214 ] presence expires_offset breaks resiprocate

[SourceForge.net]

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: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3069214&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: Kennard White (kennardwhite)
Assigned to: Nobody/Anonymous (nobody)
Summary: presence expires_offset breaks resiprocate

Initial Comment:
Issue
-----
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).

Solution
--------
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
soon enough.

2. Add new parameter to allow explicit control of the extension. This
is described below. Advantage of this patch is that it is backwards
compatible.

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.


Proposed Patch
--------------
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: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3069214&group_id=232389