Network Readiness Checklist

Bandwidth Requirements

Voice traffic requires relatively modest bandwidth, but it demands consistent, low-latency delivery. A single G.711 call (the most common codec for business VoIP) consumes approximately 87 Kbps in each direction when you account for IP, UDP, and RTP headers. The G.729 codec reduces that to roughly 32 Kbps per call at the cost of slightly lower audio quality.

To calculate your bandwidth requirement, multiply the per-call bandwidth by the maximum number of concurrent calls you expect at each location. A 50-person office where no more than 20 people are on the phone simultaneously needs approximately 1.75 Mbps of dedicated bandwidth for voice using G.711. Add a 20% overhead buffer for protocol signaling and network overhead, bringing the total to approximately 2.1 Mbps.

This bandwidth must be guaranteed, not just available on average. If your 50 Mbps internet connection is routinely saturated by file downloads and cloud backups during business hours, adding VoIP without QoS will result in terrible call quality. Either provision a dedicated voice circuit (a separate internet connection used exclusively for voice traffic) or implement QoS policies that reserve and prioritize voice bandwidth on your shared connection.

Don’t forget about upload bandwidth. Many business internet connections are asymmetric, with upload speeds significantly lower than download speeds. Voice traffic is symmetrical—every call requires equal bandwidth in both directions. A 100 Mbps download / 10 Mbps upload cable connection might support your download-heavy web traffic beautifully but choke on 30 concurrent voice calls that need 2.6 Mbps of upload bandwidth alongside your other upstream traffic.

Quality of Service (QoS) Configuration

QoS is the mechanism that tells your network to prioritize voice packets over everything else. Without QoS, voice packets compete equally with email, web browsing, and file transfers for available bandwidth. When the network is congested, voice packets get delayed or dropped just like everything else—but unlike a slightly slower email delivery, a delayed or dropped voice packet results in audible quality degradation.

The standard approach is to mark voice packets with DSCP (Differentiated Services Code Point) value EF (Expedited Forwarding, decimal 46). This marking tells every router and switch in the path to place these packets in a priority queue, ensuring they’re transmitted ahead of lower-priority traffic. Your IP phones and VoIP appliances should be configured to tag packets with DSCP EF, and every network device between the phone and the internet edge should honor those markings.

Implement strict priority queuing for voice traffic on your edge router. Allocate sufficient bandwidth to handle your maximum concurrent call volume plus signaling overhead, and configure the queue to drop excess traffic rather than buffering it (buffering adds latency, which is worse than a brief interruption for voice). Many modern routers support Low-Latency Queuing (LLQ), which combines strict priority for voice with bandwidth guarantees for other traffic classes.

QoS must be configured end-to-end within your network, but be aware that your markings are typically stripped at your ISP’s ingress point. This means QoS is most effective for managing congestion on your own network—particularly the WAN uplink, which is usually the bottleneck. For traffic traversing the public internet, QoS doesn’t apply, which is one reason that dedicated voice circuits or MPLS connections to your VoIP provider deliver more consistent quality than over-the-top internet calling.

Firewall and Security Configuration

VoIP introduces specific firewall challenges because of the way SIP and RTP work together. SIP signaling typically uses TCP or UDP port 5060 (or 5061 for TLS-encrypted SIP), while the actual audio streams use RTP on a dynamic range of UDP ports—commonly 10000–20000. Your firewall must allow both the signaling and media traffic to pass through without modification.

Many firewalls include a SIP Application Layer Gateway (ALG) that attempts to inspect and modify SIP packets as they pass through. While well-intentioned, SIP ALGs are the single most common cause of VoIP problems behind firewalls. They frequently mangle SIP headers, break NAT traversal, cause one-way audio, and create registration failures. The first step in any VoIP firewall configuration should be to disable the SIP ALG.

For a more robust deployment, place a Session Border Controller (SBC) at your network edge. The SBC handles NAT traversal, provides topology hiding (preventing external parties from seeing your internal network structure), enforces security policies, and normalizes SIP between different vendors’ implementations. It acts as a purpose-built VoIP firewall that understands the protocols and can protect your network without the problems that generic firewall SIP ALGs cause.

Encryption should be implemented wherever possible. Use TLS for SIP signaling to prevent eavesdropping on call setup information (who called whom, when, and for how long). Use SRTP for media encryption to prevent the actual audio content from being intercepted. Your VoIP provider and your phone system must both support these protocols, and the certificates must be properly configured on both ends.

Jitter, Latency, and Packet Loss Testing

Before deploying VoIP, measure the three metrics that matter most for voice quality: latency, jitter, and packet loss. These should be tested on the actual network path that voice traffic will traverse, during business hours when the network is under typical load.

Latency (also called delay) is the time it takes for a packet to travel from source to destination. For voice, one-way latency should be below 150 milliseconds. Above that threshold, conversations start to feel unnatural—speakers begin talking over each other because the delay disrupts the natural rhythm of conversation. Round-trip latency above 300 milliseconds makes real-time conversation difficult.

Jitter is the variation in latency from packet to packet. Even if average latency is low, high jitter means some packets arrive much later than others. VoIP devices include jitter buffers that temporarily hold packets to smooth out these variations, but the buffer adds latency and can only compensate for so much variation. Jitter above 30 milliseconds will typically cause audible quality issues even with jitter buffering.

Packet loss is the percentage of packets that never arrive at their destination. Voice codecs can conceal the effect of very small amounts of packet loss (below 1%) using interpolation algorithms that estimate the missing audio. Above 1%, quality degrades noticeably—listeners hear clicks, gaps, and robotic-sounding audio. Above 3%, the call becomes essentially unusable. Run extended tests (24–48 hours) using tools like iPerf, VoIP-specific assessment tools from your provider, or dedicated network assessment appliances to get an accurate picture of your network’s voice readiness.

Pre-Deployment Checklist

Use this checklist to verify network readiness before your VoIP go-live date. Every item should be confirmed and documented.

Verify that your internet circuit has sufficient bandwidth for voice traffic at peak concurrency, with at least 20% headroom above your calculated requirement. Confirm that upload bandwidth specifically can handle the symmetrical demands of voice traffic alongside your other upstream needs.

Confirm that QoS policies are configured and active on every network device from the phone to the internet edge. Test that DSCP EF markings are preserved end-to-end by running a packet capture at multiple points in the path. Verify that priority queuing is functioning correctly by generating test traffic and confirming that marked packets are prioritized during simulated congestion.

Validate firewall configuration by placing test calls through the production firewall. Confirm two-way audio, proper caller ID, call transfer, and hold/resume functionality. Verify that the SIP ALG is disabled and that the required SIP and RTP port ranges are open. If using an SBC, confirm that registration, inbound calling, outbound calling, and failover scenarios all work as expected.

Review your LAN infrastructure. Ensure switches support 802.1Q VLANs so voice traffic can be segregated from data traffic. Confirm that PoE (Power over Ethernet) capacity is sufficient for all IP phones. Verify that cabling meets at least Cat5e specifications and that cable runs are within the 100-meter maximum for Ethernet.

Document everything. Create a network diagram showing the voice traffic path from phone to provider, including IP addresses, VLANs, QoS markings, and firewall rules. This documentation will be invaluable for troubleshooting and for onboarding future IT staff who need to understand and maintain the voice infrastructure.