Before commenting inline, I will try to summarize the expiration time
rules as I interpret them from the spec:
- the Expires in the initial SUBSCRIBE defines an upper bound
on the expiration time for the initial subscription
- the Expires in a 2xx response to the initial SUBSCRIBE MUST NOT
exceed the value in the request. (The notifier may reduce, but
not extend the expiration time here.) This value actually sets
the expiration time for the subscription. (Its not clear if the
value in the header must not exceed, or if the computed expiration
time - current time plus value - must not exceed the proposed
expiration time limit - time of sending subscribe plus expires
value in it.)
- NOTIFYs following the initial subscription MAY reduce the
expiration time, but not extend it. (Not stated, but to make
any sense, this must be using expiration times rather than
the deltas in the requests.) I'm not certain, but assume
this is cumulative - that once one notify has reduced the
value, that becomes the limit which subsequent notifies must
not exceed.
- Its not clearly explained, but when an initial NOTIFY is received
in lieu of a 2xx, the expiration value it contains must be
handled the same as the Expires in a 2xx to set the actual
expiration time of the subscription.
- If a 2xx to the subscribe is received after a NOTIFY for the
same dialog, its not clear what to do. If it is consistent
with, or reduces, the value set by the NOTIFY, then I think
all is well and it should be accepted. If it attempts to
increase the value then it perhaps should be ignored on the
assumption that the NOTIFY was sent later and just happened
to arrive sooner.
- Once the initial subscription has been established, extending
the expiration time can only be initiated by the subscriber.
If a reSUBSCRIBE contains an Expires header, that value serves
as a new upper bound on the expiration time, but doesn't actually
change the expiration time. This bound may propose an increase
in the old actual expiration time, or may propose a decrease.
- The 2xx response to a reSUBSCRIBE defines a new expiration time
for the subscription, which MUST NOT exceed to new proposed
expiration time, but given that constraint may exceed the old
actual expiration time.
- If there is an error response to the reSUBSCRIBE, I think
the proposed new upper bound on the expiration time goes
away. The old actual expiration time remains in force and
again serves as the upper bound on what can be used in
NOTIFYs.
- A NOTIFY that is send/received between the sending of a
reSUBSCRIBE and the receipt of the response to that presents
some problems. Its not clear what upper bound applies to
the expiration time it carries: the old actual expiration
time or the new proposed expiration time. The subscriber
can't tell whether the notify was sent after the notifier
received the resubscribe or not, so actions shouldn't be
predicated on that. Unlike the initial subscribe case, here
the final response to the reSUBSCRIBE *will* be received,
so it isn't important that the value in a notify be able to
confirm an increase in the value. It seems workable to
apply the old upper bound to notifies received before the
2xx, and apply the new proposed upper bound only to the
2xx. If a notify is generated because of the resubscribe,
and arrives before the 2xx, and tries to increase the value,
it will then be ignored, but the 2xx following behind it
will still set the increased value, so all should be well.
[EMAIL PROTECTED] wrote:
> 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 more state than that is needed. At least a current expiration
time and a proposed expiration time. When no reSUBSCRIBE is pending
these would be the same.
> 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.
The min is with the proposed expiration time.
> 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 I agree with this. The notifier can always reduce the time.
> > 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.)
I find nothing to suggest your interpretation.
> 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 think this supports my interpretation.
Paul
> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
