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
