From: Paul Kyzivat <[EMAIL PROTECTED]> > 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. So I assume that the subscriber would keep a variable, "most-in-the-future expiration time seen so far from the notifier". Presumably to prune error cases, the subscriber would limit that value to no greater than "most-in-the-future expiration time I have so far proposed". I think the plausible action to take is to do a "min" of values so that it is never extended that way. I'm not sure I see what you mean here. If the subscriber takes the running "min" of the values that it has seen, its idea of when the subscription expires can never advance. 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 don't see it as messy -- assuming that the notifier is not misbehaving, the max of the values seen so far can be depended upon, because the notifier can't retract subscription time it has already granted (without cancelling the subscription entirely). (See discussion below.) > 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. Are you sure? My impression was that while a notifier could *terminate* a subscription before the previously promised expiration time, it could not otherwise decrease the promised expiration time. (And it is not clear why it would want to.) Skimming RFC 3265, I have to argue from the absence of any positive statement allowing it to do so. But there is one ambiguous passage: 3.2.2 The notifier MAY use this mechanism [the Subscription-State expires param] to shorten a subscription; however, this mechanism MUST NOT be used to lengthen a subscription. I argue that the "shorten a subscription" applies only to accepting a shorter extension of a subscription than was requested in a SUBSCRIBE, not shortening a subscription duration that has already been promised in a Subscription-State. I don't think a termination notify should be considered "premature". I use "premature" to mean "before the expiration time previously promised". > 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. Oh, yes. > 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. Yes, but that's in the ever-present swamp of "In theory, it will eventually come through, but in practice you have to have a timeout." Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
