I think Gadi is giving a slightly different explanation of what I was
proposing.
The really important thing here is that both sides end up with a
consistent understanding of what the expiration time is. And if that
can't be guaranteed, then it is best for the subscriber to end up
thinking the expiration time is sooner than what the notifier thinks,
because that will give the subscriber a chance to refresh before the
subscription expires.
The notifier is permitted to reduce the expiration time when sending a
notify. (While some would like to think this is only the case for the
initial notify following a subscribe, I can find nothing to support
that.) If this happens, then the subscriber must update its expiration
time in order to remain consistent with the notifier.
If the notifier is non-compliant, and sends a notify that increases the
expiration time, its not clear what the best action is on the part of
the subscriber. It could honor the increase I guess. Or it could ignore
the change. Ignoring the change would mean it will have a shorter
expiration time than the notifier, which isn't such a bad thing. But I
don't think we necessarily must specify behavior in this case.
If a resubscribe has been sent recently, and a notify arrives, there is
ambiguity as to whether the notify was sent before receipt of the
resubscribe, or after. If sent before, then the maximum valid expiration
time is governed by the prior expiration time remaining at the time it
was sent. If it was sent after the resubscribe was received, then it is
governed by the value proposed in the resubscribe.
Because of the ambiguity, the subscriber can't know for sure what to do.
AFAICT, the best option is to come up with an algorithm that ends up
with a workable result regardless of which case applies. One that
probably works reasonably well is to just always believe the notifier.
Another is to always use the min of what you get from the notifier and
what you think the notifier is allowed to specify at that time. One that
*doesn't* work is to ignore the values in notifies. (That might work
some of the time, but it isn't guaranteed to work for all legal notifier
behavior.)
This was discussed in a lot more detail, on the same thread, between
28-nov and 10-oct. If you haven't, you should go back and look at that.
Paul
Gadigeppa Malagund wrote:
> Hi,
>
> We need to consider expires both from NOTIFY and 200 OK (SUBSCRIBE).
>
> If Notifier wants to shorten subscribe duration, then we should update
> expires from NOTIFY (We can decide this based on internal expires timer
> status and expires in NOTIFY),
> else if expires in NOTIFY is more than internal expires timer status, then
> ignore it.
>
> So, we should consider expires in NOTIFY only when Notifier intends to
> shorten subscribe duration.
>
> Regards,
> Gadi
>
> On 11/29/06, Retesh <[EMAIL PROTECTED]> wrote:
>> Hi Ajit
>> You need to consider the expires in NOTIFY only so that you
>> reSUBSCRIBE in time and you need not remove and create a new dialog.
>> This has now become implementation specific, so I think you can take a
>> call on this.
>>
>> Regards
>> Retesh
>>
>> On 11/29/06, Ajit Kumar <[EMAIL PROTECTED]> wrote:
>>> Hi All,
>>> I wanted to suggest a straightforward solution which will work in all
>>> scenarios.
>>> The question here is that, why we as Subscriber are updating our
>>> Subscribe duration for every Notify we get from Notifier. We can safely
>>> rely on the subscribe duration agreed upon by Subscribe-200ok exchange.
>>> Based on the Expires got from 200ok response the Subscriber can go for
>>> refresh. Otherwise, we can send a fresh subscribe if we see subscription
>>> state "terminated" in any Notify.
>>>
>>> Regards
>>> Ajit
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On Behalf Of Ajit
>>> Kumar
>>> Sent: Wednesday, November 29, 2006 9:46 AM
>>> To: 'Paul Kyzivat'; 'Retesh'
>>> Cc: [email protected]
>>> Subject: Re: [Sip-implementors] Calculation of Subscribe Duration
>>>
>>> Hi Paul,
>>> I was also thinking the same as you said but that has been mentioned on
>>> the Notifier side. Notifier can't lengthen the Subscribe duration with
>>> respect to what was proposed in 200ok response. In the scenario I
>>> described, Notifier is compliant to RFC but it's only the delayed notify
>>> that is causing a mismatch at Subscriber side. It's no where mentioned
>>> that the subscriber on getting a Notify from Notifier can't update or
>>> lengthen its Subscribe duration agreed upon after a Subscribe-200ok
>>> exchange.
>>> So I think what Ritesh has suggested may work but I don't know if it
>>> will be RFC compliant or not.
>>> Correct me if I am wrong.
>>>
>>>
>>> Regards
>>> Ajit
>>>
>>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>>> Sent: Tuesday, November 28, 2006 7:37 PM
>>> To: Retesh
>>> Cc: Ajit Kumar; [email protected]
>>> Subject: Re: [Sip-implementors] Calculation of Subscribe Duration
>>>
>>>
>>>
>>> Retesh wrote:
>>>> Hi Ajit
>>>> RFC doesnt mandate that NOTIFY should contain a expires value less
>>>> than that was in 200ok of SUBSCRIBE.
>>> Section 3.2.2 of 3265 says:
>>>
>>> If the value of the "Subscription-State" header is "active" or
>>> "pending", the notifier SHOULD also include in the "Subscription-
>>> State" header an "expires" parameter which indicates the time
>>> remaining on the subscription. The notifier MAY use this mechanism
>>> to shorten a subscription; however, this mechanism MUST NOT be used
>>> to lengthen a subscription.
>>>
>>> It doesn't mandate that the notify contain the expiration time at all
>>> (that is SHOULD), but it MUST NOT lengthen the subscription.
>>>
>>> Paul
>>>
>>>> So, say you remove this
>>>> consideration from your implementation and you just consider the
>>>> NOTIFY containing the expires value as the latest duration of
>>>> subscription, then there shouldnt be any problem.
>>>>
>>>> So, in your scenario you can calculate subscription duration as
>>> follows-
>>>> reSUBSCRIBE (300) -->
>>>> 200 ok (250) <--
>>>> subscription duration = 250
>>>> NOTIFY (400) <--
>>>> 200 ok -->
>>>> subscription duration = 400
>>>> NOTIFY <-- (for the reSUBSCRIBE with x as expires) - This MUST be send
>>>> by the notifier if the earlier NOTIFY was just an event notification.
>>>> 200 ok-->
>>>> subscription duration = x (x will be most likely <= 250)
>>>>
>>>> Hope this helps.
>>>>
>>>> Thanks & Regards
>>>> Retesh Chadha
>>>>
>>>> On 11/28/06, Ajit Kumar <[EMAIL PROTECTED]> wrote:
>>>>> Hi Dale,
>>>>> You mean to say that I should reply to the NOTIFY with 200Ok but this
>>>>> NOTIFY is not going to effect the already agreed upon expire value of
>>>>> 250. So, their can never be an error scenario with respect to
>>> Subscribe
>>>>> duration, as such mismatch can happen anytime, Right..? I was
>>> actually
>>>>> thinking it to be an error case, responding with 4xx (may be 488) or
>>>>> terminate the dialog and send a fresh subscribe.
>>>>> Any clarification will be helpful.
>>>>> Regards
>>>>> Ajit
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [EMAIL PROTECTED]
>>>>> [mailto:[EMAIL PROTECTED] On Behalf Of
>>>>> [EMAIL PROTECTED]
>>>>> Sent: Tuesday, November 28, 2006 1:19 AM
>>>>> To: [email protected]
>>>>> Subject: Re: [Sip-implementors] Calculation of Subscribe Duration
>>>>>
>>>>> From: "Ajit Kumar" <[EMAIL PROTECTED]>
>>>>>
>>>>> Suppose I am already having an established SUBSCRIBE dialog and
>>> the
>>>>> subscription expires after 700sec. Now, I am doing a Re-Subscribe
>>> to
>>>>> refresh my Subscription with a lesser value say 300sec. The
>>> Notifier
>>>>> sends 200ok for the re-subscribe with Expires 250 say. Now I have
>>> set
>>>>> my
>>>>> expiry to be 250sec. After getting the 200Ok for Re-Subscribe I
>>> got a
>>>>> Notify which suggests Expires to be 400sec, this notify can be the
>>>>> delayed Notify of my previous subscription which was supposed to
>>>>> expire
>>>>> after 700sec. Now, how I should respond to this Notify, as my
>>> current
>>>>> expires is 250 and what I am getting is exceeding the value I
>>>>> proposed
>>>>> in Re-Subscribe.
>>>>>
>>>>> It's a messy problem. There was a discussion on the SIP mailing list
>>>>> a month or so ago, but I'm so far behind on my e-mail, I don't know
>>> if
>>>>> a consensus was reached.
>>>>>
>>>>> At one point, I advocated that once a subscription endpoint was
>>>>> established, both the Subscriber and the Notifier would be
>>> constrained
>>>>> to only push the endpoint further into the future (except when
>>>>> terminating the subscription immediately). That eliminates many
>>>>> ambiguities.
>>>>>
>>>>> In the specific case you describe:
>>>>>
>>>>> Clearly, you should respond 200 to the NOTIFY.
>>>>>
>>>>> Because the NOTIFY was likely sent by the Notifier before the
>>>>> re-subscribe, the Subscriber should retain the earlier subscription
>>>>> endpoint (250 secs.), which was agreed upon after the later
>>>>> subscription endpoint.
>>>>>
>>>>> This policy is safe...
>>>>>
>>>>> Dale
>>>>> _______________________________________________
>>>>> Sip-implementors mailing list
>>>>> [email protected]
>>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>>>
>>>>> The information contained in this message may be confidential to
>>> Kodiak Networks, Inc. and its subsidiaries and protected from
>>> disclosure. If this message did not reach the intended recipient, or an
>>> employee or agent responsible for delivering it to the intended
>>> recipient, you are hereby informed that any distribution or copying of
>>> this communication is prohibited. If you have received this
>>> communication in error, please notify us immediately by replying to the
>>> sender of the message and then delete the message. Thank you.
>>>>> _______________________________________________
>>>>> Sip-implementors mailing list
>>>>> [email protected]
>>>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>>>
>>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [email protected]
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>>
>>
>> --
>> With Regards
>> Retesh Chadha
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
