News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Use of NTP by OBi products

Started by iSKUNK!, November 26, 2012, 12:24:06 PM

Previous topic - Next topic

iSKUNK!

I recently picked up an OBi110 for use with Google Voice, and am happy with it so far. I'm impressed by the functionality and power that's been packed into this little device, and look forward to making use of it for a long time to come.

As a technically-inclined computer user, I've made direct use of NTP Internet time services, and was not surprised to see that the OBi device uses these as well to keep its internal clock synced. However, there are a couple of issues with this aspect of the device as currently implemented in the firmware.

First, the time server specified in the default configuration is pool.ntp.org. This is the top-level hostname for the NTP Pool Project, and in their guidelines for vendors, they state:

QuoteDo not use the standard pool.ntp.org names as a default configuration in your system. The NTP Pool can offer services for you, but it must be setup in advance (see below).

QuoteYou must absolutely not use the default pool.ntp.org zone names as the default configuration in your application or appliance.

According to the guidelines, Obihai should either provide their own time servers (probably stratum-2 systems syncing to an official stratum-1 host), or arrange a vendor zone (e.g. obihai.pool.ntp.org) with the NTP Pool Project and provide a small monetary contribution to help defray costs.

Given that Obihai already maintains a significant amount of Internet infrastructure for the benefit of their devices (i.e. OBiTALK), I believe providing their own NTP servers would be the easiest way to go.

Secondly, in viewing the OBi device's network chatter while idle, I see that it makes an NTP request at a rate of once per hour. Is it really necessary to get the time this frequently? Isn't the device's internal clock reasonably accurate enough to allow syncing once every, say, twenty-four hours? Public time servers are heavily-used resources, and while once an hour may not seem like much, when you multiply that by millions of devices---plus the fact that most users leave the defaults untouched---it adds up to a significant additional burden on a public resource.

There have certainly been cases where Internet-attached devices did the wrong thing vis-a-vis NTP. Given that Obihai already provides an excellent product, and has proven forthcoming and responsive to its user community, my hope is that it can become an example to other vendors in yet another respect.

tgi007

For what it's worth, the NTP implementation appears to have some problems, independent of the choice of "default server" setting.

I have 3 OBi202's I'm experimenting with, one of which I've been using for about 6 months, and one I've been dragging along on trips, for use in hotel rooms and conference rooms.

The "home" unit has "UpTime" of "90 Days 5:55:40", and has been behaving well, but here comes the weird part:

At this moment, the "home" OBi202 has a "CurrentLocalTime" of "7/23/2014 06:07:17" (over a year in the future), and my freshly-powered-on "travel" unit says "5/1/2013 20:36:37" (the correct local time as I type this).

Second weird symptom: the "home" OBi202 continues to work fine, for both inbound and outbound calls (using Google Voice), yet it shows as "offline" on the OBiTalk Dashboard "Status" column (amber/brown icon).

However, on the "Device Configuration" page, under "Configure Voice Service Providers", "SP1" and "SP2" both show as "Connected".

The "travel" OBi202 (freshly-powered-on) correctly shows "online" (green icon).

Both devices are running the most recent firmware (no update icon pending) showing "SoftwareVersion" as "3.0.1 (Build: 3722)".

Both devices are configured with "LocalTimeZone" as "GMT-05:00(Eastern Time)", the default "NTPServer1" of "pool.ntp.org" (also the default empty value for "NTPServer2"), and the usual accompanying values:
   DaylightSavingTimeEnable = true (checked)
   DaylightSavingTimeStart = 3/8/7/2
   DaylightSavingTimeEnd = 11/1/7/2
   DaylightSavingTimeDiff = 1
All configuration settings are applied via OBiTalk Dashboard. There are NO custom settings applied directly to the local device.

Both devices have identical settings across the board, with the only exceptions being which Google Voice accounts are configured as Voice Services' SP1 and SP2, and other necessarily different items such as "DisplayName" ("Voice Services" > "OBiTALK Service" > "OBiTALK Service Settings"). All other settings are the same.

Whether the "home" device is continuing (but failing) to attempt NTP synchronization, or whether its internal NTP client has died and now the clock is free-running, I don't know.

Obviously, this isn't a show-stopper (literally!) since the device continues to function as expected. But if I were using this as part of a business operation, where call-logging required accurate records, I'd be concerned that this ought to get fixed.

Anyone else seen anything like this?

duzlu_it

Keep in mind that under "Service Providers>ITSP Profile X SIP" there is a parameter named "X_ProcessDateHeader".  When this is checked, and it is by default, the Obi will get it's system time and date from the incoming SIP header information.  I would assume both the A provider and the B provider would need to be turned off before the Obi even used the NTP server.

iSKUNK!

Quote from: tgi007 on May 01, 2013, 06:41:07 PMWhether the "home" device is continuing (but failing) to attempt NTP synchronization, or whether its internal NTP client has died and now the clock is free-running, I don't know.

My guess is that the clock started out set incorrectly, and was not corrected by NTP because the time difference was too great. I wouldn't expect this from a simple embedded NTP client, but it's a standard behavior of the official client that runs on PCs/servers.

(The rationale is that the clock is expected to be mostly-correct, needing only a small adjustment, and that a very large time delta would not only be disruptive to correct automatically, but may even represent a bogus result from the server.)

You could try manually setting the clock to the correct time plus or minus a minute or two, and see if the smaller time difference is then corrected by the device.


Quote from: duzlu_it on May 01, 2013, 07:47:24 PM
Keep in mind that under "Service Providers>ITSP Profile X SIP" there is a parameter named "X_ProcessDateHeader".  When this is checked, and it is by default, the Obi will get it's system time and date from the incoming SIP header information.  I would assume both the A provider and the B provider would need to be turned off before the Obi even used the NTP server.

I'm using a Google-Voice-only configuration, which should be fairly common. And otherwise, what happens if you don't get a lot of incoming SIP connections?