The Network Is the Platform
Every Webex Calling article on this site eventually points back to the network. That’s not an accident. The cloud PBX, the licenses, the dial plan, the auto attendants — none of it matters if the network isn’t built to carry voice reliably. Webex Calling runs on Cisco’s infrastructure, but it runs over your network to get there. What happens between the endpoint and the Webex cloud is your responsibility, and it’s where most deployments quietly fail.
This article is the Webex-specific companion to the QoS for VoIP — How to Actually Configure It End to End guide. That article covers QoS principles and configuration from a platform-agnostic perspective. This one covers exactly what Webex Calling requires at the network layer — the specific port ranges, DSCP values, domain requirements, firewall behavior, and split tunneling configuration that determine whether your Webex deployment works properly in production.
For Teams-specific network requirements, see Teams Calling QoS — Network Requirements for Production Voice Quality.
Voice Quality Thresholds
Before any configuration, establish the baseline network requirements that Webex Calling needs to deliver acceptable voice quality. These thresholds apply to the path between every endpoint and Cisco’s media nodes — measure them from the actual network locations where devices will be deployed, not from a test machine on the core network.
| Metric | Requirement | Why It Matters |
|---|---|---|
| One-way latency | Under 150ms | Above 150ms callers perceive noticeable delay; above 300ms conversations become difficult |
| Jitter | Under 30ms | Jitter causes uneven audio playout — voice sounds choppy or robotic |
| Packet loss | Under 1% | Voice codecs don’t retransmit lost packets; any loss degrades audio quality directly |
| MOS score | 4.0 or above | Mean Opinion Score below 4.0 produces complaints; below 3.5 is unacceptable for business use |
These are not Webex-specific thresholds — they’re the industry standard for any VoIP deployment. What is Webex-specific is where to measure them. Cisco’s media nodes are distributed globally and Webex Calling endpoints connect to the nearest regional node. A circuit that tests fine to a general internet endpoint may perform differently to Cisco’s media infrastructure. Use Cisco’s CScan tool — available at cscan.webex.com — to test connectivity and media quality directly against Webex’s infrastructure from the actual network being deployed.
Transport Protocol — UDP Is Non-Negotiable
For Webex Calling, UDP is Cisco’s preferred transport protocol for media, and Cisco recommends using only SRTP over UDP. TCP and TLS as transport protocols for media are not supported for Webex Calling in production environments. The connection-oriented nature of these protocols affects media quality over lossy networks.
This is a harder requirement for Webex Calling than for general Webex services. Webex meetings and messaging can fall back to TCP or TLS for media if UDP is blocked — the experience degrades but the service works. Webex Calling cannot. A firewall that blocks UDP media traffic does not produce a fallback — it produces call failures.
Any firewall policy that inspects, restricts, or blocks UDP traffic in the relevant port ranges will break Webex Calling. This is not negotiable and it is not a configuration that can be worked around at the application layer.
Firewall Port Requirements
Webex Calling uses a combination of HTTPS for signaling and SRTP over UDP for media. The firewall must allow both categories of traffic outbound to Cisco’s infrastructure.
Signaling Ports
| Traffic Type | Protocol | Port | Direction |
|---|---|---|---|
| HTTPS — Control Hub, provisioning, device activation | TCP | 443 | Outbound |
| SIP signaling — Webex App and devices | TCP/TLS | 5062 | Outbound |
| SIP signaling — alternative | TCP | 8934 | Outbound |
| DNS | UDP/TCP | 53 | Outbound |
| NTP | UDP | 123 | Outbound |
Media Ports
| Traffic Type | Protocol | Port Range | Direction |
|---|---|---|---|
| SRTP media — primary | UDP | 5004 | Outbound |
| SRTP media — Webex App and devices | UDP | 19560–65535 | Outbound |
| SRTP media — alternative | UDP | 9000 | Outbound |
Once the call session is established, Webex clients use a Secure RTP connection for sending call media traffic via UDP port 5004 and the range 19560–65535.
The media port range 19560–65535 is broad by design. Webex Calling endpoints use dynamically assigned ports within this range for media streams. Attempting to restrict this range to a subset of ports will cause intermittent media failures that are difficult to diagnose — some calls will work and others won’t depending on which ports were dynamically assigned.
Local Gateway Additional Requirements
For Local Gateway deployments, additional ports are required for the SBC-to-Webex signaling and media path:
| Traffic Type | Protocol | Port | Direction |
|---|---|---|---|
| SIP/TLS — Local Gateway to Webex | TCP/TLS | 5061 | Outbound |
| SRTP media — Local Gateway | UDP | Configurable via rtp-port range | Outbound |
The Local Gateway’s Webex Calling-facing interface must have a direct path to Cisco’s infrastructure. When deployed behind a firewall, suitable rules must be configured to allow TLS SIP signaling and UDP/SRTP media to pass between the Local Gateway and the internet. The full Local Gateway design framework is covered in PSTN Options in Webex Calling.
Domain and URL Requirements
HTTPS signaling session establishment for Webex Calling and Webex Aware services is based on URLs rather than IP addresses. Network firewalls and proxies must allow access to domains and URLs, not just IP ranges.
This is a critical operational point. Firewall rules based on IP address ranges alone are insufficient for Webex Calling signaling — Cisco’s infrastructure uses dynamic IP addressing and the IP addresses behind these domains change. URL-based or FQDN-based firewall rules are required for the signaling path.
The core domains that must be allowed outbound:
| Domain | Purpose |
|---|---|
*.webex.com | All Webex Calling services, Control Hub, signaling |
*.cisco.com | Cisco infrastructure, device provisioning, firmware |
*.ciscospark.com | Legacy Webex infrastructure still in use |
*.wbx2.com | Webex media services |
*.cloudfront.net | Content delivery for Webex services |
*.amazonaws.com | AWS-hosted Webex infrastructure components |
The * wildcard is required — subdomain structures within these domains change as Cisco updates its infrastructure. Attempting to enumerate specific subdomains rather than using wildcard rules creates a maintenance burden and produces intermittent failures when Cisco changes subdomain routing.
Always reference Cisco’s current Port Reference Information documentation at help.webex.com for the complete and up-to-date domain list. The table above covers the primary domains but Cisco’s documentation is authoritative and reflects any changes to their infrastructure.
SIP ALG — Disable It
If a router or firewall is SIP Aware, meaning it has SIP Application Layer Gateway (ALG) or something similar enabled, turn it off. Although all Webex Calling traffic is encrypted, certain SIP ALG implementations cause issues with firewall traversal that break the service.
SIP ALG attempts to inspect and modify SIP traffic as it passes through the firewall. For Webex Calling, which uses encrypted SIP/TLS, the ALG cannot actually inspect the content — but it can still corrupt the packet structure in ways that break signaling. Call setup failures, one-way audio, and registration drops that appear intermittent and are difficult to reproduce are frequently caused by SIP ALG on a firewall or router that’s nominally transparent.
Disable SIP ALG on every firewall, router, and UTM appliance in the traffic path between Webex endpoints and the internet. Check both the WAN-facing edge device and any internal segmentation firewalls. Consumer-grade and SMB-grade routers frequently have SIP ALG enabled by default and the setting is sometimes hidden in advanced or VoIP-specific menus.
NAT Configuration
Webex Calling works correctly behind NAT. Most deployments use private IP addressing internally with NAT at the internet edge, and Webex Calling handles this natively. A few NAT-specific configuration points that affect Webex Calling behavior:
Configure a minimum NAT timeout to ensure proper operation of devices. Cisco phones send a follow-up REGISTER refresh message every 1–2 minutes. If your network implements NAT or SPI, set a larger timeout of at least 30 minutes for the connections. This allows reliable connectivity while reducing battery consumption on mobile devices.
NAT timeouts that are too short cause phone registrations to drop silently. The phone thinks it’s registered, the Webex cloud thinks it’s registered, but the NAT binding has expired and inbound calls can’t reach the device. Phones that don’t ring for incoming calls in a NAT environment are frequently experiencing this problem.
Port exhaustion is the other NAT consideration for larger deployments. Validate the NAT pool size required for app or device connectivity when multiple users and devices access Webex Calling services using NAT or PAT. Ensure that adequate public IP addresses are assigned to the NAT pools to prevent port exhaustion. Port exhaustion causes internal users and devices to be unable to connect to Webex Calling services.
Each active call consumes multiple UDP port bindings on the NAT device. A deployment with 200 concurrent calls will consume significantly more NAT port bindings than a deployment with 10. Size the NAT pool and verify the NAT device’s session table capacity against expected peak concurrent call volume before go-live.
QoS Configuration for Webex Calling
QoS for Webex Calling follows the same DSCP marking principles as any VoIP deployment, with Webex-specific port ranges that enable differentiated marking for audio versus video traffic. The full QoS configuration framework — queuing policies, trust boundaries, WAN enforcement — is covered in QoS for VoIP — How to Actually Configure It End to End. This section covers the Webex-specific values and settings.
DSCP Marking Values
| Traffic Type | DSCP Value | DSCP Name | Notes |
|---|---|---|---|
| Voice media (audio) | 46 | EF (Expedited Forwarding) | Highest priority — audio RTP |
| Video media | 34 | AF41 | Second priority — video RTP |
| Signaling | 24 | CS3 | SIP/HTTPS signaling |
| Call control | 24 | CS3 | Same as signaling |
These are Cisco’s recommended values for Webex Calling and align with the industry-standard DSCP recommendations in RFC 4594. The recommended values can be modified if necessary but EF for audio and AF41 for video are the right defaults for production deployments.
Source Port Differentiation — Windows Clients
Marking audio and video traffic with different DSCP values requires being able to identify which media stream is audio and which is video. On Webex App for Windows, this is not automatic without additional configuration. By default, audio and video use overlapping source port ranges, making them indistinguishable for DSCP marking at the network layer.
Without enabling source port differentiation, you cannot differentiate between audio and video/share using Windows QoS Policies (GPO) because the source ports are the same for audio, video, and share.
To enable differentiated DSCP marking on Windows endpoints:
- Enable dedicated media source port ranges in the Webex App — this requires contacting Cisco’s account team to enable the feature for your organization
- Once enabled, the Webex App uses dedicated port ranges: audio on 52,000–52,049 and video on 52,100–52,199
- Configure Windows Group Policy (GPO) to apply DSCP 46 to traffic on the audio port range and DSCP 34 to traffic on the video port range
For macOS and mobile clients, DSCP marking is applied by the application itself and does not require the additional GPO configuration.
Control Hub QoS Setting
The QoS setting in Control Hub — found under Calling > Settings > Quality of Service — enables DSCP marking from Webex devices. Enable it. Leaving it disabled means Cisco IP phones and Webex Devices won’t mark their own traffic, regardless of what your network QoS policy does.
SSL Inspection — Bypass for Webex Traffic
SSL inspection — also called TLS inspection, HTTPS inspection, or deep packet inspection — decrypts, inspects, and re-encrypts HTTPS traffic at a proxy or next-generation firewall. It’s a legitimate security control for general web traffic. It breaks Webex Calling.
The problem is certificate validation. Webex Calling endpoints validate Cisco’s certificates as part of the SIP/TLS and HTTPS signaling process. When SSL inspection is in the path, the endpoint sees the firewall’s certificate instead of Cisco’s certificate. Webex Calling treats this as a man-in-the-middle condition and either refuses the connection or behaves unpredictably.
The symptoms of SSL inspection affecting Webex Calling are inconsistent and frustrating to diagnose: devices that fail to provision, phones that register then immediately drop, Control Hub access that works from some machines and not others, and intermittent call setup failures with no obvious pattern. All of these can be caused by SSL inspection touching Webex traffic.
The fix is straightforward: create an SSL inspection bypass rule for the Webex domains listed in the Domain Requirements section above. All traffic to *.webex.com, *.cisco.com, *.ciscospark.com, and the other required domains should be excluded from SSL inspection and allowed to pass through without decryption.
This is not a security trade-off — Webex Calling traffic is already encrypted end-to-end by Cisco. SSL inspection of Webex traffic provides no security value while actively breaking the service.
Split Tunneling for Remote and Hybrid Workers
For organizations where users connect through a corporate VPN, split tunneling is the difference between acceptable call quality and persistent audio problems for remote workers.
Without split tunneling, all traffic — including Webex Calling media — routes through the VPN tunnel to the corporate network, then back out to the internet to reach Cisco’s infrastructure. This adds latency from the double traversal, introduces jitter from the VPN encapsulation overhead, and puts Webex media through a path that wasn’t designed for real-time traffic. The result is audio quality degradation that persists regardless of the underlying internet circuit quality.
With split tunneling, Webex Calling traffic bypasses the VPN tunnel entirely and routes directly from the endpoint to Cisco’s infrastructure over the local internet connection. Signaling and media take the shortest available path to Cisco’s media nodes, and the VPN tunnel carries only the corporate traffic it was designed to carry.
Configuring Split Tunneling
Split tunneling configuration depends on your VPN platform, but the approach is consistent: exclude Webex Calling domains and IP ranges from the VPN tunnel so they route locally rather than through the corporate network.
The recommended approach is domain-based split tunneling, excluding:
*.webex.com*.cisco.com*.ciscospark.com*.wbx2.com
IP-based split tunneling is an alternative for firewalls or VPN platforms that don’t support domain-based rules. Cisco publishes IP subnet ranges for Webex media services in their Port Reference Information documentation. These ranges should be excluded from the VPN tunnel.
For Cisco AnyConnect and Secure Client, split tunneling is configured through the VPN profile’s split tunneling policy — set the policy to exclude the Webex domains or subnets from tunneling. For other VPN platforms, consult the vendor documentation for split tunnel exclusion configuration.
A note on security: split tunneling for Webex traffic is accepted practice and does not meaningfully reduce security posture. Webex Calling traffic is encrypted end-to-end by Cisco — routing it through the corporate network and back out does not add a security layer, it adds latency.
MTU and Fragmentation
Webex Calling is sensitive to packet fragmentation. Fragmented packets cause audio glitches and intermittent call quality issues that appear to be bandwidth or jitter problems but are actually MTU-related.
The standard Ethernet MTU is 1500 bytes. VPN tunnels reduce the effective MTU by the size of the tunnel header — IPsec overhead is typically 50–73 bytes, reducing effective MTU to around 1427–1450 bytes. If endpoints are sending Webex media packets at the standard 1500-byte MTU through a VPN tunnel with a lower effective MTU, packets will be fragmented.
Configure MTU on endpoints and network devices to match the effective MTU of the path to Cisco’s infrastructure. For VPN users, this typically means setting the endpoint MTU to 1350–1400 bytes to provide headroom for VPN overhead. Verify the actual effective MTU of your path using ping with the don’t-fragment bit set and the packet size set to your expected MTU value.
CScan — Cisco’s Network Readiness Tool
Cisco provides CScan (cscan.webex.com) as a browser-based network readiness tool that tests connectivity and media path quality directly against Webex’s infrastructure. Run CScan from every network location where Webex Calling will be deployed before go-live.
A correctly configured firewall is essential for a successful Webex Calling deployment. Run your CScan test from the same network that you will use your Webex Calling services to get optimal results.
CScan tests port connectivity, media path quality, and basic network readiness. It does not test everything — QoS enforcement, VPN behavior, and SIP ALG configuration require manual verification. But it catches the most common firewall and connectivity issues before they manifest as go-live problems.
Run CScan:
- From the corporate LAN before deploying any devices
- From the wireless network if Webex App users will be on Wi-Fi
- From a remote worker’s home network if remote deployment is in scope
- After any firewall change that affects the port ranges or domains above
CScan results are saveable and shareable — document them as part of the pre-deployment validation record.
Common Network Failures in Webex Calling Deployments
SIP ALG enabled on the firewall or router. The most common cause of intermittent registration drops and one-way audio in new deployments. Check every device in the traffic path, not just the edge firewall.
UDP media ports blocked. A firewall policy that allows TCP 443 but blocks UDP in the media ranges will pass connectivity tests and fail on actual calls. Test media path connectivity explicitly, not just HTTPS signaling.
SSL inspection not bypassed. Produces provisioning failures, intermittent call setup failures, and Control Hub access issues that correlate with which machines have the SSL inspection root certificate installed. Bypass Webex domains at the inspection appliance.
VPN without split tunneling. Produces persistent audio quality degradation for all remote workers. Affects every call, not intermittently. Usually identified when users report that call quality is consistently worse from home than from the office.
Short NAT timeouts. Produces phones that register on boot then stop receiving inbound calls after 5–10 minutes. The registration appears successful from both the phone and Control Hub, but inbound calls don’t ring. Extend the NAT binding timeout to at least 30 minutes.
QoS not configured. Produces variable call quality that correlates with network load — calls are fine when the network is lightly loaded and degrade during peak usage. Easy to mistake for a bandwidth problem when the actual fix is queue prioritization.
MTU mismatch for VPN users. Produces audio glitches that appear to be jitter but don’t correlate with measured jitter values. The audio artifact is consistent — a periodic stutter at regular intervals — rather than the random quality variation that characterizes true jitter.
Final Thoughts
The network requirements for Webex Calling are not extraordinary — they’re the same requirements that any production VoIP deployment has had for the past fifteen years. What changes with cloud calling is that the traffic path now traverses the public internet to reach Cisco’s infrastructure, which means the firewall policy, the NAT configuration, the VPN split tunnel, and the QoS enforcement all have to be correct in ways they didn’t have to be when the PBX was on-premises.
Get these right before you provision the first user and the deployment works. Miss one of them and you spend the post-go-live period chasing an audio quality problem that looks different from every angle but has the same root cause.
The QoS for VoIP — How to Actually Configure It End to End article covers the network-layer QoS configuration in full. The Webex Calling Cloud Deployment — Full Setup Walkthrough (Part 1) and Part 2 cover the platform-side configuration that sits on top of the network foundation built here.