A fast download speed does not automatically mean your network is ready for cloud calling. Voice and video depend on consistent packet delivery, low delay, minimal variation, and sufficient capacity during the busiest parts of the workday.
A proper VoIP speed test should measure more than upload and download bandwidth. It should also evaluate latency, jitter, packet loss, firewall connectivity, and the number of simultaneous calls the network may need to support.
Run a Webex Calling network test
Cisco CScan tests the connection between your current location and a Webex Calling data center. Its basic test reports bandwidth, latency, estimated concurrent calls, traceroute information, and selected port connectivity.
The advanced diagnostic test adds upload and download packet loss and jitter measurements.
Run the Cisco CScan TestThe advanced test requests temporary microphone and camera permission to establish a WebRTC connection. Cisco states that it does not save audio or video packets.
What should a VoIP speed test measure?
These are planning targets, not promises. A test taken at 7:00 a.m. may look excellent while the same connection struggles during a busy afternoon. Run multiple tests from the locations, devices, and networks employees actually use.
How to interpret your results
| Measurement | Healthy planning target | Investigate when |
|---|---|---|
| One-way latency | Below 100 ms | Approaching or exceeding 100 ms |
| Jitter | Below 10 ms | Results vary or exceed 10 ms |
| Packet loss | 0% to 0.5% | Loss exceeds 0.5% or occurs in bursts |
| Bandwidth | Enough for peak concurrency with headroom | Usage regularly approaches circuit capacity |
| Port connectivity | Required tests succeed | UDP or signaling connectivity fails |
How much bandwidth does cloud calling require?
Voice uses far less bandwidth than most video or file-transfer applications, but bandwidth must be available in both directions and across every relevant call leg.
Cisco recommends allowing approximately 100 kbps per audio stream. An internal enterprise call may require two audio streams, or approximately 200 kbps. Your actual planning calculation must account for simultaneous calls, call types, network overhead, other applications, and growth.
Simple planning example: If a location expects 25 simultaneous audio calls, allocating at least 5 Mbps for the two audio streams provides a starting point. The final design should also include overhead, business traffic, peak utilization, and operational headroom.
Video changes the calculation. Cisco lists approximate Webex App usage of 700 kbps for 360p video and 1.5 Mbps for 720p video. Actual consumption can fluctuate as Webex adapts video quality to current network conditions.
How to run a meaningful network-readiness test
- Use a wired connection first. This establishes a baseline without introducing Wi-Fi coverage or interference variables.
- Repeat the test over Wi-Fi. Test from desks, conference rooms, common areas, and any location where employees regularly make calls.
- Test during busy periods. Run tests while employees are working, video meetings are active, backups are running, and cloud applications are in use.
- Test every office and internet connection. Results from headquarters do not establish readiness for branches, home users, or remote sites.
- Run more than one test. Intermittent loss and jitter may disappear during a single short test.
- Save the reports. Compare results by time, location, device, and connection type so recurring patterns become visible.
Why a normal internet speed test is not enough
It prioritizes throughput
A standard test mainly measures how quickly data transfers to and from a nearby server. Voice quality depends heavily on consistency, not just maximum speed.
It may use the wrong destination
A nearby consumer speed-test server does not represent the complete path between your network and the calling platform’s media services.
It may miss brief disruptions
Short bursts of packet loss or jitter can noticeably affect a conversation even when the average result looks acceptable.
It does not validate configuration
Download speed alone cannot confirm firewall ports, NAT behavior, QoS, DNS, wireless design, or whether voice traffic is taking the intended path.
Wi-Fi can change an otherwise good result
The internet circuit may be healthy while individual users experience poor calls over Wi-Fi. Signal strength, interference, channel utilization, access-point placement, client density, roaming, and older wireless devices can all affect real-time traffic.
Compare wired and wireless tests from the same location. If wired results are consistently healthy but wireless results are not, investigate the wireless environment before purchasing more internet bandwidth.
Bullfrog Group’s Cisco networking and Meraki solutions provide visibility across wireless clients, access points, switching, security, and WAN connectivity so teams can trace performance problems through the complete traffic path.
What to check when the network fails
Network-readiness checklist
- Confirm the circuit is not saturated during peak periods
- Compare wired and wireless test results
- Check for packet loss, jitter, and unstable latency
- Review switch-port errors and negotiated link speeds
- Confirm firewall capacity with security services enabled
- Validate Webex Calling ports, protocols, domains, and IP ranges
- Avoid routing real-time media through unnecessary proxies
- Configure QoS consistently across switches, routers, and firewalls
- Plan redundancy for locations that require continuous calling
- Retest after every meaningful network change
If the measurements are inconsistent or users already report poor call quality, the next step is a structured network assessment. Read Why Is My Business Network Slow? 9 Problems to Check for a broader troubleshooting process.
Frequently asked questions
What is a good internet speed for VoIP?
There is no single speed that fits every organization. Capacity should be calculated from expected simultaneous calls, video usage, other applications, overhead, peak utilization, and growth. Quality metrics such as latency, jitter, and packet loss matter as much as raw speed.
Can I run a VoIP speed test over Wi-Fi?
Yes, and you should test Wi-Fi because it reflects how many employees actually work. Establish a wired baseline first, then compare it with tests from the wireless locations where calls will occur.
Why do calls sound bad when the speed test is good?
The network may have intermittent packet loss, jitter, Wi-Fi interference, congestion, firewall processing delays, poor QoS, or an inefficient traffic path that a basic throughput test does not expose.
Does QoS fix an inadequate internet circuit?
QoS can prioritize important traffic during congestion, but it cannot create capacity that does not exist. The network still needs adequate bandwidth and properly sized infrastructure.
Should every location be tested before moving to cloud calling?
Yes. Each office, branch, remote location, and internet connection can have different performance, routing, firewall, Wi-Fi, and resiliency characteristics.
Test for call quality—not just speed
A successful cloud-calling deployment begins with a network that can deliver voice and video consistently during real operating conditions. Measure bandwidth, latency, jitter, packet loss, connectivity, and concurrency before migration—not after employees begin reporting problems.
Bullfrog Group helps organizations across the U.S. and Canada assess network readiness, design Cisco-powered infrastructure, and implement secure cloud calling as part of a complete technology strategy.
