Network Requirements
What your network needs in order to run the phone system cleanly. Use this as a checklist before your phones go live, not as a reactive troubleshooting manual. If calls are already going wrong, start with Basic Troubleshooting.
This guide covers both kinds of phone:
- Softphones: the browser-based softphone and the mobile softphone app
- Desk phones and DECT bases supplied with your phone service
It is safe to share directly with whoever runs your network (an internal IT lead or a managed-service provider). Most of the settings below are on your router and firewall, so that person is usually the one who will check them.
The short version
Most small-business networks already meet every requirement here out of the box. If you have a normal business internet connection and a router that has not been heavily locked down, voice will almost certainly work on day one. The handful of things worth confirming in advance:
- Bandwidth is rarely the issue. A voice call uses about 100 kbps per direction. Even a busy office is well under a few Mbps of voice. What matters is whether that bandwidth is stable, not how much there is.
- Turn off SIP ALG on the router if it is present. It is the single most common cause of strange voice problems.
- Avoid double NAT (your router plugged in behind another router that is also doing NAT).
- Allow the outbound ports in the Ports and destinations table. Most routers already do.
- Prefer wired Ethernet for desk phones and 5 GHz Wi-Fi for everything else.
- Run one network test from your office before the phones go live (see Validate before go-live).
The rest of this guide is the detail behind those six points.
Bandwidth
A single voice call uses very little bandwidth, whether it is on a softphone or a desk phone:
- Softphones and desk phones both use G.711: roughly 80 to 100 kbps per direction including overhead.
The table below is sized at 100 kbps per call, so it is safe for either kind of phone:
| Concurrent calls | Approx. bandwidth (each direction) |
|---|---|
| 1 | 100 kbps |
| 5 | 500 kbps |
| 10 | 1 Mbps |
| 25 | 2.5 Mbps |
In practice, modern internet connections have plenty of headroom for voice. Bandwidth is rarely the cause of a problem; how the bandwidth is shared with other traffic is what matters. A 100 Mbps line saturated by a large upload at the wrong moment can still break a call. That is what Quality of Service addresses.
Network quality thresholds
Voice is sensitive to the quality of a connection, not just its speed. Three metrics matter:
| Metric | Good | Acceptable | Problematic |
|---|---|---|---|
| Jitter | Below 20 ms | Below 30 ms | Above 30 ms |
| Packet loss | Below 0.5% | Below 1% | Above 1% |
| Round-trip latency | Below 100 ms | Below 150 ms | Above 200 ms |
These are industry-standard thresholds for VoIP. If a connection consistently sits outside the "Acceptable" column, voice quality will suffer on any phone system, so it is worth measuring before your phones go live rather than after the first complaint. The Validate before go-live section explains how to measure them.
Once the system is live, the admin portal's Call Quality dashboard reports the same metrics (Avg. MOS, jitter, packet loss) per call, so you have a numbers-based record of how your network is actually performing.
Ports and destinations
Your firewall needs to allow outbound traffic on the ports below. No inbound port-forwarding rules are required; the phones keep the connection open from their side.
Most firewalls allow all of this outbound already, so there is usually nothing to add. If yours only allows outbound traffic to specific destinations, contact support for the exact hostnames to allowlist. Only the desk phone signalling servers (SIP, ports 5060 and 5061) have fixed addresses suitable for allowlisting. The other destinations in the table use addresses that change over time, so allow those ports to any destination (see the notes below the table).
| Protocol | Port | Used by | Purpose |
|---|---|---|---|
| SIP (UDP/TCP) | 5060 | SIP devices | Desk phone and DECT signalling |
| SIP (TLS) | 5061 | SIP devices using TLS | Encrypted desk phone and DECT signalling |
| RTP/SRTP (UDP) | 10000–20000 | SIP devices | Desk phone and DECT audio (SRTP when the device uses TLS) |
| HTTPS (TCP) | 443 | SIP devices | Automatic provisioning |
| WSS (TCP) | 443 | WebRTC | Signalling WebSocket |
| HTTPS (TCP) | 443 | WebRTC | API calls, such as fetching the media relay servers |
| STUN (UDP) | 3478 | WebRTC | NAT type discovery |
| TURN (UDP/TCP) | 3478 | WebRTC | Media relay |
| TURN (TCP) | 443 | WebRTC | Media relay (firewall fallback) |
"SIP devices" are desk phones and DECT bases; "WebRTC" is the browser and mobile softphones.
About the softphone media relay servers: softphones are handed their STUN/TURN relay servers, with short-lived credentials, each time they connect. The relay hostnames and addresses are chosen at that moment, change over time and are not published, so they can't be allowlisted. Allow outbound UDP and TCP on port 3478, and TCP on 443, to any destination. A firewall that only allows general outbound HTTPS (TCP 443 to any destination) is enough on its own: softphone calls then relay over TCP 443. That relay is plain TURN over TCP, not TLS (the media itself is always encrypted), so a firewall that inspects TCP 443 and blocks anything that isn't TLS will block it.
About the RTP media destinations: desk phone audio flows directly to the platform's media servers, whose addresses are supplied per call and are not fixed. The simplest rule, and the recommended one, is to allow outbound UDP on ports 10000–20000 to any destination; an RTP stream is useless anywhere else, so this carries no practical risk. If your network cannot allow "any destination", contact support for the address ranges to scope the rule to.
The two kinds of phone reach the network differently, which is worth understanding when allowlisting:
- Softphones always signal over TCP 443 (the standard HTTPS port) and prefer UDP for audio, falling back to a relay over TCP 443 when UDP is blocked. On a firewall that only permits TCP 443 outbound, softphone calls still work, with slightly higher latency, unless the firewall also blocks non-TLS traffic on 443 (see the note on media relay servers above). See Softphones: specifics.
- Desk phones and DECT bases signal over SIP (UDP or TCP on 5060, TLS on 5061) and carry audio over RTP on a range of UDP ports. They do not have the TCP 443 fallback that softphones have, so on a locked-down network their SIP and RTP traffic must be explicitly permitted. See Desk phones: specifics.
Most consumer and small-business routers allow all of this outbound by default. Problems almost always come from a deliberately locked-down enterprise firewall, an aggressive UTM appliance doing deep packet inspection, or SIP ALG (covered next).
Firewall and router configuration
Four settings cause the large majority of network-side voice problems. Confirm each before your phones go live.
Disable SIP ALG
SIP ALG (Application Layer Gateway) is a router feature that inspects and rewrites SIP traffic as it passes through. It is well-intentioned but almost always interferes with modern hosted voice, and it is the single most common source of one-way audio and registration problems on small-business networks.
Look for any setting labeled "SIP ALG", "SIP Helper", "SIP Transformation", or "VoIP passthrough" and turn it off, then reboot the router. The label varies by manufacturer.
Avoid double NAT
If your internet provider's modem also acts as a router, and your own router is plugged in behind it, traffic passes through two layers of NAT. This frequently breaks voice. Either put the modem into bridge mode so only one device does NAT, or connect the phones to the device that is doing NAT.
Leave UDP connection tracking alone
For inbound calls to reach a phone, the router has to keep its NAT mapping open between calls. The platform sends a keepalive to each phone every 20 seconds to refresh that mapping, so the router only needs to not prune the mapping faster than that. Virtually every consumer and small-business router clears this bar by default; out-of-the-box UDP connection-tracking timeouts are measured in minutes, not seconds.
The only place this becomes a problem is a deliberately tuned firewall or UTM appliance configured to prune UDP sessions on very short timers, or one running a "SIP-aware" or "VoIP-aware" inspection profile that recycles sessions on its own schedule. On those networks:
- Leave the default UDP connection-tracking timeout alone, or set it to at least 60 seconds.
- Do not add custom rules that close or recycle UDP sessions for SIP or RTP traffic on short timers.
- Disable or relax any "SIP-aware" or "VoIP-aware" inspection feature; these usually interfere more than they help.
The symptom this prevents is inbound calls not ringing on a phone that otherwise shows as connected.
No inbound port forwarding needed
Because the phones maintain the connection outbound, there is no need to open inbound ports, set up port forwarding, or place phones in a DMZ. If a previous phone system required port forwarding, those rules can be removed.
Local network and switching
Mostly relevant to desk phones, but the wired-versus-wireless guidance applies to everything.
- Power over Ethernet (PoE). Desk phones supplied with your phone service are typically powered over the network cable by a PoE switch. Confirm the switch ports the phones will use supply PoE, or plan to use the phone's separate power adapter. Some ports on a mixed switch are non-PoE.
- Wired beats wireless for desk phones. A desk phone on wired Ethernet is the most reliable setup. Use the phone's LAN port, not its PC pass-through port, for the connection to the switch.
- DHCP. Phones get their network configuration from DHCP by default. Make sure the network has DHCP available on the segment the phones are on. A phone showing an IP of 0.0.0.0 or a self-assigned address is not getting DHCP.
- Automatic provisioning. Phones supplied with your phone service provision themselves when they connect to the network and reach the internet. There is nothing to type into the phone by hand. You then assign each device to a user in the admin portal, where its status shows as "provisioned". See Devices.
- VLANs (optional). A separate voice VLAN is not required. On larger or busier networks it can help isolate voice from other traffic and is where QoS tagging is usually applied, but it is an optimization, not a requirement. If a voice VLAN is used, set the VLAN ID through the device provisioning settings in the admin portal rather than relying on phone-side auto-discovery.
- Wi-Fi. For softphones, the mobile app, and DECT, prefer 5 GHz over the more crowded 2.4 GHz band. Wi-Fi 6 handles voice better than older standards under load. Mesh systems vary; some hand off cleanly between access points mid-call and some drop the call.
Quality of Service
QoS is how a router protects voice traffic when the network is busy with other things (video conferencing, large uploads, backup software). Phones supplied with your phone service already tag their traffic by default (DSCP 46 (Expedited Forwarding) for audio and DSCP 26 (Assured Forwarding 31) for signalling), so the router only needs to honor those tags and give the voice class priority.
QoS is optional on most small-business networks, where there is enough headroom that voice never has to compete. It is worth configuring if call quality dips line up with busy periods, or on any network where voice shares a link with heavy data traffic. On a network with a dedicated voice VLAN, this is where the prioritization is usually applied.
Softphones: specifics
This covers the browser-based softphone and the mobile softphone app. They use WebRTC, which is built to work behind almost any firewall.
- Signalling is always a WebSocket over TLS (WSS) on TCP 443, indistinguishable from normal HTTPS traffic.
- Audio prefers a direct UDP path and finds the best route automatically. If UDP is blocked, it relays over TCP 443 as a last resort. That fallback adds a small amount of latency but means calls work on networks that only allow outbound TCP 443. The relay is plain TURN over TCP, not TLS, so a firewall that inspects 443 and blocks non-TLS traffic blocks it too.
- Encryption is mandatory: audio and signalling are always encrypted. There is no unencrypted path.
- NAT is handled automatically, including the strict kinds that break many older voice apps, without any configuration.
- Microphone permission. The browser must allow microphone access for the softphone. Chrome, Edge, and Firefox prompt the first time; if a user previously denied the prompt, the permission has to be re-enabled in browser settings.
Because softphones have the TCP 443 fallback, they are the most resilient option on a restrictive network, as long as that network does not block non-TLS traffic on 443. If your network cannot be opened up for desk phones, the softphone will usually still work.
Desk phones: specifics
This covers desk phones and DECT bases supplied with your phone service.
- Signalling uses SIP to the platform SIP servers (contact support for the hostnames to allowlist): over UDP or TCP on port 5060, or over TLS on port 5061 when the device uses the TLS transport.
- Encryption follows the device's SIP transport. With TLS, signalling is encrypted and audio is encrypted with SRTP. With UDP or TCP, both are unencrypted. Unlike softphones, encryption is not automatic: choose TLS for the device in the admin portal (see Devices).
- Audio uses RTP over UDP ports 10000–20000 to the media servers. Unlike softphones, desk phones do not fall back to TCP 443, so on a tightly controlled network the SIP and RTP ports in the Ports and destinations table must be explicitly permitted outbound.
- Codecs. Desk phones use G.711, the standard carrier-grade voice codec. No codec configuration is needed on the phone.
- Registration keepalives are handled automatically, on the interval described in Leave UDP connection tracking alone. Nothing needs to be set on the phone.
- Provisioning is automatic on network connection, as described in Local network and switching.
Using phones you already own, rather than ones supplied with your phone service, is out of scope for this guide; contact support before connecting them.
Validate before go-live
Two quick tests from your office confirm the network is voice-ready before the phones go live. Run both from a device on the same network and the same connection the phones will use (wired if the phones are wired, the same Wi-Fi if they are wireless).
Run a VoIP-grade network test
A regular speed test reports raw bandwidth but not whether a connection is voice-grade. For voice, the test has to measure jitter and packet loss as well.
The recommended tool is the Cloudflare speed test at speed.cloudflare.com. It is free, runs in the browser from your network, and reports jitter and latency alongside bandwidth. Let it finish, then compare the result against the Network quality thresholds. If jitter or packet loss lands in the "Problematic" column, fix the network before the phones go live.
Run a continuous ping
A speed test is a snapshot; a continuous ping shows whether the connection holds steady over a few minutes. From a computer on your network:
macOS or Linux:
ping -c 200 1.1.1.1
Windows:
ping -n 200 1.1.1.1
Let it run for two to three minutes, then look at the packet-loss percentage (should be at or near 0%) and the spread between minimum and maximum round-trip time (a large spread indicates jitter). Wild variation or dropped packets means the connection has a problem that voice calls will inherit.
Confirm E911 on a live test call
Each location's emergency address must be registered before the phones make outbound calls. Once the phones are provisioned, confirm emergency routing by dialing 933 (the test number that reads back the registered address), never 911. See Locations.
Pre-flight checklist
A one-screen version to hand to your IT contact before the phones go live.
Internet and bandwidth
- Business internet connection in place at the site
- Headroom for voice (about 100 kbps per concurrent call; effectively always true on modern connections)
Network quality (from speed.cloudflare.com)
- Jitter, packet loss and round-trip latency all within the "Acceptable" column of Network quality thresholds
Router and firewall
- SIP ALG disabled
- No double NAT (single device doing NAT, or the provider's modem in bridge mode)
- Outbound ports allowed (see Ports and destinations)
- No aggressive UDP session pruning or "SIP-aware" inspection on managed firewalls
- No inbound port forwarding needed (remove old rules if present)
Local network (desk phones)
- PoE available on the switch ports the phones will use, or power adapters on hand
- DHCP available on the phones' network segment
- Desk phones cabled to a switch (LAN port, not PC pass-through)
Wireless (softphone, mobile, DECT)
- Devices on 5 GHz where possible
Optional, busier networks
- QoS configured to prioritize voice (honor DSCP 46 for audio)
After provisioning
- Test call placed and audio is clean both directions
- 933 dialed to confirm the registered E911 address
When to contact support
Work through this guide and the two validation tests first; the large majority of network readiness is self-serve. Contact support when:
- The network tests pass (jitter, packet loss, and latency are all in range) but call quality is still poor across multiple users at the site, or
- SIP ALG is off, the firewall is permissive, double NAT is ruled out, and phones still will not register or inbound calls still will not ring.
When you do, include the network test results, the affected site and users, and what you have already tried, so the support team can pick up where you left off rather than suggesting the same steps back. The Call Quality dashboard is the place to pull per-call evidence.
Glossary
- WebRTC: The real-time voice technology behind the browser and mobile softphones. Works over HTTPS-style connections and needs no install in the browser.
- SIP: The signalling protocol desk phones use to register and place calls.
- RTP: The protocol that carries the actual call audio.
- Codec: The format used to encode voice. Softphones and desk phones both use G.711.
- Jitter: Variation in the arrival time of audio packets. High jitter makes audio choppy.
- Packet loss: Percentage of audio packets that fail to arrive. See Network quality thresholds.
- Latency / RTT: How long a packet takes to travel to the far end and back. High latency causes people to talk over each other.
- MOS (Mean Opinion Score): A 1 to 5 rating of perceived voice quality.
- SIP ALG: A router feature that inspects and rewrites SIP traffic. Usually does more harm than good with hosted voice. Turn it off.
- NAT: The mechanism a router uses to share one public IP across many private devices.
- STUN / TURN: Servers that help softphones work through NAT and restrictive firewalls.
- DSCP / QoS: Packet tagging that lets a router prioritize voice over other traffic.
- PoE (Power over Ethernet): Powering a desk phone over the same network cable that carries its data.