Hello @Olivier Thibeault,
welcome back to the Polycom Community.
One customer finally had a ticket raised and we are investigating the root cause at present.
Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.
Best Regards
Steffen Baier
Polycom Global Services
Nothing usefull but, I just found this on voip-info.org :
--------------------------
Polycom Soundpoint IP600 – propably with old firmware – sends NTP timestamps that Wireshark tells me are dated Feb 7, 2036. This means that we have many years of roundtrip time, measured in millisecs. For a phone connected to the same switch as my Asterisk server, that’s a huge latency. I guess they need a bit more of CPU power for that device. (or it’s me that needs help to upgrade my phone to a version where they’ve fixed this bug).
--------------------------
This was back in january 2010, so is nothing new, its come from firmware 2 or 3 at lease. This issue was probably always there form the start.
Any update?
Hello @Olivier Thibeault ,
welcome back to the Polycom Community.
We are working on improving the way the phone will react if it receives a bad NTP packet causing the date to be the "2036"
If you are interested in the progress please open a ticket and quote EN-113273 / 1-11144121987 so we can share a potential test build.
Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.
Best Regards
Steffen Baier
Polycom Global Services
Should I open a ticket as well? I am experiencing the same bug, on VVX600 sets in our office. It happens every couple of weeks.
It's been happening for years, but even as recently as with the latest firmware 5.9.1 it's still happening.
I am very keen to follow this thread and know of any possible solution or test firmware. I can provide any type of debug info needed as well.
The related parts of our globally applied sntp settings are as follows:
<tcpIpApp>
<tcpIpApp.sntp tcpIpApp.sntp.address="ip.of.our.sntp.server(redacted)" tcpIpApp.sntp.address.overrideDHCP="1" tcpIpApp.sntp.resyncPeriod="3600" tcpIpApp.sntp.retryDnsPeriod="3600" tcpIpApp.sntp.daylightSavings.enable="1" tcpIpApp.sntp.daylightSavings.fixedDayEnable="0" tcpIpApp.sntp.daylightSavings.start.date="8" tcpIpApp.sntp.daylightSavings.start.dayOfWeek="1" tcpIpApp.sntp.daylightSavings.start.month="3" tcpIpApp.sntp.daylightSavings.start.time="2" tcpIpApp.sntp.daylightSavings.start.dayOfWeek.lastInMonth="0" tcpIpApp.sntp.daylightSavings.stop.date="1" tcpIpApp.sntp.daylightSavings.stop.dayOfWeek="1" tcpIpApp.sntp.daylightSavings.stop.month="11" tcpIpApp.sntp.daylightSavings.stop.time="2" tcpIpApp.sntp.daylightSavings.stop.dayOfWeek.lastInMonth="0" /> tcpIpApp>
<device
device.set="1"
device.sntp.serverName="cloudprv.com"
device.sntp.serverName.set="1"
/>
Hello all,
we believe we have addressed the issue in our code.
The fix will go into the following releases:
All of the above are subject to change but you should see reference to a NTP bug in the release notes.
A factory reset may be required to clear the local call list on the phone.
Best Regards
Steffen Baier
Hello Steffen,
The 5.9.2 haven't been released yet, please keep us updated when it does,
Latest so far is 5.9.1
Thanks,
Hello @KyleR and all,
If this is urgent Polycom support can release the software if you have an active ticket open.
If this is not possible I believe we post 5.9.2 next week.
Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.
Best Regards
Steffen Baier
Hello all,
The revised date for now is:
All of the above are subject to change but you should see reference to a NTP bug in the release notes.
Best Regards
Steffen Baier