🔌
CallerID Devices — Network Ports Reference
This article is the single source of truth for every network port a CallerID.com device uses, in which direction, and what fails if it is blocked. Use it when troubleshooting any "device on the network but not behaving" symptom — clock not syncing, no Caller ID events reaching the host PC, web configuration tool unreachable, encrypted VoIP not decoding, etc.
Quick reference — every port, one table
| Port | Protocol | Used by | Direction | What it does | If blocked, you'll see… |
|---|---|---|---|---|---|
| UDP/123 | NTP | Vertex (VoIP) | Outbound, Vertex → public NTP servers on the internet | Clock synchronization with pool.ntp.org / time.nist.gov / time.google.com / etc. | Vertex pops a "Date Error" dialog with NTP error 0, 200; clock stuck at 12:00 AM; reboots never recover real time. (See also: Vertex VoIP — Date Error / NTP "error 0, 200".) |
| UDP/53 | DNS | Vertex (VoIP) | Outbound, Vertex → DNS resolver (typically the LAN router, or 8.8.8.8 / 1.1.1.1 if statically set on the unit) | Resolves hostnames like pool.ntp.org to IP addresses so NTP can reach them. | Same symptom as UDP/123 blocked — NTP fails because the hostname never resolves. The fix is to set DNS on the Vertex (Tools menu) or unblock UDP/53 outbound. |
| UDP/6699 | CallerID proprietary | All CallerID devices (Basic, Deluxe, Vertex) | LAN-internal, device → host PC running CallerID software (CallerID.com Whozz Calling popup, third-party POS integration, etc.) | Pushes Caller ID event records (incoming-call notifications, outbound dial records, call-duration events) from the device to the listening application. | Device boots and registers fine, web admin is reachable, but the host application shows no incoming-call popups and no call records. This is the most common "device works but my app sees nothing" symptom. |
| UDP/3520 | CallerID proprietary | All CallerID devices (Basic, Deluxe, Vertex) | LAN-internal, device ↔ host PC and the Vertex Configuration Tool | Companion port to UDP/6699 used for device discovery, configuration round-trips, and remote-access broker handshakes (see Remote Access to Vertex Units). | Vertex Configuration Tool stuck on "Refreshing…" forever; remote-access sessions cannot establish; device discovery fails on the LAN. |
| UDP/5060 | SIP | Vertex (VoIP) — passive monitoring | Vertex listens to SIP signaling traffic between the customer's PBX and the SIP trunk; Vertex itself does not initiate SIP traffic | Lets Vertex see call setup messages and extract Caller ID from the SIP From: header. Some PBXs use a different SIP port — confirm with the customer's telecom provider. | Vertex shows no calls at all even though the phones are ringing. Either Vertex isn't receiving the SIP packets (port mirroring / SPAN setup issue on the network switch) or the PBX is using a non-standard SIP port. (See also: Vertex Not Showing Caller ID.) |
| TCP/80 | HTTP | Vertex (VoIP) — web admin | LAN-internal, technician browser → Vertex IP | Web-based admin UI for the Vertex (Time tab, NTP slots, DNS, firmware upload, etc.) when accessed without TLS. | Cannot reach the Vertex's web Configuration page from a workstation on the same subnet — usually a host-firewall or VLAN-isolation problem, not a Vertex problem. |
| TCP/443 | HTTPS | Vertex remote-access broker, firmware/cloud features | Outbound, Vertex → CallerID.com cloud service | Used by the remote-access feature so a CallerID.com technician can reach a Vertex behind a NAT for support sessions. | Remote-access "phone-home" never establishes; technician cannot remotely view the unit. Local LAN admin still works. |
How to think about this for firewall conversations
When working with a customer-site network admin, group the conversation into three lanes — that's how their firewall is organized:
- Outbound to the internet from the Vertex. Required: UDP/123 (NTP), UDP/53 (DNS), TCP/443 (remote access if enabled). If any of these are blocked, the corresponding feature breaks but call processing keeps working.
- LAN-internal between the device and its host PC. Required: UDP/6699 and UDP/3520. Almost never blocked by a corporate firewall, but a strict per-VLAN policy or a host-side software firewall (Windows Defender, third-party endpoint protection) can drop these. Symptom is "device is healthy but no events reach the application."
- SIP traffic into the Vertex. Vertex is a passive listener — the network must mirror or span the SIP traffic to the Vertex's port. UDP/5060 is the standard, but confirm with the SIP trunk provider in case the PBX uses something else.
Failure-mode lookup — "what's broken → which port to check"
| Symptom | First port to suspect |
|---|---|
| Vertex date error / clock at 12:00 AM / NTP error 0, 200 | UDP/123 outbound + UDP/53 outbound + DNS configured on the unit |
| Vertex Configuration Tool stuck on "Refreshing…" | UDP/3520 LAN-side (and remote-access broker if going across the internet) |
| Device on network, web admin reachable, but host app shows no calls | UDP/6699 LAN-side — check the host PC's firewall first, then any inter-VLAN ACLs |
| Vertex on network but shows zero calls during active phone activity | UDP/5060 — confirm the network is actually mirroring SIP traffic to the Vertex's port; confirm the PBX uses 5060 and not a custom port |
| Encrypted VoIP (TLS/SRTP) — Vertex sees nothing | Not a port problem — Vertex cannot decrypt. Customer needs an EdgeMarc eSBC in front of Vertex (separate article). |
| Cannot remotely reach a customer Vertex for a support session | TCP/443 outbound from the Vertex + UDP/3520 + remote-access feature enabled on the unit |
Quick test commands (technician-side)
- NTP outbound from the Vertex's subnet (run on a workstation on the same LAN):
w32tm /stripchart /computer:pool.ntp.org /samples:3on Windows, orntpdate -q pool.ntp.orgon Linux/Mac. If this works from a workstation but the Vertex still cannot sync, the firewall is allowing the workstation but not the Vertex's IP. - UDP/6699 + UDP/3520 reachability to the host PC: temporarily disable the Windows firewall on the host PC and retry. If events start flowing, add inbound allow rules for UDP 6699 and UDP 3520 on the PC's firewall.
- SIP traffic visibility: run Wireshark on the Vertex's switch port for 60 seconds during an active call. If you see SIP packets, port mirroring is correct; if you don't, the network switch isn't sending SIP traffic to the Vertex.
Related articles
- Vertex VoIP — Date Error / NTP "error 0, 200" / Clock Stuck at 12:00 AM — full playbook for the UDP/123 + DNS failure mode.
- Vertex Not Showing Caller ID — full playbook for the UDP/5060 / SIP-visibility failure mode.
- Remote Access to Vertex Units — covers the UDP/3520 + TCP/443 failure modes.
- VoIP Troubleshooting — Complete Guide — broader VoIP context.
Last updated 02MAY26.