There are several additional considerations to add into the equation:
- Expires in SUBSCRIBE 2xx is MUST, while ;expires in NOTIFY is SHOULD
- when forking, 2xx may not arrive (;expires in NOTIFY is intended for this
case)
- RFC3265 says (in different wording): Expires in 2xx SUBSCRIBE must be
equal or larger than expires in corresponding NOTIFY
There is a race condition between 2xx and NOTIFY, but since expires in
NOTIFY - if present - can be smaller, the subscriber must always base its
re-subscription timer on the (last) NOTIFY. If there is an expires value in
NOTIFY, it can safely ignore the Expires value in SUBSCRIBE, since the
latter will always be same or larger.
So IMO the proper behavior is (NOTIFYs and 2xx each processed in CSeq
order):
- upon 2xx: if 'notified' flag set: use Expires and clear flag, else
temporarily store Expires value
- upon NOTIFY: if ';expires' is present, use that and clear tempExpires.
Else use and clear tempExpires value from 2xx, if any, or set flag
'notified' otherwise
See pseudo code below.
The subscriber may send several SUBSCRIBE refreshes without waiting for 2xx
or NOTIFY. This wastes resources but still results in correct timer
settings.
Regards,
Jeroen
bool notified = false
int lastExpires = -1;
process2xx() {
if (notified) {
setTimer( getHeader('Expires') )
notified = false
} else {
lastExpires = getHeader('Expires')
}
}
processNOTIFY() {
if ( hasParameter('expires') ) {
setTimer( getParameter('expires') )
notified = false
} else if ( lastExpires > 0 ) {
setTimer( lastExpires )
lastExpires = -1
notified = false
} else {
notified = true
}
}
The above assumes that the first NOTIFY always has an 'expires' parameter,
else it will fail to refresh all but one subscription in case of forking.
Termination handling not shown
Dale Worley wrote:
> First, a reply, but after that, I've tried to think through these
> issues again:
>
> From: "Michael Procter" <[EMAIL PROTECTED]>
>
> I'm not convinced by this argument. This would imply that only
> certain NOTIFYs can shorten the duration (namely ones immediately
> following SUBSCRIBEs) but not others, which seems odd.
>
> I'm modeling things differently than you are. I expect NOTIFYs to
> always report the *notifier's* idea of when the subscription ends.
>
> When the notifier receives a SUBSCRIBE, it can increase the end-time
> as far as it likes, up to the time allowed by the SUBSCRIBE.
>
> The exception is that the notifier is allowed to reduce the
> subscription time to zero, that is, to terminate the subscription, and
> immediately send a NOTIFY. (As well as a SUBSCRIBE that terminates
> the subscription.)
>
>> From this point of view, NOTIFYs (other than termination NOTIFYs)
> never shorten the duration -- or rather, never report a shortening of
> the duration.
>
> Indeed, I think the crucial question is "Who is the authoritative
> keeper of the subscription duration?" I take it that it is the
> notifier. Others seem to assume that it is the subscriber. I model
> that the subscriber is attempting to remotely manipulate the
> subscription duration, and receives occasional updates as to what the
> subscription duration *is*.
>
> My model does get us out of the quandary of how to resolve multiple
> updates of the subscription -- take the max of the values seen in
> NOTIFYs so far. The only race condition is if a re-SUBSCRIBE is in
> flight at the same time a NOTIFY is received that terminates the
> subscription. But the subscriber then knows that the subscription is
> ended, as the notifier has sent word that it has ended, and a late
> re-SUBSCRIBE can never revive a terminated subscription.
>
> Secondly, in section 3.2.4, the behaviour of the recipient of the
> NOTIFY is defined, which includes:
>
> If the header also contains an "expires" parameter, the subscriber
> SHOULD take it as the authoritative subscription duration and
> adjust accordingly.
>
> There are no qualifiers about which NOTIFYs should be taken as
> authoritative, suggesting that all NOTIFYs are created equal in this
> respect, and should be treated as such by the subscriber.
>
> Finally, there is the difficulty in identifying when the duration
> has actually been shortened, rather than an apparent change due to
> clock drift.
>
> I think that on balance, we can only assume that the phrase
> 'shorten a subscription' means just that - to shorten it. No
> further qualifications seem to be implied or can safely be inferred.
>
> I've read through Michael's and Paul's messages, and I think I need to
> change my position. But that interacts with some issues that are
> obscuring the discussion as well.
>
> First, we need to keep our terminology straight. I think everyone
> agrees that the real keeper of the expiration time of the subscription
> is the notifier. The subscriber proposes new expiration times, and
> attempts to remain aware of what the current expiration time is. This
> point is just linguistic, but I think that in a few places people have
> been getting confused by not keeping these distinctions in mind.
> E.g., a NOTIFY can never "shorten a subscription time", it can only
> report a subscription time that has been shortened, and it can reduce
> the subscriber's idea of the subscription time.
>
> My position has been that the notifier can terminate the subscription
> at any time, and that it can extend the subscription upon processing a
> re-SUBSCRIBE, but cannot otherwise modify the subscription time, in
> particular, it can't shorten it without terminating it. Going back
> and reading 3.2.2, I think that RFC 3265 disagrees from me.
>
> But as people have pointed out, if the notifier can shorten a
> subscription, processing a NOTIFY that is close in time to the
> response to a re-SUBSCRIBE is ambiguous. (Whereas if a notifier
> cannot shorten a subscription, then processing is not ambiguous.)
>
> Hmmm, and there is the further problem of a re-SUBSCRIBE that requests
> less time than the current expiration time.
>
> The underlying problem is that the subscriber is receiving a series of
> notifications of a remote state (the subscription time), and the
> transport is not ordering the notifiactions (viz., the 2xx responses
> to SUBSCRIBEs vs. the NOTIFYs). Such situations always lead to race
> conditions unless the time-evolution of the state is arranged so that
> notifications can be unambiguously composed regardless of the order in
> which they are received.
>
> My proposal is to narrow RFC 3265 so that the composition rule is
> "take the max, but termination dominates all", which requires that the
> expiration time never be reduced. I admit that is not what RFC 3265
> says, but without a rule like that, eliminating the race condition
> cannot be done.
>
> Dale
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
