inline.
Sanjay Sinha (sanjsinh) wrote:
> Hi Paul,
>
> Pl. see inline ...
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of
>> Paul Kyzivat (pkyzivat)
>> Sent: Thursday, September 28, 2006 11:45 AM
>> To: [EMAIL PROTECTED]
>> Cc: [email protected]
>> Subject: Re: [Sip-implementors] Calculation of subscription
>> duration (RFC 3265)
>>
>> 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.
>
> But the watcher will receive another NOTIFY with new expiration value
> proposal that is triggered by the Re-Subscribe. So even if it updates
> timer value based on previous NOTIFY, ir will have an option to update
> with the new proposal.
So, you are suggesting to treat that notify as if it has been sent
before the subscribe. And if it was, then all is well - you will get
another.
But suppose it in fact was sent in response to the resubscribe, and is
attempting to set the expiration time consistent with the new larger
value in the resubscribe. If it is treated as having been sent earlier,
then that value will be invalid - too large. In general the safest thing
to do when receiving a value that is invalidly large is to reduce it to
the largest value that is valid. And there won't be another notify
coming soon in this case. (But the 200 will still come with its
expiration time.)
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.
>> 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 think that will be a bad implementation to send Notify (triggered by
> re-Subscribe) and then a failure response for re-Subscribe.
I think so too. I am just trying to cover all the cases. If this
happened, depending on how the value in the notify is processed, the
expiration time for the subscription might be increased by the watcher
even though the resubscribe failed. But maybe it doesn't matter much in
this case, since things are broken.
>> 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.)
>
> I think sec. 3.1.6.2 already says this:
>
> Upon successfully accepting or refreshing a subscription, notifiers
> MUST send a NOTIFY message immediately to communicate the current
> resource state to the subscriber.
That says what must happen. It doesn't say what happens when the the
refresh is rejected.
Admittedly this is an unlikely case, and not worth a lot of concern.
The point is, from the perspective of the subscriber, its *possible* to
receive the notify and then receive a failure response. It just do
*something* in this case. Its a question of what it should do.
As I think about this further, I conclude that it is probably safest to
always process a notify as if it had been sent prior to any resubscribe
that might be outstanding. Only allow it to reduce the expiration time
that was in effect before the resubscribe. If it actually was sent
*after* the resubscribe was received, and specifies an increased
expiration time, that will then be lost, but will be fixed with the
receipt of the 200.
Paul
> Sanjay.
>
>> - 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
>>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
