> -----Original Message----- > From: Worley, Dale (BL60:9D30) > Sent: Friday, August 14, 2009 11:18 AM > To: Beeton, Carolyn (CAR:9D60) > Cc: [email protected] > Subject: Re: [sipX-dev] SipSubscribeServer issues > > On Fri, 2009-08-14 at 10:03 -0400, Carolyn Beeton wrote: > > I have noticed the following things while investigating SAA issues: > > > > 2: although the SipPersistentSubscriptionMgr persists the > CSEQ of the > > NOTIFYs it sends, there appears to be a timer involved, > such that if a > > service is restarted soon after sending a NOTIFY, it will > use a CSEQ > > which is too small. This causes Polycom sets to reject the > new NOTIFY, > > which in turn causes problem #1. > > My guess is that this is due to the 20 second delay in > persisting -- the IMDB table is written 20 seconds after the > first change is made. What would be a good solution? > > Dale
I think we need to figure out how to make it persist on shutdown. Currently we don't even try because "Unfortunately, the signal handler has usually closed the IMDB by the time this destructor is called, so this store() cannot be executed." I haven't looked into whether this statement is still true (it may be obvious to others). Maybe the delay should be in the receiving end rather than the sending end... A 20 second interval is a lot to lose, especially when QA is testing the feature's behaviour through restarts :-) Carolyn _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
