Network Requirements
What a customer's network needs in order to run the phone system cleanly. Use this as a pre-flight checklist before cutover, not as a reactive troubleshooting manual.
This guide covers both kinds of endpoint:
- WebRTC clients — the browser-based softphone and the mobile app
- SIP devices — desk phones and DECT bases provisioned through DialStack
It is written for the person who runs the customer's network (an internal IT lead or their managed-service provider) and is safe to share directly with them. The thresholds and ports below are the same regardless of integration tier.
The short version
Most SMB networks already meet every requirement here out of the box. If the customer has a normal business internet connection and a router they have not 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 (a customer 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 the customer's site before cutover (see Validate before cutover).
The rest of this guide is the detail behind those six points.
Bandwidth
A single voice call uses very little bandwidth, on both WebRTC and SIP endpoints:
- WebRTC clients use the Opus codec: roughly 50 to 60 kbps per direction including overhead.
- Desk phones 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 endpoint type:
| 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 platform, so it is worth measuring before cutover rather than after the first complaint. The Validate before cutover 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 there is a numbers-based record of how the network is actually performing.
Ports and destinations
The customer's firewall needs to allow outbound traffic to the destinations below. No inbound port-forwarding rules are required; DialStack keeps the connection alive from the endpoint side.
| Protocol | Destination | Port | Used by | Purpose |
|---|---|---|---|---|
| SIP (UDP/TCP) | sip-east.dialstack.ai, sip-west.dialstack.ai | 5060, 5061 | SIP devices | Desk phone and DECT signalling |
| RTP (UDP) | DialStack media servers (see note below) | 10000–20000 | SIP devices | Desk phone and DECT audio |
| HTTPS (TCP) | prov.dialstack.ai | 443 | SIP devices | Automatic provisioning |
| WSS (TCP) | api.dialstack.ai | 443 | WebRTC, softphone, mobile | Signalling WebSocket |
| STUN (UDP) | global.stun.twilio.com | 3478 | WebRTC | NAT type discovery |
| TURN (UDP/TCP) | global.turn.twilio.com | 3478 | WebRTC | Media relay |
| TURN (TLS/TCP) | global.turn.twilio.com | 443 | WebRTC | Media relay (firewall fallback) |
The SIP signalling hostnames resolve to static IP addresses (one per region) and are suitable for allowlisting; allow both regions. The exact WebRTC media-relay servers and their credentials are provided to clients dynamically at call time.
About the RTP media destinations: call audio flows directly to the platform's media servers, whose addresses are supplied per-call in signalling and are not fixed. The simplest rule — and the one we recommend — 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. On networks that cannot allow "any destination", scope the rule to the published AWS IP ranges (ip-ranges.amazonaws.com/ip-ranges.json, service EC2, regions us-east-1 and us-west-2). Those ranges change over time, so the firewall needs to refresh them — many enterprise firewalls support AWS ranges as a built-in dynamic feed.
The two endpoint types reach the network differently, which is worth understanding when allowlisting:
- WebRTC clients always signal over TCP 443 (the standard HTTPS port) and prefer UDP for media, falling back to a TURN relay over TCP 443 when UDP is blocked. On a firewall that only permits TCP 443 outbound, WebRTC calls still work, with slightly higher latency. See WebRTC clients: specifics.
- SIP devices signal over SIP (UDP/TCP 5060/5061) and carry audio over RTP on a range of UDP ports. They do not have the TCP 443 fallback that WebRTC has, so on a locked-down network the SIP and RTP destinations must be explicitly permitted. See SIP devices: 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 cutover.
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 SMB 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 the customer's modem also acts as a router, and they have plugged their own router in behind it, traffic passes through two layers of NAT. This frequently breaks voice. Either put the upstream 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. DialStack sends keepalives 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 endpoints 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 SIP devices, but the wired-versus-wireless guidance applies to everything.
- Power over Ethernet (PoE). DialStack-supplied desk phones 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. DialStack-supplied phones provision themselves when they connect to the network and reach the internet. There is nothing to type into the phone by hand. The partner then assigns each device to a user in the admin portal, where its status shows as "provisioned". See Managing 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). DialStack-provisioned phones 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 SMB networks, where there is enough headroom that voice never has to compete. It is worth configuring if call quality dips correlate 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.
WebRTC clients: specifics
WebRTC covers the browser-based softphone and the mobile app. The connection model is built to work behind almost any firewall.
- Signalling is always a WebSocket over TLS (WSS) on TCP 443, indistinguishable from normal HTTPS traffic.
- Media prefers a direct UDP path and uses ICE to find the best route. If UDP is blocked, it relays through TURN over TCP 443 as a last resort. That fallback adds a small amount of latency but means calls work even on networks that only allow outbound HTTPS.
- Encryption is mandatory: media is DTLS-SRTP and signalling is WSS. There is no unencrypted path.
- NAT is handled automatically. Symmetric NAT, which breaks many older voice clients, is resolved by the TURN relay 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 WebRTC always has the TCP 443 fallback, it is the most resilient option on a restrictive network. If a customer's network cannot be opened up for SIP, the softphone will usually still work.
SIP devices: specifics
This covers DialStack-provisioned desk phones and DECT bases that register over SIP.
- Signalling uses SIP over UDP or TCP on ports 5060 and 5061 to the DialStack SIP servers.
- Media uses RTP over UDP ports 10000–20000 to the DialStack media servers. Unlike WebRTC, SIP devices do not fall back to TCP 443, so on a tightly controlled network the SIP and RTP destinations in the Ports and destinations table must be explicitly permitted outbound.
- Codecs. Desk phones use G.711, the standard carrier-grade voice codec; WebRTC clients use Opus. 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.
Bringing your own existing SIP devices is covered separately and is out of scope for this guide.
Validate before cutover
Two quick tests from the customer's site 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, browser-based, runs from the customer's 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 cutover.
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 the customer's 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
E911 location is registered during onboarding and must be in place 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 in the Admin Guide.
Pre-flight checklist
A one-screen version to hand to the customer's IT contact before cutover.
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 below 30 ms
- Packet loss below 1%
- Round-trip latency below 150 ms
Router and firewall
- SIP ALG disabled
- No double NAT (single device doing NAT, or upstream 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 escalate
Work through this guide and the two validation tests first; the large majority of network readiness is self-serve. Escalate an issue to DialStack 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 escalate, 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 browser and mobile real-time voice technology behind the softphone and the mobile app. Works over HTTPS-style connections and needs no special client install in the browser.
- SIP: The signalling protocol physical desk phones use to register and place calls.
- RTP: The protocol that carries the actual call audio.
- Codec: The format used to encode voice. WebRTC clients use Opus; desk phones 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. Anything above 1% is noticeable.
- 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. Above 4.0 is good.
- 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 WebRTC clients 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.