> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 06, 2003 9:34 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] SIP Event Notification > > > I don't think the server can extend expiration time. The terminal > is required to refresh the subscription. [TOLGA]In fact, it is not a real extension purely from notifer side, it is just to make subscriber aware about the successfull authentication refresh and is triggered with reSUBSCRIBE and uses Expires value from reSUBSCRIBE -if it increased Expires value in reSUBSCRIBE, that would be a violation-. Otherwise, should we accept the limitation that subscriber can't know wether there is authentication going on for reSUBSCRIBE and whether it is allowed or not, till original subscription expires? > > /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
