Skip to main content

VoIP Troubleshooting & Network Diagnostic SOP

Field Value
**Document Type** Standard Operating Procedure — Diagnostic Field Procedure
**Audience** L1 (run tests, collect data) · L2 (interpret, escalate) · L3 (packet capture, UDM API, provider escalation)
**Minimum Tier to Execute** **L1**

for basic tests ·

L2

for full diagnostic ·

L3

for UDM API and packet capture

**Maintenance Window Required** **No**

— all tests are non-disruptive and can run during business hours

**Last Updated** March 2026
**Version** 1.0
**Companion Document** VoIP Operations SOP (Section 7.3, Section 9)
**Related Tickets** **Reference site-specific HALO tickets as encountered**

Automation Roadmap: The VoIP Network Diagnostic Tool (Automation Project 3) will automate the tests in this SOP into a single PowerShell script with automated UDM API integration and PDF report generation. Until that tool is deployed, follow this manual procedure.

1 · Purpose

When a VoIP provider tells a dental practice "it's your network," DTC needs to prove or disprove that claim with documented evidence — not opinions. This SOP provides a structured diagnostic procedure that collects measurable network data, checks the UniFi infrastructure for VoIP-related issues, and produces documentation suitable for sending directly to a provider's Tier 2 support team.

This SOP answers one question: Is the local network causing the VoIP problem?

This SOP does NOT cover:

  • General VoIP symptom troubleshooting (see VoIP Operations SOP, Section 9)
  • VoIP installation procedures (see VoIP Operations SOP, Sections 5-6)
  • Provider-side configuration (call trees, auto-attendants, voicemail)
  • Phone hardware repair or replacement

When to use this SOP:

  • Provider support tells the client or DTC "it's your network" or "it's a network issue"
  • Recurring VoIP quality complaints where the provider cannot identify a cause
  • Post-network-change VoIP issues (after firewall swap, ISP change, VLAN reconfiguration)
  • Pre-escalation evidence gathering before involving a provider's Tier 2/3 engineering team
  • Client onboarding where VoIP quality issues existed before DTC took over the network

2 · Before You Start

2.1 — Gather Context

Before running any test, document these in your HALO ticket:

VOIP DIAGNOSTIC — PRE-ASSESSMENT
=================================
Client:           ____________________
HALO Ticket:      ____________________
VoIP Provider:    ____________________
Provider Ticket#: ____________________ (if they have one open)
Phone Hardware:   ____________________ (e.g., Yealink T54W, Poly VVX 250)
Phone Count:      ____________________
Reported Symptom: ____________________ (no audio / one-way / choppy / drops / no register)
Symptom Scope:    ____________________ (all phones / one phone / all calls / specific numbers)
When Started:     ____________________
Recent Changes:   ____________________ (network, ISP, firmware, provider changes)
ISP Provider:     ____________________
ISP Service Tier: ____________________ (e.g., Comcast 300/35 Mbps)
UDM Model:        ____________________ (UDM, UDM-Pro, UDM-SE)
UDM IP:           ____________________

2.2 — Check the Obvious First

Before running the full diagnostic, spend 2 minutes on these. They resolve 30%+ of VoIP tickets:

  1. Is the internet up? — Open a browser on the same network. If the internet is down, the VoIP issue is an internet issue, not a VoIP issue.
  2. Is the provider having an outage? — Check their status page:
    • Weave: <span class="editor-theme-code">status.getweave.com</span>
    • Freedom Voice: Call partner support 1-844-467-7847
    • RingCentral: <span class="editor-theme-code">status.ringcentral.com</span>
    • 8x8: <span class="editor-theme-code">status.8x8.com</span>
    • General: <span class="editor-theme-code">downdetector.com/search?q=[provider]</span>
  3. Was anything changed recently? — Network changes, ISP maintenance, firmware updates, new devices added. Check the HALO timeline and UDM alerts.
  4. Is it one phone or all phones? — One phone = likely phone/cable/port issue, not network. All phones = network or provider issue.

If any of these resolve the issue, document it, close the ticket, and skip the full diagnostic.

3 · Diagnostic Test Procedures

Run these tests in order. Each test builds on the previous one. You can stop at any point if you find a clear cause.

The overall goal: collect 6 categories of evidence that prove the network is clean.

Test 1: Speed & Bandwidth (L1 can execute)

Purpose: Verify the internet connection supports VoIP alongside normal dental workload.

VoIP Bandwidth Requirements:

  • G.711 codec (used by most providers): ~100 Kbps per concurrent call (both directions)
  • Typical dental office (6-10 phones, 2-3 concurrent calls): needs ~300 Kbps upload minimum for VoIP alone
  • DTC threshold: 5 Mbps upload minimum for any site running VoIP (provides generous headroom)

Procedure:

Run from a workstation on the VOIP VLAN (or CORP if phones share the workstation network):

  1. Open a browser and go to <span class="editor-theme-code">speedtest.net</span> or <span class="editor-theme-code">fast.com</span>
  2. Run 3 speed tests, spaced 2 minutes apart
  3. Record download, upload, and ping for each test
  4. If results vary significantly between tests, that itself is a finding (unstable connection)

From PowerShell (more precise, better for documentation):

# Quick latency baseline to gateway and ISP
$gateway = (Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Select-Object -First 1).NextHop
Write-Host "Gateway: $gateway"

# 20 pings to gateway — looking for loss and variance
Test-Connection -ComputerName $gateway -Count 20 |
    Select-Object Address, ResponseTime, StatusCode |
    Format-Table -AutoSize

# Quick external latency check
Test-Connection -ComputerName 8.8.8.8 -Count 10 |
    Select-Object Address, ResponseTime |
    Format-Table -AutoSize

Document these results:

SPEED TEST RESULTS
==================
Test 1: Download _____ Mbps | Upload _____ Mbps | Ping _____ ms
Test 2: Download _____ Mbps | Upload _____ Mbps | Ping _____ ms
Test 3: Download _____ Mbps | Upload _____ Mbps | Ping _____ ms

Gateway ping (20x): Avg _____ ms | Max _____ ms | Loss _____ %
External ping (10x): Avg _____ ms | Max _____ ms | Loss _____ %

ISP service tier: _____ / _____ Mbps (advertised)
Actual vs advertised: _____% of advertised upload

Pass Criteria:

Metric Pass Warning Fail
Upload speed ≥ 5 Mbps 1-5 Mbps < 1 Mbps
Download speed ≥ 10 Mbps 5-10 Mbps < 5 Mbps
Gateway ping avg < 5 ms 5-15 ms > 15 ms
Gateway packet loss 0% < 1% ≥ 1%
External ping avg < 50 ms 50-100 ms > 100 ms
External packet loss 0% < 1% ≥ 1%

Any packet loss to the gateway is a significant finding. This indicates a problem on the local network (cable, switch port, UDM) — not the ISP or the VoIP provider.

Test 2: Jitter & Stability (L1 can execute)

Purpose: Measure network jitter — the variation in packet delivery timing that causes choppy audio.

What is jitter? If packets arrive at 10ms, 12ms, 11ms intervals — low jitter, good. If packets arrive at 10ms, 45ms, 5ms, 80ms intervals — high jitter, bad. VoIP phones have a jitter buffer (typically 30-60ms) to smooth this out. If jitter exceeds the buffer, audio breaks up.

Procedure:

# Extended ping test — 50 pings to gateway
# We'll calculate jitter manually from the results
$gateway = (Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Select-Object -First 1).NextHop

$results = Test-Connection -ComputerName $gateway -Count 50 -ErrorAction SilentlyContinue
$times = $results | Where-Object { $_.StatusCode -eq 0 } | Select-Object -ExpandProperty ResponseTime

if ($times.Count -gt 1) {
    $avg = ($times | Measure-Object -Average).Average
    $min = ($times | Measure-Object -Minimum).Minimum
    $max = ($times | Measure-Object -Maximum).Maximum
    $loss = (50 - $times.Count) / 50 * 100

    # Calculate jitter (mean absolute difference between consecutive pings)
    $diffs = @()
    for ($i = 1; $i -lt $times.Count; $i++) {
        $diffs += [Math]::Abs($times[$i] - $times[$i-1])
    }
    $jitter = ($diffs | Measure-Object -Average).Average

    Write-Host "=== GATEWAY JITTER TEST ==="
    Write-Host "Packets: 50 sent, $($times.Count) received, $loss% loss"
    Write-Host "Latency: Avg $([Math]::Round($avg,1))ms | Min ${min}ms | Max ${max}ms"
    Write-Host "Jitter:  $([Math]::Round($jitter,1))ms"
} else {
    Write-Host "ERROR: Too few responses to calculate jitter"
}

Run the same test against an external target (VoIP provider SIP endpoint or 8.8.8.8):

# Replace with provider SIP endpoint if known
# Common: sip.freedomvoice.com, weave SIP endpoints
$target = "8.8.8.8"  # or provider SIP endpoint

$results = Test-Connection -ComputerName $target -Count 50 -ErrorAction SilentlyContinue
$times = $results | Where-Object { $_.StatusCode -eq 0 } | Select-Object -ExpandProperty ResponseTime

if ($times.Count -gt 1) {
    $avg = ($times | Measure-Object -Average).Average
    $min = ($times | Measure-Object -Minimum).Minimum
    $max = ($times | Measure-Object -Maximum).Maximum
    $loss = (50 - $times.Count) / 50 * 100

    $diffs = @()
    for ($i = 1; $i -lt $times.Count; $i++) {
        $diffs += [Math]::Abs($times[$i] - $times[$i-1])
    }
    $jitter = ($diffs | Measure-Object -Average).Average

    Write-Host "=== EXTERNAL JITTER TEST ($target) ==="
    Write-Host "Packets: 50 sent, $($times.Count) received, $loss% loss"
    Write-Host "Latency: Avg $([Math]::Round($avg,1))ms | Min ${min}ms | Max ${max}ms"
    Write-Host "Jitter:  $([Math]::Round($jitter,1))ms"
}

Document these results:

JITTER TEST RESULTS
===================
Gateway jitter:   _____ ms (target: < 10ms)
External jitter:  _____ ms (target: < 30ms)
Gateway loss:     _____ %
External loss:    _____ %
Max gateway ping: _____ ms (spikes above 50ms are significant)

Pass Criteria:

Metric Pass Warning Fail
Gateway jitter < 5 ms 5-15 ms > 15 ms
External jitter < 15 ms 15-30 ms > 30 ms
Ping spikes (gateway) None > 20ms Occasional > 50ms Frequent > 50ms

Note: ICMP-based jitter is a proxy for VoIP (UDP) jitter, not an exact measurement. However, elevated ICMP jitter reliably indicates network instability that will affect VoIP. If ICMP jitter is clean, UDP jitter is almost certainly clean. Document this caveat in your report.

Test 3: DNS Resolution (L1 can execute)

Purpose: Verify DNS is resolving VoIP provider endpoints correctly and quickly.

VoIP phones need to resolve provider SIP server hostnames. If DNS is slow, misconfigured, or failing, phones can't register or calls fail intermittently.

Procedure:

# Check what DNS server this machine is using
Get-DnsClientServerAddress -AddressFamily IPv4 |
    Where-Object { $_.ServerAddresses } |
    Select-Object InterfaceAlias, ServerAddresses |
    Format-Table -AutoSize

# The DNS server should be the UDM gateway IP (DTC standard)
$gateway = (Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Select-Object -First 1).NextHop
Write-Host "Default Gateway (should match DNS): $gateway"

# Test DNS resolution for common VoIP endpoints
$endpoints = @(
    "google.com",
    "stun.l.google.com",
    "freedomvoice.com",
    "sip.freedomvoice.com",
    "getweave.com"
)

foreach ($ep in $endpoints) {
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
    try {
        $result = Resolve-DnsName -Name $ep -ErrorAction Stop
        $sw.Stop()
        Write-Host "$ep → $($result[0].IPAddress) ($($sw.ElapsedMilliseconds)ms)" -ForegroundColor Green
    } catch {
        $sw.Stop()
        Write-Host "$ep → FAILED ($($sw.ElapsedMilliseconds)ms)" -ForegroundColor Red
    }
}

Document these results:

DNS TEST RESULTS
================
DNS Server in use: ____________________ (DTC standard: UDM gateway IP)
DNS matches gateway: YES / NO

Resolution tests:
  google.com:            _____ ms  PASS / FAIL
  stun.l.google.com:     _____ ms  PASS / FAIL
  freedomvoice.com:      _____ ms  PASS / FAIL
  sip.freedomvoice.com:  _____ ms  PASS / FAIL
  getweave.com:          _____ ms  PASS / FAIL

Pass Criteria:

Metric Pass Warning Fail
DNS server UDM gateway IP DC IP (functional but non-standard) External DNS / mismatched
Resolution time < 50 ms 50-200 ms > 200 ms or FAILED
All endpoints resolve Yes — Any failure

Test 4: Bandwidth Contention Check (L1/L2 can execute)

Purpose: Identify active bandwidth consumers competing with VoIP traffic.

The single most common cause of VoIP quality issues in dental offices is a Veeam backup or replication job running during business hours. Windows Update downloads are a close second.

Procedure:

# Check for active Veeam jobs
Write-Host "=== VEEAM STATUS ===" -ForegroundColor Cyan
$veeamServices = Get-Service -Name "Veeam*" -ErrorAction SilentlyContinue
if ($veeamServices) {
    $veeamServices | Format-Table Name, Status, DisplayName -AutoSize

    # Check if Veeam B&R is actively running a job (requires Veeam PS module)
    try {
        Add-PSSnapin VeeamPSSnapin -ErrorAction Stop
        $activeJobs = Get-VBRJob | Where-Object { $_.IsRunning }
        if ($activeJobs) {
            Write-Host "⚠ ACTIVE VEEAM JOBS RUNNING:" -ForegroundColor Yellow
            $activeJobs | Format-Table Name, @{N='Type';E={$_.TypeToString}}, @{N='State';E={$_.GetLastState()}} -AutoSize
        } else {
            Write-Host "No active Veeam jobs" -ForegroundColor Green
        }
    } catch {
        Write-Host "Veeam PS module not available — check Veeam console manually" -ForegroundColor Yellow
    }
} else {
    Write-Host "No Veeam services found on this machine"
}

# Check for active BITS transfers (Windows Update downloads)
Write-Host "`n=== BITS TRANSFERS ===" -ForegroundColor Cyan
try {
    $bits = Get-BitsTransfer -AllUsers -ErrorAction Stop
    if ($bits) {
        Write-Host "⚠ ACTIVE BITS TRANSFERS:" -ForegroundColor Yellow
        $bits | Format-Table DisplayName, JobState, BytesTransferred, BytesTotal -AutoSize
    } else {
        Write-Host "No active BITS transfers" -ForegroundColor Green
    }
} catch {
    Write-Host "Unable to query BITS (may need elevation)"
}

# Check top network consumers (quick view)
Write-Host "`n=== ACTIVE NETWORK CONNECTIONS (top by remote endpoint) ===" -ForegroundColor Cyan
Get-NetTCPConnection -State Established -ErrorAction SilentlyContinue |
    Group-Object RemoteAddress |
    Sort-Object Count -Descending |
    Select-Object -First 10 Count, Name |
    Format-Table -AutoSize

Document these results:

CONTENTION CHECK
================
Veeam backup running:      YES / NO
  If YES, job name:        ____________________
  Scheduled window:        ____________________
BITS transfers active:     YES / NO
  If YES, size:            ____________________
Other bandwidth consumers: ____________________
Time of test:              ____________________ (business hours?)

Pass Criteria:

Condition Pass Fail
No active backup during business hours ✅ —
Active Veeam backup during VoIP complaint window — ❌ Reschedule backup
Large BITS transfers active — ⚠ Warning — may affect quality

If a Veeam backup is running during business hours and VoIP quality is poor, you've likely found your cause. Reschedule the backup to after-hours, test again, and document the resolution. This doesn't mean the provider was right about "your network" — it means a bandwidth management issue needs correcting.

Test 5: Route Trace (L2 can execute)

Purpose: Document the network path between the client and the VoIP provider. Identify where latency or loss is being introduced.

Procedure:

# Traceroute to VoIP provider SIP endpoint
# Replace with actual provider endpoint
$target = "sip.freedomvoice.com"  # or provider-specific endpoint

Write-Host "=== TRACEROUTE TO $target ===" -ForegroundColor Cyan
tracert -d -w 2000 $target

# Also trace to a known-good external target for comparison
Write-Host "`n=== TRACEROUTE TO 8.8.8.8 (baseline) ===" -ForegroundColor Cyan
tracert -d -w 2000 8.8.8.8

What to look for:

  • Hop 1 = UDM gateway (should be < 5ms). High latency here = local network issue.
  • Hop 2 = ISP first hop. Latency jump here = ISP handoff issue.
  • Hops 3+ = ISP backbone and beyond. Latency here = ISP or internet routing issue — not DTC's network.
  • Asterisks (*) = Hop doesn't respond to ICMP. Not necessarily a problem — many routers block ICMP traceroute. Only concerning if latency increases after the silent hop.

Document the traceroute output. If latency spikes occur at hop 2 or beyond, this is evidence the issue is upstream of DTC's network.

Test 6: UDM Firewall & IPS Check (L2/L3 — requires UDM access)

Purpose: Verify the UDM is not blocking legitimate VoIP traffic through firewall rules or IPS signatures.

6A — UDM Controller GUI Check (L2 can execute)

  1. Log into the UniFi Controller
  2. Navigate to Alerts / Events and filter for the last 48 hours
  3. Search for any events mentioning:
    • SIP, VoIP, or phone-related IPS alerts
    • Blocked traffic from known phone IPs
    • Threat events involving ports 5060, 5061, or 10000-20000
  4. Navigate to Settings → Security → Threat Management
    • Record the IPS mode: Off / Detection Only / Prevention
    • If Prevention mode is active, check if any VoIP-related categories are being blocked
  5. Navigate to Settings → Security → Firewall
    • Check for any rules that could block VoIP ports (UDP 5060, TCP 5061, UDP 10000-20000, UDP 3478)

Document findings:

UDM FIREWALL & IPS CHECK
=========================
IPS Mode:                    OFF / DETECTION / PREVENTION
VoIP-related IPS events (48hr): _____ (count)
  Details: ____________________
Firewall rules blocking VoIP ports: YES / NO
  If YES: ____________________
VoIP phones visible in client list: YES / NO
  Phone count in UDM: _____

6B — UDM API Queries (L3 only)

For detailed IPS event analysis, use the UDM REST API. This is the method the VoIP Diagnostic automation tool (Project 3) will automate.

# UDM API Authentication
# WARNING: Use Get-Credential — NEVER hardcode or log passwords
$udmIP = "192.168.1.1"  # Replace with actual UDM IP
$cred = Get-Credential -Message "Enter UDM admin credentials"

# Bypass self-signed certificate
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { $true }

# Authenticate
$loginBody = @{
    username = $cred.UserName
    password = $cred.GetNetworkCredential().Password
} | ConvertTo-Json

$session = $null
try {
    $loginResponse = Invoke-RestMethod -Uri "https://${udmIP}/api/auth/login" `
        -Method Post -Body $loginBody -ContentType "application/json" `
        -SessionVariable session
    Write-Host "UDM Authentication successful" -ForegroundColor Green
} catch {
    # Try CloudKey path if UDM path fails
    try {
        $loginResponse = Invoke-RestMethod -Uri "https://${udmIP}/api/login" `
            -Method Post -Body $loginBody -ContentType "application/json" `
            -SessionVariable session
        Write-Host "CloudKey Authentication successful" -ForegroundColor Green
    } catch {
        Write-Host "UDM Authentication FAILED: $_" -ForegroundColor Red
        Write-Host "Skipping UDM API tests" -ForegroundColor Yellow
    }
}

# If authenticated, query IPS events
if ($session) {
    # Get IPS events (last 48 hours)
    # UDM path: /proxy/network/api/s/default/stat/ips/event
    # CloudKey path: /api/s/default/stat/ips/event
    $basePath = "https://${udmIP}/proxy/network/api/s/default"

    try {
        $ipsEvents = Invoke-RestMethod -Uri "$basePath/stat/ips/event" `
            -WebSession $session -Method Get

        $recentEvents = $ipsEvents.data | Where-Object {
            $_.datetime -gt (Get-Date).AddHours(-48).ToUniversalTime()
        }

        Write-Host "`n=== IPS EVENTS (Last 48 Hours) ===" -ForegroundColor Cyan
        Write-Host "Total events: $($recentEvents.Count)"

        # Filter for VoIP-relevant events (SIP ports, phone IPs)
        $voipPorts = @(5060, 5061, 3478, 10000..20000)
        $voipEvents = $recentEvents | Where-Object {
            $_.dest_port -in $voipPorts -or $_.src_port -in $voipPorts -or
            $_.msg -match 'SIP|VoIP|RTP'
        }

        if ($voipEvents) {
            Write-Host "⚠ VoIP-related IPS events found: $($voipEvents.Count)" -ForegroundColor Yellow
            $voipEvents | Select-Object datetime, src_ip, dest_ip, dest_port, msg, action |
                Format-Table -AutoSize
        } else {
            Write-Host "No VoIP-related IPS events" -ForegroundColor Green
        }
    } catch {
        Write-Host "IPS query failed: $_" -ForegroundColor Red
    }

    # Get client list — identify VoIP phones by MAC OUI
    try {
        $clients = Invoke-RestMethod -Uri "$basePath/stat/sta" `
            -WebSession $session -Method Get

        # Known VoIP phone OUI prefixes
        $phoneOUIs = @(
            '80:5e:c0', '80:5e:c1',   # Yealink
            '64:16:7f', '00:04:f2',   # Polycom
            '34:98:b5',               # Poly (HP)
            '00:1b:d4', '5c:50:15',   # Cisco
            '00:0b:82',               # Grandstream
            '0c:38:3e'                # Fanvil
        )

        $phones = $clients.data | Where-Object {
            $mac = $_.mac
            $phoneOUIs | Where-Object { $mac -like "$_*" }
        }

        Write-Host "`n=== DETECTED VOIP PHONES ===" -ForegroundColor Cyan
        if ($phones) {
            $phones | Select-Object @{N='Name';E={$_.hostname}}, mac, ip,
                @{N='VLAN';E={$_.network}}, @{N='Last Seen';E={
                    [DateTimeOffset]::FromUnixTimeSeconds($_.last_seen).LocalDateTime
                }} | Format-Table -AutoSize
        } else {
            Write-Host "No phones detected by OUI — phones may use non-standard MACs"
            Write-Host "Check UDM client list manually for phone hostnames"
        }
    } catch {
        Write-Host "Client query failed: $_" -ForegroundColor Red
    }

    # Logout
    try {
        Invoke-RestMethod -Uri "https://${udmIP}/api/auth/logout" `
            -WebSession $session -Method Post | Out-Null
    } catch {}
}

Pass Criteria:

Condition Pass Fail
Zero IPS events blocking VoIP traffic ✅ —
IPS events blocking SIP/RTP from phone IPs — ❌ Create IPS exception
No firewall rules blocking VoIP ports ✅ —
Firewall rule blocking 5060/5061/RTP range — ❌ Modify rule

Test 7: SIP ALG & NAT Configuration (L2/L3)

Purpose: Verify no device in the network path is mangling VoIP SIP headers.

Check 1 — UDM (DTC-managed)

UniFi UDM does not have a traditional SIP ALG toggle. The UDM's default NAT behavior (port-restricted / consistent NAT) is VoIP-friendly. However, check:

  • IPS is not performing destructive SIP inspection (checked in Test 6)
  • No custom NAT rules are interfering with VoIP traffic

Check 2 — ISP Gateway (if present in the path)

Many ISPs provide a gateway/modem that performs its own NAT. If the ISP device is in NAT mode (not bridge mode), it adds a second NAT hop. This double NAT usually works fine for VoIP (Comcast gateways use port-restricted NAT, not symmetrical), but SIP ALG on the ISP device can break things.

# Check the network path — is there an ISP gateway between UDM and internet?
$tracert = tracert -d -h 5 -w 1000 8.8.8.8
# If Hop 1 = UDM and Hop 2 = ISP public IP → UDM is directly connected (good)
# If Hop 1 = UDM and Hop 2 = another private IP → double NAT (check ISP device)

If double NAT is present:

  1. Identify the ISP gateway IP (usually hop 2 in traceroute, or the WAN IP of the UDM)
  2. Try accessing the ISP gateway admin page: <span class="editor-theme-code">http://[ISP gateway IP]</span>
  3. Look for SIP ALG setting — disable if found
  4. If ISP device is accessible, document its model and SIP ALG status
  5. If not accessible, flag for the client to call their ISP

Document findings:

NAT / SIP ALG CHECK
====================
Double NAT detected:       YES / NO
ISP gateway in path:       ____________________ (model if identifiable)
ISP SIP ALG status:        ON / OFF / UNKNOWN (flag for ISP call)
UDM NAT mode:              Standard (port-restricted) — VoIP compatible
UDM SIP inspection:        None (confirmed in Test 6)

Test 8: VoIP Phone Verification (L1/L2)

Purpose: Confirm the phone itself is healthy and properly configured before blaming the network.

Quick phone checks (do this at the phone, not remotely):

  1. Check phone registration status — Most Yealink/Poly phones show registration status on the idle screen or under Menu → Status. Should show "Registered" for each line.
  2. Check phone IP configuration — Menu → Status → Network:
    • IP address matches expected range (DTC standard .150-.199 for phones)
    • Gateway = UDM IP
    • DNS = UDM IP
  3. Check phone uptime — If the phone has been up for months without reboot, reboot it. Many intermittent VoIP issues are resolved by a phone reboot (the phone re-registers with fresh SIP session).
  4. Check cable and port — Swap the Ethernet cable. Try a different switch port. Rule out physical layer.

From the phone's web interface (if accessible — most Yealink phones have a web UI at their IP address):

  • Check SIP server address — matches provider's documented SIP endpoint?
  • Check registration status — Registered / Unregistered / Trying?
  • Check codec — G.711 (ulaw/alaw) is standard for Freedom Voice and Weave

Document findings:

PHONE CHECK — [Phone Location / Extension]
===========================================
Phone Model:           ____________________
Phone IP:              ____________________
Registration Status:   REGISTERED / UNREGISTERED / TRYING
DNS Server:            ____________________ (should be UDM IP)
Gateway:               ____________________ (should be UDM IP)
Uptime:                ____________________
Cable/port swapped:    YES / NO
Reboot resolved issue: YES / NO

4 · Interpreting Results — The Verdict

After running all tests, determine the verdict:

ALL TESTS PASS ✅

The local network is not causing the VoIP issue.

The evidence shows: adequate bandwidth, low jitter, DNS resolving correctly, no firewall blocks, no IPS interference, no bandwidth contention, and phones are properly configured. The issue is upstream — either the ISP's backbone, the VoIP provider's infrastructure, or the provider's SIP/codec configuration.

NETWORK ISSUES FOUND 🔴

The local network has a problem that needs to be fixed before the provider can be excluded.

Common findings and their fixes:

  • Veeam running during business hours → Reschedule backup window
  • IPS blocking SIP/RTP → Create IPS exception for VoIP phone group
  • High jitter to gateway → Check cabling, switch port, or UDM port. Could indicate failing hardware.
  • Packet loss to gateway → Physical layer issue — cable, switch, or UDM port problem
  • DNS misconfigured → Set DNS to UDM gateway IP per DTC standard
  • SIP ALG enabled on ISP device → Disable SIP ALG or put ISP device in bridge mode
  • Phone misconfigured → Correct IP/DNS/gateway settings, reboot phone

PARTIAL ASSESSMENT — UDM ACCESS NOT AVAILABLE ⚠

If UDM credentials were not available (common at new/prospect sites), note that Tests 6 and 7 could not be fully completed. The LAN-side tests still provide significant evidence, but cannot fully rule out firewall/IPS interference.

5 · Provider Escalation Report Template

When all tests pass and you need to send evidence to the provider, use this template. Copy into the HALO ticket and email to the provider's support team.

Subject: Network Diagnostic Report — [Client Name] — VoIP Issue Not Network-Related

To: [Provider Support Email]
CC: [Client Contact], [DTC Account Manager]

Provider Ticket#: [if known]
DTC HALO Ticket#: [number]
Date of Diagnostic: [date]
Technician: [name]

SUMMARY
We have performed a comprehensive network diagnostic at [Client Name] in response
to the reported VoIP quality issues. All network tests PASS. The local network
infrastructure is correctly configured for VoIP and is not the cause of the
reported issues.

FINDINGS

1. BANDWIDTH
   Upload: [X] Mbps (supports approximately [X÷0.1] concurrent G.711 calls)
   Download: [X] Mbps
   Assessment: PASS — exceeds VoIP requirements

2. LATENCY & JITTER
   Gateway latency: [X] ms average, 0% loss
   External latency: [X] ms average, 0% loss
   Jitter (gateway): [X] ms
   Jitter (external): [X] ms
   Assessment: PASS — within acceptable thresholds

3. DNS
   DNS server: [UDM IP] (local gateway — resolving correctly)
   Provider endpoint resolution: [X] ms
   Assessment: PASS

4. BANDWIDTH CONTENTION
   No active backup jobs or large transfers during test window
   Assessment: PASS — no contention detected

5. FIREWALL / IPS
   UDM IPS events blocking VoIP: NONE (last 48 hours)
   Firewall rules blocking VoIP ports: NONE
   Assessment: PASS — no VoIP traffic blocked

6. NAT CONFIGURATION
   NAT type: Port-restricted (consistent) — VoIP compatible
   SIP ALG: Not applicable (UniFi UDM)
   Assessment: PASS

7. ROUTE TRACE
   [Paste traceroute output]
   Assessment: No abnormal latency on local hops

8. PHONE STATUS
   Phones registered: YES
   Phone configuration: Correct (IP, DNS, gateway per spec)
   Assessment: PASS

CONCLUSION
Based on these findings, the reported VoIP issues are not caused by the local
network infrastructure. We recommend the provider investigate:
- SIP server health and registration handling
- Codec negotiation and media path routing
- Provider-side call routing and trunk capacity
- Any recent changes to the provider's platform

Please contact us at [DTC support email] or reference HALO Ticket [number]
for follow-up.

[Technician Name]
[DTC]

6 · Common VoIP Provider SIP Endpoints

Use these for Test 3 (DNS) and Test 5 (Traceroute). Not all endpoints are publicly documented — verify with the provider if needed.

Provider SIP / Registration Endpoint Status Page
Freedom Voice sip.freedomvoice.com Call 1-844-467-7847
Weave Provisioned per-account (check phone config) status.getweave.com
RingCentral sip.ringcentral.com status.ringcentral.com
8x8 Varies by region (check phone config) status.8x8.com
Vonage Varies (check phone config) status.vonage.com
Mango Voice Provisioned per-account —
Zoom Phone Varies (check phone config) status.zoom.us

7 · VoIP Phone OUI Reference

Use these MAC address prefixes to identify VoIP phones in UDM client lists, ARP tables, or DHCP lease tables.

Manufacturer OUI Prefix(es) Common Models in Dental
Yealink 80:5E:C0, 80:5E:C1 T33G, T43U, T46U, T54W (Weave bundled)
Polycom / Poly 64:16:7F, 00:04:F2, 34:98:B5 VVX 150, VVX 250, VVX 450
Cisco 00:1B:D4, 5C:50:15 SPA 303, SPA 514G (legacy — common at inherited sites)
Grandstream 00:0B:82 GXP 2135, GXP 2170
Fanvil 0C:38:3E X3SP, X4U

Tip: If a phone doesn't match any known OUI, check the UDM client list for hostname patterns. Many phones report their model in the hostname (e.g., "Yealink-T54W", "POLY-VVX250").

8 · Key VoIP Ports Reference

Quick reference for firewall checks (Test 6) and port accessibility verification.

Port Protocol Purpose Used By
5060 UDP SIP signaling (unencrypted) Most providers
5061 TCP SIP over TLS (encrypted) Freedom Voice (encrypted mode), others
5090 UDP SIP alternate Some providers as secondary
3478 UDP STUN (NAT traversal) Weave, RingCentral, most modern providers
10000-20000 UDP RTP (voice media) All providers (range varies)
443 TCP HTTPS (provisioning, web management) Phone provisioning, Weave sync
80 TCP HTTP (phone provisioning) Legacy phone auto-provisioning

9 · Escalation Decision Tree

VoIP Issue Reported
       │
       ├─ Provider says "it's your network"
       │       │
       │       ├─ Run this diagnostic SOP (Tests 1-8)
       │       │       │
       │       │       ├─ ALL PASS → Send provider escalation report (Section 5)
       │       │       │              Provider must investigate their side
       │       │       │
       │       │       ├─ NETWORK ISSUE FOUND → Fix it (Section 4)
       │       │       │              Re-test after fix
       │       │       │              If VoIP still bad → re-run diagnostic, escalate to provider
       │       │       │
       │       │       └─ PARTIAL (no UDM access) → Document what you can
       │       │                      Request UDM credentials
       │       │                      Escalate to L3 if needed
       │       │
       │       └─ Issue clearly on provider side (outage confirmed, config error)
       │               → Document in HALO, notify client
       │
       ├─ Issue seems network-related (all phones affected after network change)
       │       → Check VoIP Operations SOP Section 9 (symptom troubleshooting)
       │       → Run Tests 1-4 of this SOP to validate
       │
       └─ Single phone issue
               → Check physical layer (cable, port, phone)
               → See Test 8 of this SOP
               → Not a network-wide issue — do NOT run full diagnostic

DTC Internal:

  • VoIP Operations SOP (BookStack — companion document, covers installation & symptom troubleshooting)
  • DNS Architecture & Troubleshooting SOP (BookStack)
  • Network Connectivity Troubleshooting Decision Tree (BookStack)
  • DHCP Migration SOP — Windows Server → UniFi UDM (BookStack)
  • Ubiquiti Config Quick Reference (BookStack)

Automation:

  • VoIP Network Diagnostic Tool — Project 3 (Automation System Prompts document) — will automate Tests 1-8 into a single PowerShell script with UDM API integration and PDF report generation

Vendor Resources:

  • Weave Status: status.getweave.com
  • Weave Partner Support: 888-579-5668
  • Freedom Voice Partner Support: 1-844-467-7847
  • Freedom Voice Weblink Portal: weblink.freedomvoice.com

11 · Document Control

Version Date Author Changes
1.0 March 2026 DTC Engineering Initial release — structured diagnostic field procedure
Back to top