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-0600Date Closed:2011-06-07 14:03:24
Versions:Frequency of
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)

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).


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.


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.