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