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. > >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. > >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. 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
