> -----Original Message----- > From: Lawrence, Scott (BL60:9D30) > Sent: Tuesday, August 18, 2009 3:11 PM > To: Worley, Dale (BL60:9D30) > Cc: Beeton, Carolyn (CAR:9D60); [email protected] > Subject: Re: [sipX-dev] SipSubscribeServer issues > > On Fri, 2009-08-14 at 11:17 -0400, Dale Worley wrote: > > > > > 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. > > If I recall correctly (and if I'm not remembering something > that I meant to do and never got around to), we solved this > in the registrar by having it always persist the registration > data during the server shutdown. > It's subscription data that is at issue here... is that the same as registration data? (or would the solution you mention cover subscription data also)
I can definitely reproduce this by restarting sipxecs immediately after causing a NOTIFY to be sent. Adding logs in the destructor of SipPersistentSubscriptionMgr shows that the timer was running, but the store() fn was not called (for obsolete reasons). Adding back the call to store() then causes proper operation. Can I go ahead with the obvious fix (remove the comments that say "Unfortunately, the signal handler has usually closed the IMDB by the time this destructor is called, so this store() cannot be executed.", and uncomment the call to mSubscriptionDBInstance->store())? 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/
