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 > -- Gadigeppa Malagund +91 9845854432 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
