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
