I don't think the server can extend expiration time. The terminal is required to refresh the subscription.
/Hisham > -----Original Message----- > From: ext Tolga Asveren [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 06, 2003 4:03 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] SIP Event Notification > > > comments/questions below.... > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Thursday, November 06, 2003 6:19 AM > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: RE: [Sip-implementors] SIP Event Notification > > > > > > As Robert pointed out, the subscription-state header carries > > information about the subscription itself, not the > SUBSCRIBE request. > > > > You have a system that only allows subscription duration for 150 > > seconds (for some reason or another) and it does not allow you to > > have a subscription valid any longer than that. In this case, if > > you subscribe for 150 secs and then after 100 seconds (50 secs > > remaining on your subscription) you refresh the subscribe for > > another 150 seconds (making you current subscription valid for > > 250 secs in total, and extending it by 100 secs), that second > > SUBSCRIBE request does not change that fact that you subscription > > is still active. Therefore the server accepts the SUBSCRIBE > > refresh but lowers the expiration time to 50 (since you already > > spent 100 secs of your quota of 150). > > > > If the server does not know if you're quota will change between > > the time you have sent the SUBSCRIBE refresh and the time the > > original SUBSCRIBE will expire, it must then accept the > > subscription with state active. It can then terminate the > > subscription in a NOTIFY with subscription-state: terminated, if > > it learned that your quota has not been extended. > > > > max allowed-----------| > > |-----50-----100-----150-----200-----250| > > > > <--------SUB---------> > > <--------SUB---------> > > > > > > The server reduces the second SUBSCRIBE expiration time to 50 > > since max allowed total is 150. If server does not know if quota > > will change, it does not reduce the expiration time. At time 150, > > if quota has not changed, server terminates the subscription as > > indicated above. > [TOLGA] Yes, that will work. This solves the problem, how > subscriber is > informed, when referesh is authenticated, because rather than telling > subscriber about successfull authentication, this scenario > accepts refresh > request immediately -even if further authentication is necessary- and > informs subscriber about refresh request indirectly, when it is not > allowed -with NOTIFY(terminated)- when original subscription > timer expires. > In fact, still here some information is lost, i.e. the > subscriber is not > aware of the fact that a further authentication process is > going on for its > refresh and again subscriber does not know that refresh is > not allowed, till > original subscription timer expires. With the scenario, we > were originally > discussing, subscriber had the information that referesh > request is pending > (because it received NOTIFY(active expires=what is left from > original timer) > after reSUBSCRIBE rather than NOTIFY(active expires=timer value with > refresh)) and also it would know that unless it receives NOTIFY(active > expires=timer value with refresh), refresh is not allowed yet > -and maybe > might take further action based on that information- > So, for that reason, I still would like to know, whether the > behavior in the > original scenario is allowed or not: > > | | > |---SUBSCRIBE1(100s)-->| > | | > | | > |<--NOTIFY(active 100s)| subscription allowed > | | > | | > | | > | | > | | > | | > sent after 50s |---SUBSCRIBE2(100s)-->| > | | > | | > |<---NOTIFY(active 50s)| refresh request is > | | not authenticated yet > | | > | | > | (active | > |<--NOTIFY 150-x )-----|referesh request > | |authenticated > | |(let's assume after x > | | seconds) > | | > | | > | | > | | > > > > /Hisham > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf Of > > > ext Tolga > > > Asveren > > > Sent: Wednesday, November 05, 2003 10:52 PM > > > To: Robert Sparks > > > Cc: [EMAIL PROTECTED] > > > Subject: RE: [Sip-implementors] SIP Event Notification > > > > > > > > > Please see my comments/questions below... > > > > > > Tolga > > > > > > [..snip..] > > > > Here is the essence of what's causing us to have this > conversation > > > > I think. How can you be in a state where a watcher has > sufficient > > > > authorization for a subscription to enter the active > state and have > > > > the refresh SUBSCRIBE _NOT_ be approved? The only way I > can think of > > > > is if the presentity has removed approval, in which case the > > > > subscription is no longer active. > > > [TOLGA] Yes, I also believe this is the crucial point. > Let's assume my > > > initial subscribe has expiry timer of 100s. And it is > > > authorized. At t=50s , > > > I sent SUBSCRIBE2 (with Expires=100s). Let's assume, notifier > > > can't decide > > > immediately, whether I am approved for subscriptions more > > > than 100s - I > > > don't think this is unrealistic, subscribing for a > > > resouce/entity for more > > > than a certain amount of time might require additional > authorization-. > > > Subscriber has still have the authorized 50s from intial > > > SUBSCRIBE. Now, > > > notifier can send 200(SUBSCRIBE, Expires=50s) and > > > NOTIFY(active) -50s is, > > > what is left from the initial subscribe, nothing new > approved yet, and > > > because subscription is active -conclusion based on this > > > thread till now, > > > always use current subscription state-, > > > Subscription-State=active in NOTIFY, > > > this also means that the original scenario I did draw was not > > > just odd, but > > > also wrong, i.e. it shouldn't be valid from protocol point of > > > view and a > > > refreshing SUBSCRIBE should never be answered with > > > NOTIFY(pending)). After a > > > while, notifier decides to approve SUBSCRIBE2. How can it > > > inform subscriber > > > about this? Sending a new NOTIFY(active) and using "expires" > > > parameter? I > > > believe, there is nothing not allowing to do so in RFC3265 > > > but I doubt, > > > whether majority of implemantations would behave properly in > > > such a case, > > > i.e. updating subscription timer based on "expires" field > in such a > > > NOTIFY(active), which was not sent directly as response to a > > > reSUBSCRIBE. > > > > > > [..snip..] > > > > > > _______________________________________________ > > > Sip-implementors mailing list > > > [EMAIL PROTECTED] > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
