net-check

Is this network VoIP-ready? Send real packets and find out.

6.7MB — one double-click executable53Go source files across 15 packages4binaries built from one repo

01

The problem

Every miserable VoIP install has the same suspects: a router quietly rewriting SIP packets, a NAT table dropping mappings mid-call, a path MTU nobody measured. None of it is readable from any API or browser. The only way to know is to send real traffic and watch what comes back.

So I built net-check at VOXO. A support agent generates a link from a dashboard; the customer downloads one 6.7 MB Go executable and double-clicks it. No installer, no admin rights, no typing. It probes SIP ALG, NAT UDP timeout, path MTU, latency, jitter, and loss, then posts graded pass/warn/fail results to a portal both sides watch live.

It turns onboarding arguments into evidence. Instead of 'try rebooting the router', the conversation becomes 'your router's SIP ALG rewrote our test packet — here is the setting to turn off.'

02

How it works

  1. An agent mints a per-customer link from the portal — or lets an AI assistant do it through the built-in MCP server.
  2. The landing page records a claim: this token, this public IP.
  3. The customer downloads one signed 6.7 MB Go exe and double-clicks it. No installer, no admin rights, no typing.
  4. The exe sends real traffic. A SIP OPTIONS packet with sentinel private IPs goes to the production SIP server — if the echo comes back rewritten, the router is running SIP ALG. A parallel UDP ladder (20–330 s, every rung at once) measures the NAT timeout in minutes instead of the sum of all probes. DF-bit UDP datagrams find the path MTU without raw ICMP.
  5. Results post home. The portal matches the exe's source IP to the pending claim — one signed binary serves every customer — and both the customer's branded page and the agent dashboard flip to graded pass/warn/fail pills.

The whole tool exists because no API can read a router's ALG setting. You find out by sending real packets and looking at what comes back.

voxo-netcheck.exe6.7 MB Go probe · no installersip.voxo.coproduction SIP serverUDP echo appliance$5 VM · systemdportalNext.js on Vercelagent dashboard · customer pageMCP: generate_link · get_resultsSIP OPTIONS + sentinel IPsUDP ladder 20–330 s · DF-bit MTUgraded results → matched to IP claim

03

See it working

The replay below tells the story of one probe run — fabricated values, real mechanics. Then open the live portal; it's deliberately open, so you can mint a check link yourself.

voxo-netcheck.exeSIP ALG probe · fabricated rundemo data
probe .execustomer routersip.voxo.co

Scroll into view — or press Next — to launch the probe.

headersentreceived back
ViaSIP/2.0/UDP 192.168.147.53:5060
Contact<sip:probe@192.168.147.53:5060>
SDP c=IN IP4 192.168.147.53
Call-IDnc-demo-5f21c8@probe
analyzing echo…

NAT UDP timeout ladder — every rung probed in parallel

20s
45s
70s
95s
120s
180s
240s
330s
Open the live tool ↗

04

Under the hood

Application-layer SIP ALG detection

The probe sends a real SIP OPTIONS packet with sentinel private-IP values in the Via, Contact, and SDP fields to VOXO's production SIP server, then diffs the echoed payload. It distinguishes 'ALG rewrote the packet' from 'UDP 5060 blocked' from 'no response' — a check that is impossible from a browser.

Parallel NAT UDP-timeout ladder

It opens many UDP bindings at once, each idling on a rung from 20 to 330 seconds while an echo appliance pings back on a timer. Measuring a 300-second-plus NAT timeout costs about six minutes of wall clock instead of the sum of every rung.

Path MTU without admin rights

Instead of raw ICMP (which needs elevation), the probe sends DF-bit UDP datagrams with per-OS socket code for Windows, Linux, and macOS, walking the datagram size down until it fits.

One signed exe for every customer

The landing page records a token-to-public-IP claim; when the generic exe phones home, the portal matches its source IP to the pending claim. No per-customer builds, no codes to type, and results still land on the right customer.

Ships its own MCP server

A Go MCP server exposes generate_link and get_results, so a support agent can mint a check link and read graded results without leaving an AI assistant — which is exactly how VOX consumes it.

  • Go 1.26
  • Next.js 16
  • React 19
  • TypeScript
  • Tailwind CSS 4
  • Neon Postgres
  • mcp-go
  • Vercel
  • Vultr + systemd

05

By the numbers

MB — one double-click executable
0.0
Go source files across 15 packages
0
binaries built from one repo
0
seconds — top rung of the NAT ladder
0
a month to run, all-in
~$0

Next project

VOX