Testing VoIP Before You Deploy: A Pre-Flight Checklist

The best time to discover a VoIP problem is before users are on the system. Every deployment should go through a structured pre-flight check that validates the full stack — internet, LAN, firewall, DNS, endpoints, and actual call quality — before anyone dials a real phone number.

This checklist is organized by layer, from the internet connection down to individual handsets. Work through it in order. A failure in an earlier section often causes failures in later sections, so fix issues as you find them rather than pressing forward.

If you are an MSP, this complements your network assessment and network preparation work. If you have done those steps, some of these items will be a confirmation of work already completed. That is fine. Verify anyway.

Internet connection

A speed test cannot tell you if VoIP will work. You need to test the metrics that actually matter for voice: jitter, packet loss, latency, and MOS.

• [ ] Jitter under 20ms. Test with a UDP-based tool that sends packets at VoIP-like intervals (every 20ms). Run the test for at least 5 minutes during peak business hours. Average jitter should be under 20ms with no sustained spikes above 50ms.

• [ ] Packet loss under 0.5%. Measure loss over the same UDP test. Any consistent loss is a problem. Occasional isolated drops may be tolerable, but burst loss is worse than random loss at the same percentage.

• [ ] Latency under 100ms one-way. Measure round-trip time to your VoIP provider's SIP servers or a representative internet destination. Divide by two for approximate one-way latency. Under 100ms is good. Under 150ms is acceptable. Above 150ms, people start talking over each other.

• [ ] Test during peak hours. Run tests at 10am, 2pm, and 4pm on a business day. Internet quality varies with usage. A test at 6am on a Sunday tells you nothing about what Tuesday afternoon will look like.

• [ ] Test under load. If possible, generate typical business traffic (file transfers, cloud app usage, backups) while running the voice quality test. You need to know how voice performs when the connection is actually being used, not when it is idle.

LAN readiness

The internal network carries voice packets from the phone to the router. Every component in that path matters.

• [ ] Voice VLAN configured. Phones should be on a dedicated VLAN separate from data traffic. Verify that the VLAN is configured on every switch port where a phone will connect, and that the DHCP scope for the voice VLAN is issuing addresses correctly.

• [ ] QoS enabled and verified. QoS markings should be configured on your managed switches and router. Verify that voice packets are being marked with DSCP 46 (EF) and that the router's outbound interface has a priority queue for marked traffic. Note that QoS only protects voice on your local network — ISPs strip these markings at their network edge.

• [ ] PoE budget verified. If phones draw power from the switch via PoE, confirm that the switch's total PoE budget can handle all connected phones plus any other PoE devices (access points, cameras). A switch running out of PoE budget will silently refuse to power additional phones.

• [ ] Switch uplink capacity. The uplink from your access switch to your core switch or router should not be a bottleneck. If 48 phones share a single gigabit uplink to the router, the uplink is fine. If the uplink is 100Mbps and you have 200 phones, do the math. Check your switch configuration for any port speed mismatches.

• [ ] Cabling tested. Every cable run to a phone location should be tested with a cable certifier or at minimum verified to link at the expected speed. A cable that negotiates 100Mbps instead of 1Gbps due to a bad termination will work but may introduce problems under load.

Firewall and NAT

Firewalls are the single most common source of VoIP deployment problems.

• [ ] SIP ALG disabled. Check your router and firewall for SIP ALG (Application Layer Gateway). It should be off. SIP ALG rewrites SIP messages as they cross NAT and almost always introduces more problems than it solves — one-way audio, registration failures, dropped calls. Disable it.

• [ ] SIP signaling ports open. Your VoIP provider will specify which ports SIP uses (typically UDP/TCP 5060 or 5061 for SIP-TLS). Confirm that outbound traffic to your provider on these ports is permitted and that return traffic is allowed through the stateful firewall.

• [ ] RTP port range open. RTP (the actual audio) uses a range of UDP ports, typically 10000-20000 or a subset specified by your provider. Outbound UDP to this range must be permitted. Some firewalls with overly aggressive UDP timeouts will drop RTP sessions — verify that your firewall's UDP session timeout is at least 60 seconds.

• [ ] NAT traversal tested. If phones are behind NAT (they almost always are), verify that NAT traversal is working. The phones should register successfully and maintain registration. Place a test call and confirm audio flows in both directions.

• [ ] No SIP inspection interfering. Some enterprise firewalls have SIP-aware inspection engines (separate from SIP ALG) that can also interfere with signaling. If you have a next-gen firewall, check whether its SIP inspection is modifying packets.

DNS

DNS failures take down VoIP completely because phones need to resolve your provider's SIP server hostname to register.

• [ ] SIP server hostname resolves. From the voice VLAN, verify that your VoIP provider's SIP server FQDN resolves correctly. Check for both A records and SRV records if your provider uses them.

• [ ] DNS response time under 50ms. Slow DNS does not usually affect call quality, but it can slow registration and failover. Verify that your DNS server responds promptly from the voice VLAN.

• [ ] Secondary DNS works. If your primary DNS server goes down, phones need to reach a secondary. Verify that the secondary is configured in your DHCP scope for the voice VLAN and that it resolves the same records.

Failover and redundancy

Do not wait for a real outage to find out if your failover works.

• [ ] Secondary ISP tested. If you have a backup internet connection, simulate a primary failure (unplug it) and verify that traffic fails over. Place a call over the backup connection and confirm quality is acceptable. Some backup connections (LTE, satellite) may have latency or loss characteristics that degrade voice quality.

• [ ] VoIP provider failover tested. If your provider has multiple SIP servers or registrar addresses, verify that phones fail over to the secondary when the primary is unreachable. Simulate this by blocking the primary server's IP in your firewall temporarily.

• [ ] Recovery tested. After failover, restore the primary path and verify that phones fail back correctly. Some configurations require manual intervention to return to the primary — find out now, not during an outage.

Endpoint provisioning

Every phone needs to be individually verified. Bulk provisioning saves time but introduces bulk problems if the template is wrong.

• [ ] All phones registered. Every phone should show a registered status on its display or web interface. An unregistered phone cannot make or receive calls. Check your VoIP provider's portal for registration status of all extensions.

• [ ] Firmware current. Verify that phones are running the firmware version recommended by your provider or manufacturer. Outdated firmware is a common source of intermittent issues that are difficult to troubleshoot.

• [ ] Time and date correct. Phones that cannot reach an NTP server will have incorrect time, which can affect TLS certificate validation and call detail record accuracy.

• [ ] Features configured. BLF keys, speed dials, call park buttons, shared lines, paging groups — whatever was specified in the deployment plan should be verified on each phone.

Test calls

This is where you find out if everything actually works together.

• [ ] Internal call (extension to extension). Two phones on your network calling each other. Audio should be clear in both directions. This tests your LAN and your provider's call routing.

• [ ] External call (outbound to mobile). Call a mobile phone. Verify audio quality, caller ID display, and that DTMF tones work (press options on a voicemail system or automated attendant).

• [ ] External call (inbound from mobile). Call into your main number from a mobile phone. Verify the auto-attendant or receptionist answers, the call routes correctly, and audio is clear.

• [ ] Call transfer (blind and attended). Transfer a call to another extension both ways. A failed transfer during testing is a configuration fix. A failed transfer during a client call is an embarrassment.

• [ ] Hold and resume. Place a call on hold, verify hold music plays for the other party, resume the call. Hold failures are a common SIP interoperability issue.

• [ ] Conference call. Initiate a three-way call. Verify all parties can hear each other.

• [ ] Voicemail. Call an extension that does not answer and verify the call reaches voicemail. Leave a message and verify the notification (email, phone indicator) works.

Number porting readiness

If you are porting numbers, you have a hard cutover date that cannot be easily reversed.

• [ ] FOC (Firm Order Commitment) confirmed. You have a confirmed date from the losing carrier. The port will happen on that date whether you are ready or not.

• [ ] Temporary numbers tested. Before the port, test everything using the temporary numbers your new provider assigned. Every issue you find and fix before porting day is one less thing that can go wrong during the cutover.

• [ ] Porting day plan documented. Who will be on-site? Who is the contact at the new provider? What is the rollback plan if the port fails? Document this before go-live day, not during it.

Monitoring

You need to know when something breaks, ideally before users tell you.

• [ ] Registration monitoring active. Your monitoring system should alert if any phone loses registration.

• [ ] Quality metrics being collected. RTCP reports, call quality scores, or endpoint statistics should be flowing to your monitoring platform. Verify that data is actually arriving and that dashboards show current information.

• [ ] Alert contacts verified. Whoever receives alerts should confirm they are getting test notifications. An alerting system that silently fails to deliver alerts is worse than no alerting at all.

Every item on this checklist is something that has gone wrong in a real VoIP deployment. Working through it systematically before go-live does not guarantee a perfect launch, but it eliminates the categories of problems that are preventable, predictable, and embarrassing. The problems you cannot prevent — ISP outages, provider issues, edge cases in call routing — are hard enough to deal with without also fighting configuration mistakes you could have caught the week before.