> As suggested by Sumit and Pandurangan, if i maintain SUBSCRIBE dialog for > the timer sent in Expires header of 200 OK (which at times might be as large > as one week in IMS) then i would be wasting my resources at PROXY server > unnecessarily which is my concern.
I agree that it is waste of resources waiting for the entire duration sent in Expires header of 200 OK, but since RFC 3265 does not explicitly specify the behavior of UA when initial NOTIFY is not received by the 'subscriber', i was thinking subscription dialog should not be cleared (by UAC or a dialog stateful proxy) under this condition. But take a look at http://tools.ietf.org/html/draft-ietf-sipcore-rfc3265bis-00 It seems to amend/clarify few items in RFC 3265 and you should be using timer L as per the draft. Regards Pandu On Tue, Dec 15, 2009 at 11:22 AM, Dushyant Dhalia <[email protected]> wrote: > > > Paul Kyzivat wrote: > > Pandurangan R S wrote: > > In such a case UAC and NOTIFIER would destroy then SUBSCRIBE > dialog quietly. > > NOTIFIER will destroy the dialog as per RFC3265. > But how/why did the UAC destroy subscribe dialog? I think it has to > wait for the NOTIFY. > > Now my questions are - > 1. Does the proxy server have to start a timer for receipt of NOTIFY? > 2. What should be the value of such a timer, if any? > > NOTIFY can come after quite a long time (authorization may take a long > time, if interacting with user, a primary reason that > subscription-state is *finally* conveyed in a NOTIFY message, a > separate transaction) > > This is wrong. > > INVITE can take a long time, which is why the invite transaction has its own > state machine and the ACK. > > SUBSCRIBE is a normal sip transaction, and times out like one, after (IIRC) > 32 seconds. > > Re the original question: > > Did the proxy Record-Route? If not then it won't see the NOTIFY anyway. > > [Dushyant] > Yes, the proxy inserted Record-Route. > > > The recent clarifications to SUB/NOT (in progress) make it clear that the > dialog/dialog-usage for SUBSCRIBE is established by the NOTIFY, not by the > SUBSCRIBE. So if the proxy is dialog stateful, then it can capture some > *tentative* state based on the SUBSCRIBE, and then watch for NOTIFYs. (The > SUBSCRIBE may be forked.) When/if it sees them it can establish actual > dialog state. If the SUBSCRIBE transaction times out without there having > been any NOTIFYs, then the proxy can forget the whole thing. > > [Dushyant] > SUBSCRIBE transaction has not timed out. UAC has received 200 OK for > SUBSCRIBE but it has not (and won't) received NOTIFY. So, as per the above > clarification (and RFC 3265) PROXY has entered the *neutral* state but the > actual dialog state has not been established. > As suggested by Sumit and Pandurangan, if i maintain SUBSCRIBE dialog for > the timer sent in Expires header of 200 OK (which at times might be as large > as one week in IMS) then i would be wasting my resources at PROXY server > unnecessarily which is my concern. > My suggested solution is - PROXY should wait for 32 seconds (retransmission > of NOTIFY) + 2 seconds (delay in network) and after that it should clear its > resources. > Also, what should be the behavior at the UAC (subscriber)? > > Thanks, > Dushyant > > Thanks, > Paul > > 3. Won't this timer be, if there's any, similar to session-expires timer? > > Anyway, subscribe dialog lifetime is bound (even at proxy, if dialog > stateful) based on expires header 2xx response for subscribe. So I > don't think any other timer is required. > > On Mon, Dec 14, 2009 at 5:43 PM, Dushyant Dhalia > <[email protected]> wrote: > > The scenario is as follows - > > 1. UAC sends SUBSCRIBE. > 2. Proxy forwards SUBSCRIBE to the NOTIFIER. > 3. NOTIFIER sends 200 (OK) which is received by the UAC. > 4. NOTIFIER sends NOTIFY which is lost, retransmissions are also lost. > > As per RFCs 3265 and 5057 subscribe usage should be destroyed in such a > scenario. See sec. 4.2 of RFC 5057 (NOTIFY or refresh-SUBSCRIBE request > timeout). In such a case UAC and NOTIFIER would destroy then SUBSCRIBE > dialog quietly. > > Now my questions are - > 1. Does the proxy server have to start a timer for receipt of NOTIFY? > 2. What should be the value of such a timer, if any? > 3. Won't this timer be, if there's any, similar to session-expires timer? > > Regards, > Dushyant P S Dhalia, > Rancore Technologies, INDIA > > -- > "When work is a pleasure, life is a joy! When work is duty, life is > slavery." > > _______________________________________________ > 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 > > > -- > "When work is a pleasure, life is a joy! When work is duty, life is > slavery." > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
