> But those lines were not in what you sent before. My last post from this morning at 2am contained the error lines mentioned. It's become a crazy long thread so hard to keep up. If this is not what you're talking about, sorry, I'm working on lack of sleep and a great deal of stress so easy to make errors.
> That is exactly the issue that has already been diagnosed. Something is > setting your clock - this completely messes up all time-based event > handling in sipXecs, and incidentally causes registrations to expire. > > You must track down whatever it is that's changing your clock - Tony > posted some promising-looking hints from the IBM documentation. Yes, I've about that and am waiting for input. The following is what I posted last night. --- Sorry if this gets posted twice, it didn't seem to make it so I put the file on a web server instead of attaching. > What's under devices/network parameters for NTP? 1.pool.ntp.org Enabled 1.pool.ntp.org NTP 2.pool.ntp.org Enabled 2.pool.ntp.org NTP Finally found a lead. We had been waiting to see this happen again and it had been a while so decided to call one of the internal phones and sure enough, after ringing twice, all of the registered phones disappeared from the Active Registrations screen. After a moment, as always, they started showing up again. The sipregistry.log instantly filled with the following, similar lines, as we watched all of the registered phone disappear out of the Active Registrations screen. The main errors appear to be; "2010-07-07T06:00:47.555486Z":68843:KERNEL:WARNING:uc.mydomain.com:OsTimer-12:B6EF4B90:SipRegistrar:"OsTimerTask::insertTimer timer to fire 3375693763 microseconds in the past, queue length = 0" The above definitely points to a timing issue but hardware and OS clocks are still correct and were when we did this testing. "2010-07-07T07:00:48.822979Z":77347:KERNEL:NOTICE:uc.mydomain.com:OsTimer-12:B6EF4B90:SipRegistrar:"OsMsgQShared::doSendCore message queue 'SipUserAgent-22' is over half ful l - count = 51, max = 100" The above having different SipUserAgent number. I read that the above at least, can be safely ignored and would be removed in a future version. The following tests were calls from a cell phone, through a pri to an internal phone. We also tried calling a remote phone but that didn't drop the registered phones. It's definitely random, we didn't find a way to replicate it. Calling a same phone which caused the behavior one didn't cause it again. We tried several times, with a combination of phones registered and not. I came across interesting things related to the error but they appear to have been resolved. On Fri, 02 Nov 2007 16:09:11 -0400, Francis Joanis <francis.joa...@xxxxxxxxx> wrote: >osTimers have gone through a major revamp within the last year. It is >possible these issues are no longer there. But be aware that NTP is >still required, as large jumps in time have unknown consequences, (of >which the osTimer issues are just one). It's 2am so will continue tomorrow, just wanted to make these files available.
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
