Jeroen van Bemmel wrote:
> 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):
You can't order notify and 2xx relative to each other based on CSeq,
because the CSeq values are assigned by different ends.
Ordering notifies based on CSeq happens in a degenerate way, in that if
they get out of order, the one with the higher value gets processed and
the one with a lower value that arrives after gets rejected.
> - 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.
My head is too fuzzy to study it in detail right now. But my first
reaction is that it isn't going to work in all cases. One thing it
definitely doesn't do is work around a non-conforming notifier. It also
doesn't specify what the algorithm for the notifier should be.
Paul
> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
