Vertex VoIP — "Date Error" with NTP error 0, 200 (clock at 12:00 AM)
TL;DR: This is almost always a network-side problem (outbound NTP blocked or DNS not configured), not a hardware fault. The Vertex's call-processing path is unaffected — only the time/NTP subsystem fails. A short fix: change the NTP servers to a global anycast pair, confirm DNS, and power-cycle.
Symptom
When the Vertex Configuration Tool launches, the user sees a popup:
"Date Error. Try power cycling the Vertex. If problem persists, contact CallerID.com."
On the Time tab the line reads:
NTP Last Date/Time from Unit error 0, 200 12:00 AM
The status banner at the top right still shows Call Processing: ON (green). Behavior is often described as "erratic — works one day, stops the next."
What the error actually means
- error 0, 200 = the firmware's NTP request was issued but no usable reply was received within the timeout window. The unit cannot set its clock.
- 12:00 AM = the on-board clock has reverted to its power-on default. This appears whenever the unit reboots or briefly loses power without a successful NTP sync since.
- Call Processing: ON = the DSP/call-capture path is healthy. CDR data is still being produced (just with bad timestamps until the clock is restored).
- "Erratic" = consistent with intermittent outbound NTP reachability — when sync succeeds the unit looks fine; the next reboot/power blip with NTP blocked brings the error back.
Most likely root cause
Outbound NTP (UDP port 123) from the Vertex's IP is being blocked, rate-limited, or the unit cannot resolve NTP server hostnames because no DNS server is set. The factory-default servers (time.nist.gov, time-b.nist.gov) are US-based and are commonly blocked by enterprise firewalls outside North America (especially in Australia and the EU).
Known firmware quirk to watch for
On Vertex firmware ≥ 119, the Configuration Tool shows four NTP server slots (Server 1 through Server 4) but only the first two are honored by the firmware. Anything typed into Server 3 or Server 4 is silently dropped. Always put the two preferred servers in slots 1 and 2.
Fix — step by step
- Set NTP servers in slots 1 and 2 (Time tab). For sites outside North America, use globally anycast servers that almost always traverse enterprise firewalls:
- Server 1:
0.au.pool.ntp.org(or0.pool.ntp.orgfor sites outside AU) - Server 2:
time.cloudflare.com
- Server 1:
- Confirm a DNS server is set on the Vertex. From the Tools menu, set DNS to
8.8.8.8(Google) or1.1.1.1(Cloudflare). Without DNS, the Vertex cannot resolve any NTP hostname and sync will never start. - Confirm UDP/123 outbound is permitted from the Vertex's LAN IP at the customer-site firewall. If outbound NTP is blocked entirely, no setting on the Vertex will fix it — only the firewall change will.
- Full power-cycle the Vertex (PSU out 30 seconds, plug back in). After NTP servers + DNS are correct, the cold boot lets the firmware re-attempt sync from a clean state.
- After about 60 seconds, click Read Time from Vertex on the Time tab. The clock should populate with a real local time and the error should clear.
How to confirm whether it is hardware
Once NTP servers and DNS are correct and the clock has populated, do one deliberate reboot of the Vertex.
- Clock holds correct time after reboot → unit is healthy. Root cause was network reachability. No hardware action needed.
- Clock returns to 12:00 AM on every reboot, even when NTP is confirmed reachable from a workstation on the same subnet (use any NTP client to test) → escalate. Capture firmware version, unit serial number and a config dump, then book an RMA evaluation with CallerID.com support.
- Call Processing banner ever flips to OFF or the unit becomes unresponsive on the Configuration Tool → that is a different fault, not this one. Open a separate ticket.
Reference / full writeup
The full operator-facing analysis with screenshots and a copy/paste customer reply (originally written for the 02MAY26 Voicelytics incident, helpdesk ticket #261) is at:
https://callerid.link/Voicelytics-Vertex-Date-Error-Analysis-02MAY26.html
Related
- For caller-ID capture problems with calls being missed even though the unit reports healthy, see the EEE Troubleshooting Guide: Vertex-EEE-Troubleshooting-Guide.html
- For information on the four NTP server slots, time/DST tags and other Vertex configuration field behavior, see Vertex-DefaultParameters-Analysis-20APR26.html
Related
For the full reference of every UDP/TCP port a CallerID device uses (NTP UDP/123, device-to-host UDP/6699 and UDP/3520, SIP UDP/5060, web admin TCP/80 + remote-access TCP/443) including failure-mode lookups, see CallerID Devices — Network Ports Reference (article #510).