Troubleshooting order
Find the layer that is actually failing
Fibre and VoIP symptoms can overlap. A slow website, choppy call, dropped VPN, or one-way audio problem may come from Wi-Fi, router load, DNS, SIP registration, ISP routing, or the voice provider. A good troubleshooting note separates symptoms by layer so the next support person does not have to start again.
Triage
Write down the symptom before changing settings
The first step is not rebooting everything at random. It is recording what is failing, when it started, who is affected, and whether the issue is constant or intermittent. This gives every later test a useful comparison point.
Scope
Check whether the problem affects one phone, one laptop, one room, one app, all internet traffic, or only voice calls.
Timing
Record exact times, call examples, speed-test windows, and whether the issue appears during peak hours, weather events, backups, or large uploads.
Recent changes
Look for router swaps, ISP plan changes, new firewalls, VPN changes, cordless-phone moves, number ports, or provider configuration edits.
Business impact
Note whether the issue is lost calls, poor audio, EFTPOS failure, booking-system failure, staff unable to work, or customer-facing downtime.
Provider-facing evidence
Check ONT, modem, and voice guidance before escalating
NZ providers usually need more than "the internet is bad". They need the affected service, ONT or modem light state, restart order, wired test result, examples, and the troubleshooting already completed. Capturing this detail makes the next call more useful and reduces the chance of repeating the same tests.
Broadband path
One NZ's broadband troubleshooting guidance starts with outage checks, power-cycling hardware in order, and checking modem/ONT state.
Fibre ONT checks
2degrees guidance separates modem checks from ONT checks and calls out ONT red-light states such as Optical/PON or Alarm/LOS.
Voice path
Voice-over-broadband checks should separate internet connectivity, VoIP light or registration state, handset/cable tests, and audio-quality symptoms.
Escalation note
Write down timestamps, affected numbers, wired-test results, ONT/modem lights, provider ticket IDs, and what changed after each restart.
Local network
Rule out devices, Wi-Fi, cabling, and router load
Many fibre and voice problems are local network problems wearing a provider disguise. A test on wired Ethernet, a known-good cable, and a quiet network can separate a real ISP issue from Wi-Fi congestion or router overload.
Wired versus wireless
Test one device by Ethernet if practical. If wired works and Wi-Fi fails, focus on coverage, interference, access points, and channel congestion.
Router health
Check uptime, CPU/load, memory, logs, WAN status, DNS settings, and whether the router is overloaded by backups, cameras, or guest traffic.
Cabling and power
Confirm ONT, router, switches, and phones are powered correctly. Replace suspect Ethernet cables before escalating a line fault.
Controlled restart
If restarting is needed, do it in order: ONT, router, switches, access points, then phones. Record what changed and what did not.
Connection metrics
Measure latency, packet loss, jitter, and throughput
Speed tests alone do not explain voice quality. VoIP is sensitive to jitter, packet loss, and changing latency. A connection can show good download speed while still making calls sound broken.
Latency
Run repeated pings or monitoring to stable endpoints. Sudden spikes can explain choppy voice, VPN drops, and slow interactive systems.
Packet loss
Even small packet loss can hurt calls. Check whether loss appears on the LAN, first hop, ISP path, or only one destination.
Jitter
Record jitter during a bad call if the phone, PBX, router, or provider portal exposes call-quality statistics.
Throughput
Measure upload as well as download. Saturated upload from cloud backup, video, or CCTV can damage voice quality before download looks slow.
Voice specifics
Check SIP and VoIP details separately from internet access
If general internet access works but calls fail, the voice path needs its own checks. Registration, NAT behaviour, codecs, number routing, porting status, provider outages, and handset configuration can each create different symptoms.
Registration
Check whether phones or the PBX are registered with the provider. A registered device with failed calls is a different problem from no registration.
Call direction
Record whether inbound, outbound, internal, mobile, landline, or one specific number range is affected.
Audio direction
One-way audio often points toward NAT, firewall, or RTP path issues. Dropped calls after a fixed time can point toward session timers or firewall state.
Provider evidence
Collect call IDs, timestamps, affected numbers, SIP status codes if available, and screenshots from the provider portal before escalating.
A useful support note
The goal is not to prove who is at fault. The goal is to collect enough evidence that the right provider, technician, or internal support person can make the next move. A good note says what was tested, what was ruled out, and what still needs provider-level access.
Professional context
Support notes are part of the wider technical profile
Fibre and VoIP troubleshooting content supports the same practical profile as the project work: diagnose carefully, record evidence, explain the next action, and leave a system that is easier to support.
Current profile
About John Finnerty gives the broader technical consulting and support context.
Project evidence
The project hub shows software and diagnostics-oriented project notes, including support-friendly project documentation.
Local context
The Christchurch profile connects this support topic to the local service area.
Related reading
The DNS and email checklist covers another common layer of SME technical support.
Related services
Networking, fibre, and VoIP support
Fibre and voice problems are easier to solve when the symptoms, modem/router state, and provider evidence are captured cleanly. These pages connect the troubleshooting checklist to the service areas they sit within.