[EMAIL PROTECTED] wrote:
> From: Paul Kyzivat <[EMAIL PROTECTED]>
>
> The trick is to figure out how to arrive at a situation where both sides
> agree on what the expiration time is. I suspect that with the current
> rules one can construct cases where that isn't possible. A weaker
> condition is to just ensure that things work out right when there aren't
> these race conditions, and that worst case the notifier never expires
> sooner than the subscriber.
>
> I think the essential problem is that the goal you state above is not
> achievable in the theoretical sense -- all communication between the
> subscriber and notifier has round-trip delay, and so neither side can
> have up-to-date knowledge of the other side's knowledge. The real
> problem is how to approximate the theoretical goal.
I agree that it is impossible to achieve exactly. A reasonable goal is
have it correct within an epsilon defined by the transmission delay
between the two and ignoring any clock rate differences.
> The notifier has an easier time of it, since it doesn't "want"
> anything. It just responds to SUBSCRIBEs according to the rules. All
> of its state will time out eventually, and most truly defunct
> subscriptions will be detected because the NOTIFYs will get errors
> indicating that the subscriber is definitively unreachable (481, 404,
> or the like, but not 408 or 503).
While the notifier doesn't *want* anything, as part of an overall design
we must have some agreement between what the notifier and subscriber do,
so that they don't do inconsistent things. So we need a predictable
specification for both.
Also, the notifier doesn't want to maintain a subscription if the
subscriber doesn't know or care about it.
> The subscriber needs to refresh its subscriptions "in time". As you
> note, both the SUBSCRIBE response and NOTIFYs give an expiration time.
> I think that the subscriber can safely take the most-in-the-future
> expiration time it has seen so far as being the "real" expiration
> time, plus or minus transmission delays.
I had occasion to read the details recently just to refresh my memory of
the details. What you say is not quite right.
Once a subscription is in place, the notifier is not permitted to extend
it by sending a notify with a value further in the future. An attempt to
do so is an error, but the action to take in that case is not defined.
I think the plausible action to take is to do a "min" of values so that
it is never extended that way.
To get an extension, a resubscribe must be sent that *proposes* a value
in the future. The notifier then provides a value in the 200 that may be
no further in the future than that.
Its a notify between the resubscribe and the 200 that presents problems.
Is it limited to the old value in force, or to the new value presented
in the resubscribe? I think this should depend on whether this comes
before or after the resubscribe. But the ordering of events can be
perceived differently by the two sides, which makes a mess.
> (I assume that the
> subscriber won't have two in-flight SUBSCRIBEs, so it has to receive
> the response to the first, and update its expiration time, before it
> would consider sending a second SUBSCRIBE.)
Yes.
> I don't think the notifier is allowed to on the fly reduce the
> expiration time once it has promised an expiration time,
It seems that it *is* allowed to do that.
> but I suppose
> we must allow that it is allowed to terminate the subscription before
> the expiration time for other reasons. But in either case, it is
> supposed to send a NOTIFY, although that might not be successful.
> Presumably a subscriber receiving a premature *termination* NOTIFY
> (which would not happen under other circumstances)
I don't think a termination notify should be considered "premature".
That is a perfectly valid thing to do. A great example of this is for
the "refer" event. The notifier will typically terminate the
subscription on its own as soon as it has "completed" the refer. (But
AFAIK there is no guarantee that it will.)
> can attempt to
> create another subscription, and if the SUBSCRIBE fails, report an
> error to the layer above it.
I guess this would depend on the type of API you prefer. I am not
inclined to do this automatically.
> An even worse case is if a resubscribe causes a NOTIFY that says to
> increase the value, and then there is a failure response to the
> resubscribe.
>
> I don't think a subscriber can do that -- since a failed SUBSCRIBE has
> no effect, it can't increase the expiration time. (It could still
> stimulate a NOTIFY, but that NOTIFY can't bear a later expiration
> time.) The subscriber must commit itself to a success response
> (though it doesn't have to send it) before it is allowed to send a
> NOTIFY with a later expiration time.
I was thinking of a case where the NOTIFY was sent first, and then
something happens that causes a failure to be sent in response to the
resubscribe. This does however seem to be erroneous behavior on the part
of the notifier.
> An open question is how to receive the NOTIFY in response to a subscribe
> with Expires=0. If the subscription is torn down as soon as the time
> expires (e.g. when a 200 w/Expires=0 is received), then it won't be
> possible to receive a NOTIFY that follows. Either that NOTIFY *must* be
> sent first (a bad assumption I think), or else the subscriber must allow
> some grace period after the subscription expires during which a NOTIFY
> will still be accepted.
>
> Does it matter? If the subscriber tears down the subscription without
> waiting for the NOTIFY, it clearly doesn't care if it receives the
> NOTIFY. The notifier will receive a 481 to the NOTIFY, and continue
> on to delete the subscription, either in the normal course of
> processing, or as error processing in response to the 481.
It doesn't matter to the notifier (as long as the notifier follows the
rules in the dialogusage draft and doesn't tear down other usages as a
result of the 481). It matters to the subscriber. Forget refreshes for a
minute and consider an initial subscription with expires=0 to poll for
event state. Presumably the subscriber wants the notify. There is no
specification of how long it might be after the 200 before the notify
will be arriving. So there is no definition of how long to keep the
usage active to receive it. But I guess that is more of an
implementation issue than a specification issue.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
