The MSP's Guide to VoIP: Part 4 of 20
You've scoped the project, the client has signed off, and now it's time to figure out what you're actually working with. The network assessment is where the rubber meets the road. It's the difference between a smooth VoIP deployment and a three-month firefight where every other ticket is "my calls sound terrible."
This isn't a theoretical exercise. This is the site survey checklist, the stuff you actually walk through before you commit to a go-live date. We'll cover the internet connection, the internal network, the measurements you need to take, and how to interpret the results. By the end, you'll have a clear framework for sorting clients into three buckets: ready to go, needs some work, or not happening until we fix some things.
Start with the Internet Connection
The WAN link is the single most important factor in VoIP quality. You can have a perfectly configured internal network, but if the internet connection can't sustain real-time media, none of it matters. Here's what to evaluate.
Connection Type
What kind of circuit are they on? This tells you a lot before you even run a test.
Fiber is the gold standard. Symmetric bandwidth, low latency, minimal jitter. If the client is on fiber, you're already in good shape. See our deep dive on fiber for the specifics.
Cable is where things get interesting. Downstream is usually fine, but upstream is often the bottleneck. A 200/10 cable connection looks great on paper until you realize those 10 Mbps upstream need to carry voice, video conferencing, cloud backups, and whatever else is fighting for that pipe. We've written extensively about cable internet and VoIP.
DSL varies wildly depending on distance from the DSLAM. If they're close, it can work. If they're far, latency and bandwidth will be a problem. Fixed wireless and satellite connections introduce their own challenges: higher latency, weather sensitivity, and shared capacity that can degrade during peak hours.
If you're walking into a site running on a basic cable connection with 20+ users, start thinking about whether a dedicated internet access circuit makes sense. DIA gets you symmetric bandwidth, an SLA with teeth, and priority repair. It costs more, but it's the right call for sites where voice quality is non-negotiable.
Upload Speed, Specifically
This is the number that matters most, and it's the one most people overlook. Every concurrent VoIP call consumes roughly 80-100 Kbps upstream using G.711, or about 24-32 Kbps with G.729. That doesn't sound like much, but it adds up fast when you factor in overhead, and it's competing with everything else on the network.
Do the math. Count the maximum number of concurrent calls the client will realistically have. Multiply by 100 Kbps for a conservative G.711 estimate. That's your voice traffic baseline, or use our Bandwidth Calculator to model it with the exact codec and overhead. Now compare that to the available upstream bandwidth. Not the advertised speed, but the actual measured speed during business hours.
A good rule of thumb: voice traffic should never consume more than 30% of available upstream bandwidth. If it does, you're going to have problems, especially during peak usage. This is a concept we explore further in our piece on why call quality drops in the afternoon.
Provider and SLA
Who's the ISP? Do they offer an SLA? What does it actually guarantee? A residential cable connection with "best effort" service is a very different animal than a business-class circuit with uptime guarantees and a four-hour repair window.
Ask for the ISP's contact information, the account number, and the current contract terms. You'll want this when things go sideways, and at some point, they will. Knowing whether you can escalate to a business support team or you're stuck in a residential queue matters.
Also check: is there a single point of failure? One ISP, one circuit, one path into the building? For clients where uptime is critical, a secondary WAN link with automatic failover is worth discussing. It doesn't have to be another fiber circuit. Even an LTE backup can keep phones alive during an outage.
Current Utilization
Don't just measure bandwidth capacity. Measure what's actually being used. The client might have a 100 Mbps symmetric fiber connection, but if cloud backups are saturating the upstream every day at 2 PM, that capacity is spoken for.
If the client has a firewall or router with traffic monitoring, pull the utilization graphs. Look at the patterns over a full business week. You're looking for sustained periods where utilization exceeds 70% of available bandwidth. Those are your danger zones.
If there's no monitoring in place, that's a finding in itself. You'll want to deploy something (even temporarily) to get a baseline before committing to a deployment date. For more on how the ISP connection forms the foundation of everything else, see our earlier post in this series.
Evaluate the Internal Network
The WAN gets the most attention, but the LAN is where plenty of VoIP deployments quietly fall apart. A packet's journey from the phone to the internet is only as good as the weakest link, and that link is often a $40 unmanaged switch hiding under someone's desk.
Switches: Managed vs. Unmanaged
This is a binary question with major implications. Managed switches give you VLANs, QoS, port mirroring, and LLDP-MED for auto-provisioning phones. Unmanaged switches give you none of that.
If the client's network is built on unmanaged switches, you have a decision to make. You can deploy VoIP on a flat network with no traffic prioritization and hope for the best, or you can spec managed switches into the project. For anything beyond a five-person office, managed switches aren't optional. They're required.
Check the switch models, port counts, and age. A ten-year-old 100 Mbps switch is going to be a bottleneck even if everything else is perfect. You want gigabit ports at minimum.
Power over Ethernet
Most modern VoIP phones are PoE-powered. Check whether the existing switches support PoE, and more importantly, whether they have enough power budget for the number of phones you're deploying.
A 24-port PoE switch might have a 190W power budget. If each phone draws 10-13W, that switch can realistically power 15-18 phones, not 24. Factor in any existing PoE devices (access points, cameras) that are already drawing from the budget. Running out of PoE capacity mid-deployment is an embarrassing problem to have.
If the switches don't support PoE, you'll need either new switches or midspan PoE injectors. Budget accordingly.
VLAN Support
Can you segment voice traffic onto its own VLAN? This is one of the most effective things you can do for call quality. A voice VLAN isolates phone traffic from the broadcast storms, large file transfers, and general noise of the data network.
Most managed switches support 802.1Q VLANs. The question is whether the existing network design accommodates them. If the client is running a flat Layer 2 network with a single subnet, adding VLANs means reconfiguring the switching infrastructure and potentially the firewall/router.
It's worth it. A properly configured voice VLAN paired with QoS policies is one of the most reliable ways to protect call quality. We covered the mechanics of QoS in detail in that post, and it's worth reviewing before you design the VLAN and marking strategy.
Cabling
Walk the site. Look at the patch panels, the cable runs, the wall jacks. What category of cabling is installed?
Cat5e is the minimum for VoIP. It supports gigabit Ethernet at distances up to 100 meters and handles PoE without issues. If the site is wired with Cat5e or better, you're fine.
Cat5 (not 5e) is technically capable of gigabit at short distances, but it wasn't designed for it. If you find Cat5, test the runs you'll be using for phones. Marginal cabling works fine until it doesn't.
Cat3 or older? That's a re-cable conversation. No amount of network configuration will compensate for cabling that can't reliably carry the traffic.
Check for obvious problems: cables running parallel to power lines (electromagnetic interference), patch cables that look like they've been chewed on, punch-downs that were done by someone in a hurry. Physical layer issues cause intermittent problems that are maddening to troubleshoot. Better to catch them now.
For a deeper look at your local network and its impact on voice quality, see our dedicated post on the topic.
WiFi Situation
Are any phones going to be on WiFi? Softphones on laptops? Mobile UC apps?
WiFi and real-time voice have a complicated relationship. The shared medium, contention-based access, and susceptibility to interference all work against the predictable, low-latency delivery that voice requires. We've covered this in detail in wired vs. WiFi for VoIP.
If WiFi voice is part of the plan, you need to assess the wireless infrastructure. What access points are deployed? Do they support WMM (WiFi Multimedia) for QoS? What's the channel utilization in the areas where people will be making calls? Are there neighboring networks causing co-channel interference?
For most MSP deployments, the recommendation is simple: hard-wire the desk phones, and accept that softphones on WiFi will have variable quality. Set that expectation with the client upfront.
QoS Configuration
Is QoS configured on the existing network? If so, what's the policy? If not, can the equipment support it?
QoS is only useful if it's configured end-to-end. DSCP markings on voice packets need to be honored at every hop: from the phone, through the switches, through the firewall, and ideally by the ISP. A DSCP marking that gets stripped at the first switch isn't doing anything.
Check whether the firewall/router supports traffic shaping or prioritization on the WAN interface. This is where QoS matters most. Internally, on a properly provisioned gigabit network, congestion is rare. But on the WAN uplink, where bandwidth is constrained, QoS can be the difference between clean audio and choppy, robotic sound.
Take Measurements
Opinions are nice. Data is better. Here's what to measure and how.
Extended Ping and Jitter Tests
Run continuous ping tests to the VoIP provider's SBC or SIP proxy for at least 24 hours. Not five minutes. Twenty-four hours. You need to capture the full business cycle, including the afternoon utilization peak.
Use a tool that logs individual ping times so you can calculate jitter (the variation between consecutive ping times). A simple ping -t will give you round-trip times, but you'll need to post-process the data or use a tool that calculates jitter natively.
Better yet, run a dedicated VoIP quality test. Tools like VoIP Test give you MOS scores, jitter measurements, and packet loss data that are specifically relevant to voice quality. Generic speed tests tell you throughput; VoIP-specific tests tell you whether calls will sound good.
Run these tests from a device plugged into the network where phones will be deployed, ideally on the voice VLAN if one exists. Testing from the IT closet on a different subnet doesn't tell you what the phone on the sales floor will experience.
iperf for Internal Throughput
Use iperf3 to test throughput between network segments. This helps identify internal bottlenecks: an oversubscribed uplink between floors, a dying switch, a duplex mismatch on a trunk port.
Set up an iperf server on one segment and run clients from others. Test with UDP traffic (which is what voice uses) at realistic rates. You're not trying to saturate the link; you're checking whether the internal network can deliver packets consistently at voice-traffic rates.
Pay attention to the jitter and packet loss numbers that iperf reports, not just the throughput. A link that delivers 900 Mbps with 2% packet loss is worse for voice than a link that delivers 100 Mbps with zero loss.
Packet Loss Patterns During Business Hours
This is the measurement that catches problems the others miss. Packet loss is rarely constant. It tends to spike during periods of high utilization. You need to see what happens during the busiest parts of the business day, not just at 7 AM when nobody's there.
Log packet loss continuously for a full business week if possible. Three days at minimum. You're looking for patterns: does loss spike every day at 2 PM? Does it correlate with backup jobs? Does it happen when the office next door starts streaming video?
For a thorough understanding of what packet loss does to voice quality and why even small amounts matter, read our post on understanding VoIP packet loss. And for the jitter side of the equation, what jitter is and why it matters covers the mechanics in detail.
Interpreting the Results
Now you have data. Here's how to read it.
The Three Buckets
Will Work (Green Light)
- Latency to VoIP provider: under 150 ms one-way (under 80 ms is ideal)
- Jitter: under 30 ms (under 15 ms is ideal)
- Packet loss: under 1% (under 0.5% is ideal)
- Sufficient upstream bandwidth with room to spare
- Managed switching with VLAN and QoS capability
- Cat5e or better cabling
- No sustained utilization spikes above 70%
If all of these check out, you're in good shape. Proceed with deployment planning.
Needs Improvement (Yellow Light)
- Latency between 150-250 ms
- Jitter between 30-50 ms
- Packet loss between 1-3%
- Upstream bandwidth is tight but manageable with QoS
- Mix of managed and unmanaged switches
- Some cabling concerns but not widespread
These sites can support VoIP, but not without remediation. The scope of the remediation depends on which metrics are yellow. High jitter with good bandwidth? QoS configuration might fix it. High latency? That's an ISP issue and you may need a different circuit. Packet loss during peak hours? Bandwidth upgrade or traffic shaping.
Present the findings to the client with specific recommendations and costs. "Your network can support VoIP, but we need to address X, Y, and Z first. Here's what that looks like."
Going to Be a Problem (Red Light)
- Latency over 250 ms
- Jitter over 50 ms
- Packet loss over 3%
- Insufficient upstream bandwidth even with QoS
- Unmanaged switches throughout, no VLAN capability
- Cat3 or degraded cabling
- Saturated WAN link during business hours
These sites need significant work before VoIP is viable. Be honest with the client. Deploying voice on a network that can't support it creates a terrible user experience and generates a flood of support tickets that will eat your margin.
The conversation here is: "We need to upgrade the network infrastructure before we can deploy VoIP. Here's the investment required." Some clients will accept that. Others will push back and ask you to deploy anyway. Hold the line. Your reputation is on the line every time a user picks up a phone and hears garbage audio.
Context Matters
These thresholds aren't absolute. A call center with 50 concurrent calls has a much lower tolerance for network issues than a five-person office that makes 10 calls a day. Adjust your standards based on the client's use case, call volume, and tolerance for imperfection.
Also consider the VoIP platform. Some hosted providers are more forgiving of network imperfections than others. Some have built-in jitter buffers that handle moderate jitter gracefully. Others fall apart at the first sign of trouble. Factor in what you know about the platform when interpreting the results.
Document Everything
Your assessment should produce a deliverable. A written report that captures:
- Connection details: ISP, circuit type, contracted speeds, measured speeds
- Network topology: Switch inventory, VLAN configuration, cabling assessment
- Measurement results: Latency, jitter, packet loss, bandwidth utilization (with graphs)
- Findings: What's good, what's concerning, what's a dealbreaker
- Recommendations: Specific actions required before deployment, with estimated costs
- Risk assessment: What happens if the client declines remediation
This document serves two purposes. First, it sets expectations. If the client declines to upgrade their cabling and later complains about call quality, you have a paper trail. Second, it demonstrates professionalism. Clients trust MSPs who do the homework before making promises.
The Assessment as a Sales Tool
A thorough network assessment isn't just a technical exercise. It's a differentiator. Plenty of VoIP providers will ship phones to a site without ever checking whether the network can support them. When those deployments fail (and they will), the client blames the provider and starts looking for someone who does it right.
That someone is you. The MSP who walks in with a checklist, takes measurements, produces a report, and says "here's exactly what we need to do before go-live" wins the trust of the client. It takes more time upfront, but it prevents the avalanche of problems that come from deploying blind.
The assessment also creates opportunities. Need managed switches? You're selling hardware. Need a bandwidth upgrade? You're facilitating an ISP conversation. Need QoS configuration? That's billable engineering time. The assessment naturally surfaces the work that needs to be done, and positions you as the one to do it.
Wrapping Up
The network assessment is the foundation of every successful VoIP deployment. Skip it and you're gambling. Do it thoroughly and you're making an informed decision backed by real data.
Walk the site. Check the connection. Inspect the switches. Test the cabling. Run the measurements for days, not minutes. Interpret the results honestly. Document everything. Then, and only then, commit to a deployment timeline.
Your clients are trusting you to get this right. The assessment is how you make sure you do.
Share
Want to know when we publish new articles? Sign up for updates