Summary:	ASTERISK-13276: Registration uses hwclock and sysclock to retrieve time
Reporter:	Chris Alcorn (cgmchris)	Labels:
Date Opened:	2008-12-26 17:44:01.000-0600	Date Closed:	2011-06-07 14:03:24
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Registration
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	It looks like different areas of the SIP registration code retrieve the date/time differently. Under *most* conditions the time is pulled from the sysclock, however, under some rare conditions the time appears to be pulled from the hwclock. My system had the hardware clock set 4 hours ahead of the sysclock (it's a new system and I had never ran /sbin/hwclock --systohc). Once every day or so, my service would go out, and "sip show registry" would report a registration time in the future.  Asterisk was showing me as connected with a registration time 4 hours into the future, but my provider was timing me out. I tried the following settings (with no luck) sip.conf: [general] ... registerattempts=0 registertimeout=60 defaultexpiry=120 Granted it's my fault that I did not set the hwclock, but I think Asterisk should also be more consistent on how it pulls the date/time -- hwclock or sysclock, one or the other.
Comments:	By: Tilghman Lesher (tilghman) 2008-12-29 07:23:04.000-0600 Asterisk is very consistent on how it pulls the time -- it's always the sysclock, never the hwclock.  Presumably, you have some other process that is setting the sysclock to the hwclock. By: Chris Alcorn (cgmchris) 2009-01-05 16:58:47.000-0600 If another process is setting the sysclock to the hwclock then this needs to be addressed in the AsteriskNOW distribution. I am running an install of AsteriskNOW, nothing custom except for my Asterisk configuration. Furthermore, after syncing the sysclock and hwclock, over the past weeks I have had ZERO problems with registrations occuring at a FUTURE time. To summarize, either: 1. Asterisk was indeed pulling the time from the hwclock when processing *some* SIP registrations, which explains why they were 4 hours into the future (just like the hwclock). OR 2. AsteriskNOW was secretly setting my sysclock to match my hwclock, processing an arbitrary SIP registration and recording that it occured at a FUTURE time (hwclock), and then changing the sysclock back, before I could check it, just to fool me. So that I am sure that I am making my self clear: At no time did the sysclock and hwclock ever match.  The hwclock was consistently 4 hours ahead, and random/arbitrary sip registrations also occured at a time that matched only the hwclock. Regardless of how or why, this is a legitimate and reproducable problem.  I feel that I have done my duty to report the problem.  Do with it what you will. Cheers. By: David Woolley (davidw) 2009-01-06 05:36:46.000-0600 Application code has to go a long way out of its way to read the RTC rather than the software clock. Is it possible that the timestamp from an incoming messages is being used? By: Chris Alcorn (cgmchris) 2009-01-06 08:25:46.000-0600 Incoming message timestamps or a GMT/time-zone conversion problem; both are possible causes. I looked over the sip registration source code briefly myself and did not find any reference to the hardware clock, but it is possible that a logical error exists with using a sip message timestamp, or a GMT/time-zone conversion issue. It is curious that the problem was resolved by syncing my clocks. You would think that if it was pulling the timestamp from a sip header that it would continue to do so, regardless of my hwclock settings.  Likewise, with GMT/time-zone conversions -- it should not suddenly stop when the hwclock is set.  For the record, I set my time-zone correctly when I installed AsteriskNOW and have not changed it since. Hopefully this helps point everyone in the right direction and we can get to the bottom of this. By: Jason Parker (jparker) 2009-04-23 12:23:51 Putting Asterisk issues into the AsteriskNOW project is the wrong thing to do.  They will never be looked at. AsteriskNOW is unpatched Asterisk on a standard CentOS install.  There is nothing magical added. By: Tilghman Lesher (tilghman) 2009-04-23 13:29:09 Given that this is neither an Asterisk issue nor something that can be fixed in AsteriskNOW, it is likely that this is a CentOS issue.  We advise that you report this problem upstream to them.