Do us all a favor and consider changing your terminology here. "dropped" and is in the middle of a call and dropped the call, and "lost" (or lose) registration as in I was registered and the registrar seemed to determine that my registration was no longer active.
ensure your cron jobs have nothing to do with timesync being run. ensure ntpd is running ensure this is not on a virtual server ensure you are using an external timesource (example below requires tcp port 123 to be allowed out in a firewall) (other timesources I use are 192.5.41.40 and 192.5.41.40, tick amd tock at annapolis naval academy, naval types are obsessive about time) ensure cmos reports the same date/time your server should have (requires prolonged reboot) Here is a useable ntp.conf file: # ntpd configuration # ------------------ # # Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system. restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery # # Permit all access over the loopback interface restrict 127.0.0.1 # # Local fudge if network servers are not available server 127.127.1.0 fudge 127.127.1.0 stratum 10 # #ntp reports in syslog that authenticate is invalid keyword #authenticate no # driftfile /var/lib/ntp/drift # Synchronize with selected time servers server 0.pool.ntp.org iburst server 1.pool.ntp.org iburst server 2.pool.ntp.org iburst Then I would reboot my server and look at the time and ensure it is right. Secondly, it would be important to know whether our phones are getting time from sipx or somewhere else? If from sipx, then the host sipx is on has to have correct time. If external then tcp port 123 needs to be allowed wherever they are *using sipx or not), and the timesource has to be accurate. I would also point out that in all the years I have used sipx I have never had this issue on any of the systems I have produced. Since this is a BLADE server, I sincerely suspect how the blade management gets its time and does some things internal to the chassis and the blades is part of the issue, and it behooves you to fully investigate that (since it would be a shared cmos of sorts) before posting more information about it. Contrary to what other may have alluded to, I am not so sure your issue(s) are unrelated, and I encourage you to resolve the time issue before doing anything else. *What is the synchronize date and time option?* Specifying *YES synchronizes the time of the integrated server with the time of IBM i during a vary on and every 30 minutes while the server is active. A value of *NO synchronizes the time only during a vary on. For i 6.1, a new value of *NONE disables time synchronization. *Hints:* 1. On IBM i, ensure the system time zone is set to the same value as the integrated server: Check system value QTIMZON. QTIMZON will be set automatically one time, during IBM i install. You can use the Change System Value (CHGSYSVAL) command to change the QTIMZON system value. 2. Ensure the Windows "Automatically adjust clock for daylight savings changes" option is checked. 3. Verify that the QTIME system value on IBM i is correct. *Back to top*<http://www-03.ibm.com/systems/i/advantages/integratedserver/faqinstall.html#main> *How do I set date and time synchronization for my Windows server?* To prevent a conflict with the time synchronization settings of other Microsoft® Windows® server applications, use the Change Network Server Description (CHGNWSD) command to set the Synchronize date and time value (SYNCTIME) to *NO. For more information describing how to use date and time synchronization, see topic Setting the Synchronize date and time value<http://www-912.ibm.com/s_dir/slkbase.nsf/1ac66549a21402188625680b0002037e/2592316b18d8dd5d86256f6300752393> in the IBM i Support: Software Knowledge Base. I think this is all a blade time issue. I hope the next post you have is a Eureka moment. On Wed, Jul 7, 2010 at 3:09 AM, m...@grounded.net <m...@grounded.net> wrote: > 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/ > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: tgrazi...@voice.myitdepartment.net Fax: 434.984.8431 Email: tgrazi...@myitdepartment.net LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
_______________________________________________ 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/
