The Polycom IP601

The Polycom IP601 is a very capable SIP VOIP phone. It has been reliable in my asterisk installation for nearly two years as this is being written, and hasn't spontaneously rebooted (as I've seen Cisco 7960 phones do) or otherwise acted unreliable. It has great voice quality, is very configurable, and has been a useful piece of equipment.

The Problem

Among the many features on the phone is a clock that displays the time and date. Better, it can synchronize with the local NTP server to get the time and date, so it's always accurate. You can specify the NTP server name and time zone offset in your DHCP configuration file; the phone will configured itself when it boots.

Unfortunately, nobody told the IP601 about the modification to the daylight savings time specification followed in the United States. When the time change occurred in early March rather than the expected time, the phone continued to display the “old” time. With perfect accuracy, of course.

The Solution

Fortunately, the solution is simple. In the “sip.cfg” file, look for the “SNTP” section. As you might expect, this section contains information related to time services.

Within the SNTP section, you should see tcpIpApp.sntp.daylightSavings.start.month and tcpIpApp.sntp.daylightSavings.start.date. The value you want for month is obvious; date is slightly less obvious; it's interpretation depends on the setting of tcpIpApp.sntp.daylightSavings.fixedDayEnable, which, in this case, should be 1. This means that the daylight savings time shift will occur on first day matching tcpIpApp.sntp.daylightSavings.start.dayOfWeek and on or after date.

Wow — that sounds pretty complicated. Its really not. In the case of the recent March time change:

  1. Make sure that tcpIpApp.sntp.daylightSavings.start.fixedDayEnable is set to 1.
  2. Set tcpIpApp.sntp.daylightSavings.start.month to 3.
  3. Verify that tcpIpApp.sntp.daylightSavings.start.dayOfWeek is 1 (Sunday). It's probably already correct.
  4. Set tcpIpApp.sntp.daylightSavings.start.date to 8. This was the tricky one, and in conjunction with the other settings means that the time change will occur on the first Sunday on or after March 8 - in other words, the second Sunday of the month.

And that's it! Reboot the phone to force it to accept the new settings, and the time should be correct.

Search

Static links

RSS Feed RSS Feed

About this site

Our host

Dynamic links

None