Network Readiness Assessment for UCaaS — What to Check Before You Deploy

Every UCaaS deployment has a go-live moment where the phones ring for the first time in production. What happens in that moment — clean cutover or a cascade of tickets — is largely determined by what you did on the network before the deployment started.

This article is the pre-deployment network readiness checklist for Microsoft Teams Calling and Cisco Webex Calling deployments. Work through each category before go-live. Find the problems now, not when the front desk is on the phone.

Each section covers what to verify and why it matters. Platform-specific requirements are called out where Teams and Webex differ. The consolidated printable checklists for each platform are available as free downloads at the end.

DNS

DNS is the first thing that needs to work and the last thing most people check. If endpoints can’t resolve Microsoft or Cisco cloud infrastructure, nothing else matters — calls fail before a single SIP packet leaves the building.

What to verify:

Confirm that your internal DNS servers can resolve the platform domains your deployment depends on. Run these tests from a domain-joined machine on the voice VLAN using internal DNS — not from your own workstation, not from a machine that might be using a different DNS server.

Microsoft Teams:

Resolve-DnsName teams.microsoft.com
Resolve-DnsName login.microsoftonline.com
Resolve-DnsName outlook.office365.com
Resolve-DnsName *.skype.com

Cisco Webex:

Resolve-DnsName webex.com
Resolve-DnsName wbx2.com
Resolve-DnsName ciscospark.com
Resolve-DnsName broadworks.net

Every query should return IP addresses with a reasonable TTL. A timeout means your forwarder chain is broken. An NXDOMAIN means the domain is being blocked by a DNS policy or RPZ rule.

Also verify the DNS server assigned by DHCP on the voice VLAN is actually your internal DNS server — not a public resolver that was left in scope options from a previous configuration.

Teams DNS checklist:

TCP/UDP 53 outbound permitted from DNS servers to forwarders
Forwarders configured and reachable on all internal DNS servers
teams.microsoft.com resolves correctly from voice VLAN
login.microsoftonline.com resolves correctly from voice VLAN
No RPZ or DNS filtering rules blocking Microsoft 365 domains
DNS server assigned by voice DHCP scope is correct

Webex DNS checklist:

TCP/UDP 53 outbound permitted from DNS servers to forwarders
Forwarders configured and reachable on all internal DNS servers
webex.com and wbx2.com resolve correctly from voice VLAN
ciscospark.com resolves correctly from voice VLAN
No RPZ or DNS filtering rules blocking Webex domains
DNS server assigned by voice DHCP scope is correct

DHCP

DHCP problems surface immediately at go-live — phones that don’t register, endpoints that get APIPA addresses, IP conflicts on the voice VLAN. All of it is preventable with a five-minute scope check before deployment.

What to verify:

Check scope utilization on your voice VLAN DHCP scope. A scope that’s already at 60–70% utilization before you add phones is going to exhaust mid-deployment. Check that your gateway and DNS options are correct for the voice scope specifically — voice scopes often have different options than data scopes and mistakes here are easy to make.

Verify the IP helper address on the voice VLAN SVI is pointing to the correct DHCP server. Then test it — connect a test device to the voice VLAN and confirm it receives an address, the correct gateway, and the correct DNS server.

Teams DHCP checklist:

Voice VLAN scope utilization below 60%
Correct gateway IP configured in scope options (Router option)
Correct DNS server configured in scope options
Lease time set appropriately for voice endpoints (1 day recommended)
IP helper address on voice SVI pointing to correct DHCP server
Test device on voice VLAN receives correct IP, gateway, and DNS
Excluded addresses cover all static assignments at low end of range
DHCP failover configured if single server is a concern

Webex DHCP checklist:

Voice VLAN scope utilization below 60%
Correct gateway IP configured in scope options
Correct DNS server configured in scope options
Option 66 configured if physical Webex desk phones require TFTP provisioning
Lease time set appropriately for voice endpoints (1 day recommended)
IP helper address on voice SVI pointing to correct DHCP server
Test device on voice VLAN receives correct IP, gateway, and DNS
Excluded addresses cover all static assignments at low end of range

VLAN Segmentation

Voice endpoints on the wrong VLAN, or no voice VLAN at all, is one of the most common pre-deployment gaps. A flat network where voice shares a VLAN with workstations has no QoS enforcement boundary and no broadcast domain isolation — call quality problems are predictable.

What to verify:

Confirm the voice VLAN exists and is consistent across all switches in the deployment. VLAN IDs should be identical at every site — VLAN 20 for voice everywhere, not VLAN 20 at HQ and VLAN 100 at the branch. Inconsistent VLAN IDs between sites create trunk configuration problems and make documentation unreliable.

Verify that access ports serving IP phones are configured with the correct voice VLAN. Connect a phone and confirm it registers on VLAN 20, not VLAN 10 or VLAN 1. Check that trunk ports between switches have VLAN 20 in the allowed list — a missing VLAN on a trunk is a silent failure that only shows up when a phone on a downstream switch can’t register.

Verify the SVI for the voice VLAN is up and has the correct IP address. The SVI is the default gateway for voice endpoints — if it’s shut down or misconfigured, no phone on that VLAN can reach anything outside the local segment.

Teams VLAN checklist:

Voice VLAN created and consistent across all switches
Access ports for IP phones configured with correct voice VLAN
Softphone workstations remain on data VLAN — not voice VLAN
Trunk ports have voice VLAN in allowed list
Voice VLAN SVI is up with correct IP and subnet mask
IP helper address on voice SVI configured for DHCP relay
Native VLAN on trunk ports is not VLAN 1
Test phone registers on correct VLAN and receives correct IP

Webex VLAN checklist:

Voice VLAN created and consistent across all switches
Access ports for Webex desk phones configured with correct voice VLAN
Softphone workstations remain on data VLAN
Trunk ports have voice VLAN in allowed list
Voice VLAN SVI is up with correct IP and subnet mask
IP helper address on voice SVI configured for DHCP relay
Native VLAN on trunk ports is not VLAN 1
Test Webex device registers on correct VLAN and receives correct IP

QoS and Firewall

These two categories share a section because they’re the most common source of go-live failures and they’re often misconfigured together. A correctly segmented voice VLAN with no QoS marking and a firewall that’s blocking return UDP is the most common pre-deploy gap combination.

QoS — What to verify:

Confirm DSCP marking is configured at the access layer for voice traffic. Voice RTP should be marked DSCP EF (46). Signaling should be marked DSCP CS3 (24). Verify that the marking is being applied — connect a test phone and run a test call, then capture traffic on the uplink and confirm DSCP values in the IP headers.

Verify that QoS policy is consistent end to end — marking at the access layer is only useful if the upstream switches and WAN edge are configured to honor those markings and apply appropriate queuing. A phone that marks traffic EF but hits a router that re-marks everything to best effort is no better than no QoS at all.

Firewall — What to verify:

Confirm the firewall has the correct port rules for your platform before go-live, not during. Check that UDP port ranges are permitted in both directions — outbound from the voice VLAN to the platform’s IP ranges, and inbound return traffic from the platform back to the voice VLAN. Verify SSL inspection and DPI are bypassed for platform traffic. Verify proxy bypass rules are in place if a proxy exists on the network.

Run a test call and check the firewall logs during the call — dropped packets during active RTP streams will show up as denied entries. If you see denies, address them before go-live.

Teams QoS and Firewall checklist:

DSCP EF (46) marking configured for RTP on access layer
DSCP CS3 (24) marking configured for signaling
QoS policy honors DSCP markings end to end to WAN edge
TCP 443 outbound permitted to *.teams.microsoft.com and *.skype.com
UDP 3478–3481 outbound permitted to Microsoft 365 IP ranges
UDP 50000–50059 outbound permitted to Microsoft 365 IP ranges
Return UDP permitted inbound from Microsoft 365 IP ranges
SSL/TLS inspection bypassed for Microsoft 365 domains
Proxy bypass configured for Microsoft 365 domains
DPI disabled or bypassed for Teams traffic
No denied entries in firewall logs during test call

Webex QoS and Firewall checklist:

DSCP EF (46) marking configured for RTP on access layer
DSCP CS3 (24) marking configured for signaling
QoS policy honors DSCP markings end to end to WAN edge
TCP 443 outbound permitted to *.webex.com, *.ciscospark.com, *.wbx2.com
TCP/TLS 5060/5061 outbound permitted to *.broadworks.net
UDP 5004 and 8000–8100 outbound permitted to Webex media infrastructure
Return UDP permitted inbound from Webex IP ranges
SSL/TLS inspection bypassed for Webex domains
Proxy bypass configured for Webex domains
DPI disabled or bypassed for Webex traffic
No denied entries in firewall logs during test call

Bandwidth

Bandwidth planning is a conditional check. For most general office deployments on a mid-tier business internet circuit, available bandwidth is not a constraint — a 100 Mbps circuit handles far more concurrent calls than a typical office generates. Where bandwidth becomes a go-live risk is at two ends of the spectrum: large enterprise deployments with high concurrent call volume, and small budget-constrained clients on entry-level circuits that were sized for web browsing, not real-time media.

If your deployment doesn’t fall into either of those categories, this section is a quick confirmation rather than a detailed calculation.

What to verify:

For standard deployments, confirm the WAN circuit speed and verify current utilization during business hours before adding voice load. If the circuit is already running at 60–70% during peak hours, voice traffic will compete for bandwidth even if the raw numbers look sufficient.

For deployments where bandwidth is a real constraint, run the calculation before go-live. The VoIP Bandwidth Calculator gives you per-site requirements based on codec and concurrent call count. If the required voice bandwidth plus current data utilization exceeds 80% of circuit capacity, you have a problem to solve before go-live — not after.

Teams bandwidth checklist:

WAN circuit speed confirmed and documented
Current peak utilization measured during business hours
Concurrent call estimate calculated for site user count
Required voice bandwidth confirmed to fit within available headroom
QoS policy in place to protect voice bandwidth from data traffic during congestion
Secondary circuit or failover path confirmed if primary circuit is bandwidth-constrained

Webex bandwidth checklist:

WAN circuit speed confirmed and documented
Current peak utilization measured during business hours
Concurrent call estimate calculated for site user count
Required voice bandwidth confirmed to fit within available headroom
QoS policy in place to protect voice bandwidth from data traffic during congestion
Secondary circuit or failover path confirmed if primary circuit is bandwidth-constrained

Split Tunneling

This check only applies to deployments where remote workers will be using the UCaaS platform over a corporate VPN. If your deployment is office-only with no VPN users, skip this section.

What to verify:

Confirm that Teams or Webex traffic is excluded from the VPN tunnel for remote users. Connect a test machine to the VPN and run a traceroute to a known Microsoft 365 or Webex IP — the first hop should be the local gateway, not the VPN concentrator. If the first hop is the VPN concentrator, traffic is still tunneling and voice quality will degrade.

Verify that DNS for Microsoft 365 and Webex domains resolves via public DNS from the VPN client — not through the corporate DNS tunnel. Check the routing table on the VPN client to confirm Microsoft 365 and Webex IP ranges are not in the tunnel route list.

Teams split tunneling checklist:

Split tunnel exclusions configured for Microsoft 365 Optimize IP ranges
*.teams.microsoft.com and *.skype.com excluded from tunnel
Traceroute from VPN client to 13.107.64.1 first hop is local gateway
DNS for Microsoft 365 domains resolves via public DNS on VPN client
Split tunnel config applied to all VPN group policies used by calling users
Test call from VPN client produces acceptable audio quality

Webex split tunneling checklist:

Split tunnel exclusions configured for Webex IP ranges and domains
*.webex.com, *.ciscospark.com, *.wbx2.com excluded from tunnel
Traceroute from VPN client to Webex IP first hop is local gateway
DNS for Webex domains resolves via public DNS on VPN client
Split tunnel config applied to all VPN group policies used by calling users
Test call from VPN client produces acceptable audio quality

Go-Live Readiness — The Final Check

Before you cut over, run a test call that exercises the full production path. Not a call between two internal test extensions — a real call out to the PSTN and back, from the voice VLAN, through the production firewall, over the production WAN circuit. Both parties should have clear audio in both directions. The call should hold for at least two minutes without degradation or unexpected termination.

If anything in that test call doesn’t pass — one-way audio, choppy quality, unexpected drop — go back to the relevant section above. The checklist told you what to verify. The test call tells you whether it’s actually working.

Don’t sign off on a deployment until that test passes cleanly. The front desk will find out if you do.

Downloadable Checklists

The consolidated printable versions of both checklists — one for Microsoft Teams Calling, one for Cisco Webex Calling — are available as free downloads at systemstackhq.com/tools.

The Full Networking Pillar

This article is the capstone of the SystemStackHQ Networking pillar. Every check in this assessment has a full article behind it: