Interesting. I have recently been fielding questions locally on this
subject.
I do think there are some ambiguities in the spec.
Some key points are:
- Expires value in initial subscription is only a proposal
and upper bound by the subscriber. It is the notifier that
gets to decide the actual value, <= that proposal.
- A notify can again reduce the value, but never increase it.
(There could be problems here if notifier clock runs slower
than the watcher clock.)
- The only way to ever increase the value is if a resubscribe
proposes an increased value and the increase is confirmed
by the notifier.
- If a resubscribe fails, the old value remains in force.
A nasty issue in here is if you send a resubscribe, and then receive a
notify before the final response. If this notify was triggered by the
resubscribe, then it can specify a value up to the new proposal. But if
it was sent before receipt of the resubscribe, then it can only reduce
the old value. But the watcher can't tell which is the case.
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.
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.
It would be simpler if there were a few additional rules:
- no NOTIFY will be sent as result of failing SUBSCRIBE -
even a reSUBSCRIBE. (Maybe this can already be assumed.)
- NOTIFY in response to successful SUBSCRIBE or reSUBSCRIBE
will be sent *after* the successful response is sent.
(But this still doesn't guarantee it will be received
in that order.)
There are a variety of ways to resolve these ambiguities, but they won't
all be interoperable. It would probably be useful to publish subscriber
and notifier state machines for subscriptions to clarify how this is
expected to work.
Paul
[EMAIL PROTECTED] wrote:
> From: Marco Ambu <[EMAIL PROTECTED]>
>
> My problem is to calculate the expiration time of a subscription when
> sending subscribe.
> Can the two values (the one in the response and the one in the notify)
> be different?
>
> It doesn't matter. Since the expiration *time* as determined by the
> subscriber is always "current-time + reported-subscription-duration",
> delays in the network can cause the subscriber to see different
> expiration times from different messages even if the notifier is
> perfectly accurate.
>
> However, the calculated expiration times should always be close,
> within a few seconds at most. That much slop should not affect your
> subscription-refresh algorithm significantly, which should be
> refreshing the subscription well before it expires.
>
> Does the last message received win in determining expiration time?
>
> That's the method many agents use.
>
> In any case, if the subscription expires when the subscriber does not
> expect it to, the notifier is required to send a final NOTIFY saying
> so, and the subscriber can then resubscribe.
>
> 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
