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
