I have an OBI 202 and just like another user, mine shows the wrong date and time. However, powering it off and then on again after waiting 30seconds to a few minutes, does not correct the issue.
All of my other devices in the same network which share pool.ntp.org as their time server show the correct time. My firmware is 3.2.2 (Build: 5898EX). Hardware version 1.4.
The time showing now is: 07:54:16 11/07/2016, Monday
I've changed to a different time server at google. I've used it's IP address to rule out a DNS issue.
At this point, I feel like I need to factory reset the device. Any other ideas?
You failed to mention enough detail to diagnose the problem. For example:
- What is the actual time zone you wish to use?
- Your OBi's firmware is downlevel. Why?
- Are you configuring it via the OBiTALK portal or locally?
- Where is the incorrect time shown? On a telephone's caller ID display or what? If it displays wrong on one attached telephone, did you try another telephone?
If you remove the device from your OBiTALK dashboard, reset the unit to factory defaults, then add it back via the **5 xxxx procedure, configure your SPs, and set the time zone on the main OBiTALK device page, it should simply work. It should also update the device's firmware.
In my case, I modified these settings on the OBi Expert-->Router Configuration-->WAN Settings page as follows:
Change DNS to either Google's public DNS pair (8.8.8.8 and 8.8.4.4) or the Quad9 (https://www.quad9.net/) DNS (9.9.9.9)
Change NTP server to us.pool.ntp.org (assuming you are, indeed, in the USA)
Steve,
Firstly, thank you for your reply and all you do for these forums.
The date is showing in the system status page of the web interface. My Dect phones have to have their clocks set manually. I suspect my FW version is out of date because maintenance lapsed. The update of firmware was set to disabled, which I suspect is done by the mother ship, but would not know for sure.
I don't really think my timezone is relevant to finding a solution. It's likely the same as yours if you live in Washington State. It's appropriate for my location. You just have to trust that a 2016 date is plainly wrong.
My DNS is already with Google. with the same values as quoted above, and I'd already tried us.pool.ntp.org as one of the variants. I merely tried the IP address of a known server as a means of testing I wasn't up against a DNS issue.
So, as I suspected, the solution appears to be starting from scratch.
I want to take exception to your use of the word failed. I think it is unwarranted.
Thank you again for responding to my post.
If you don't like "failed to mention", how about "If you would kindly provide us with more details, perhaps it would help in diagnosing the root cause of the issue."
Anyhow, yah, start from scratch, and see what happens. Since I'm near Seattle, our settings and results should be the same.
Note that there is a lot of confusion about how and whether OBiTALK pushes firmware updates. None of us know for sure how things work now (as opposed to some time in the past). I have a feeling that the parameters shown on the device configuration page (enabling or disabling firmware updates, firmware server, etc) may not matter. All I know is, if you remove and re-add a device, and configure Google Voice, the firmware typically updates itself. I do not think OBiTALK is "pushing" firmware updates anymore without the user asking for them, after a device is added to the portal.
If it doesn't update automatically, you can get it here: http://fw.obihai.com/OBi202-3-2-2-5921EX-332148940.fw (http://fw.obihai.com/OBi202-3-2-2-5921EX-332148940.fw)
As it turns out, I did not have to remove the device or do a factory reset.
The problem was resolved by disabling X_ProcessDateHeader in each of the service provider profiles in use, in my case both A and B. Once I disabled them, the date and time were immediately adjusted to their correct values.
Hope this helps someone in the future.
T
WTH. In all the years I've been on this forum, I have never heard of that parameter even mentioned.
So, the question is, which ITSP are you using on those SP slots? It would help others who may run into this.
Good job figuring it out.
I don't think this is going to be a widespread problem.
I run FusionPBX/Freeswitch on an odroid which does not have a hardware clock. Re-syncing Freeswitch with the system clock corrected the date/time shown in SIP messages, but disabling X_ProcessDateHeader will provide insulation against future trouble. Incidentally, even though the sofia stack was sending SIP messages with incorrect dates, my CDR records reflect correct dates and times.
T
Quote from: SteveInWA on December 18, 2019, 10:04:15 PM
WTH. In all the years I've been on this forum, I have never heard of that parameter even mentioned.
The parameter has always been there. And I think it is "checked" by default. If you don't put in an NTP server or can't reach one you can use the time stamp sent by the ITSP. I suppose there might be a case where you might use it if you wanted your phones to display a different time zone than the one you're actually in.
In my opinion, this feature is OK as a backup strategy where NTP isn't accessible. But to make it the default, and might I say rather invisible choice is a mistake. NTP is reliable and available in most environments.
T