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. 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). 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 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.) I don't think the notifier is allowed to on the fly reduce the expiration time once it has promised an expiration time, 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) can attempt to create another subscription, and if the SUBSCRIBE fails, report an error to the layer above it. 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. 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. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
