>-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >Marco Ambu >Sent: Friday, October 20, 2006 5:44 AM >To: SIP-implementors mailing list >Subject: [Sip-implementors] Calculation of subscription >duration - updated > >Hi, >I have read may times the thread "Calculation of subscription >duration", but implementing rfc 3266 procedures I still have >some doubts. > >Assuming that subscriber and notifier can agree about the >subscription duration with subscribe/2xx/notify, is there any >reason for the notifier to change the subscription duration >with a notify NOT triggered by a subscribe/refresh. >This notify can be triggered by any event at the notifier >(presence state change, subscription policy change, ...) but I >cannot find a 'reasonable' reason to shorten expires time, >even if it is possible to do that. That is an implementation decision on the notifier. If it has a good reason to do so, it can shorten the expire time. But as you mentioned, why would it do that.
>If the subscription is not longer valid the notifier can send >expires = 0. There is no expires=0 for final Notify, it is Subscription-State: terminated and expires is not a valid parameter for terminated. > >Actually the notifier decides the expiration time (using >subscriber proposal), but it can carry the expiration time >both in 2xx (Expires header mandatory) and in notify. >It seems that the responsibility is not well distributed >considering that notify is sent soon after the 2xx response: >2xx and notify can carry the subscription duration >indipendently, and the values can be different; this leads to >some problems already discussed in the other thread. > >thought #1 >**If there is no reason for the notifier to shorten the >expires time after agreement (subscribe/2xx/notify phase) the >expire time carried by notify could be 'only informational', >to alert the subscriber about the remaining time at the >notifier, and subscription agreement can be left to subscribe/2xx. This is what is described in RFC 3265. > >thought #2 >Otherwise we can use expires time carried by 2xx response to >subscribe/refresh as informational and wait for notify to >decide the agreed subscription time (this allows notifier to >change subscription duration whenever it wants) Subscription duration allowed by notifier is indicated in 200 OK to Subscribe. Subscription-State header in NOTIFY can have an expires parameter which indicates *current* duration left in subscription and the subscriber should adjust it's timers accordingly. Sanjay > >I would like to know your comments about this. > >Thanks. >-- >Marco Ambu >Abbeynet S.p.a. <http://www.abbeynet.it> >E-mail: [EMAIL PROTECTED] >VoIP address: <sip:[EMAIL PROTECTED]> >_______________________________________________ >Sip-implementors mailing list >Sip-implementors@cs.columbia.edu >https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
