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
