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