Most practice networks already meet every requirement here out of the box. With a normal business internet connection and a router that has not been heavily locked down, DI Voice will almost certainly work on day one. Confirm these six things in advance:

A DI Voice call uses very little bandwidth on either endpoint type:

The table is sized at 100 kbps per call, so it is safe for either endpoint type.

Modern connections have plenty of headroom for voice. What causes problems is how bandwidth is shared with other traffic: a 100 Mbps line saturated by a large cloud backup or imaging upload at the wrong moment can still break a call. Quality of Service addresses that.

Voice depends on the quality of a connection, not just its speed. Three metrics matter:

These are industry-standard VoIP thresholds. A connection that consistently sits outside the Acceptable column will hurt voice quality on any platform, so measure before go-live rather than after the first complaint from the front desk. Validate before go-live explains how.

Once DI Voice is live, the Call Quality dashboard in the DI Voice admin portal reports the same metrics (average MOS, jitter, packet loss) per call, giving a numbers-based record of how the network actually performs.

The practice's firewall needs to allow outbound traffic to the destinations below. No inbound port-forwarding rules are required; DI Voice keeps the connection alive from the endpoint side.

The SIP signalling hostnames resolve to static IP addresses (one per region) and are suitable for allowlisting; allow both regions. Media-relay servers and credentials for the softphone and mobile app are supplied 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 and are not fixed. The recommended rule 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 the network 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, so the firewall must refresh them; many enterprise firewalls offer AWS ranges as a built-in dynamic feed.

Desk phones and DECT signal over SIP (UDP/TCP 5060/5061) and carry audio over RTP on UDP. They have no TCP 443 fallback, so on a locked-down network the SIP and RTP destinations must be explicitly permitted.

Most small-business routers allow all of this outbound by default. Problems almost always come from a deliberately locked-down firewall, a UTM appliance doing deep packet inspection, or SIP ALG.

Four settings cause most network-side voice problems. Confirm each before go-live.

SIP ALG (Application Layer Gateway) is a router feature that inspects and rewrites SIP traffic. It is well-intentioned but almost always interferes with hosted voice, and it is the most common source of one-way audio and registration problems on small-office 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.

If the internet provider's modem also acts as a router and the practice's 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.

For inbound calls to reach a phone, the router must keep its NAT mapping open between calls. DI Voice sends keepalives every 20 seconds, so the router only needs to keep mappings longer than that. Virtually every small-business router clears this bar by default; standard UDP timeouts are measured in minutes.

This only becomes a problem on a firewall or UTM appliance tuned to prune UDP sessions on very short timers, or one running a "SIP-aware" or "VoIP-aware" inspection profile. On those networks:

The symptom this prevents is inbound calls not ringing on a phone that otherwise shows as connected.

Because endpoints maintain the connection outbound, there is no need to open inbound ports, set up port forwarding or place phones in a DMZ. If the practice's previous phone system required port forwarding, those rules can be removed.

This section mostly concerns desk phones and DECT, but the wired-versus-wireless guidance applies to every endpoint.

QoS lets a router protect voice traffic when the network is busy with other things, such as video meetings, imaging uploads or cloud backups. DI Voice phones already tag their traffic by default, so the router only needs to honor those tags and give the voice class priority:

QoS is optional on most practice networks, where there is enough headroom that voice never competes. Configure it if call-quality dips line up with busy periods, or wherever voice shares a link with heavy data traffic. On a network with a dedicated voice VLAN, this is usually where prioritization is applied.

This covers DI Voice-provisioned desk phones and DECT bases, which register over SIP.

Bringing the practice's own existing SIP phones is covered separately and is out of scope for this guide.

Two quick tests from the practice confirm the network is voice-ready before the phones go live. Run both from a device on the same network and connection the phones will use: wired if the phones are wired, the same Wi-Fi if they are wireless.

A regular speed test reports raw bandwidth but not whether a connection is voice-grade. For voice, the test must also measure jitter and packet loss.

The recommended tool is the Cloudflare speed test at speed.cloudflare.com. It is free, runs in the browser from the practice's network, and reports jitter and latency alongside bandwidth. Let it finish, then compare the result against Network quality thresholds. If jitter or packet loss lands in the Problematic column, fix the network before go-live.

A speed test is a snapshot; a continuous ping shows whether the connection holds steady over a few minutes. From a computer on the practice's network:

macOS or Linux:

Windows:

Let it run for two to three minutes. Packet loss should be at or near 0%, and a large spread between minimum and maximum round-trip time indicates jitter. Wild variation or dropped packets means a problem that calls will inherit.

The practice's E911 location is registered during DI Voice onboarding and must be in place before phones make outbound calls. Once phones are provisioned, confirm emergency routing by dialing 933, the test number that reads back the registered address. Never dial 911 to test. See Locations in the DI Voice Admin Guide.

A one-screen version to hand to the practice's IT contact before go-live.

Internet and bandwidth

Network quality (from speed.cloudflare.com)

Router and firewall

Local network (desk phones)

Wireless (DECT)

Optional, busier networks

After provisioning

Work through this guide and the two validation tests first; most network readiness is self-serve. Contact DI Voice Support when:

When you reach out, include the network test results, the affected location and users, and what you have already tried, so the team can pick up where you left off. The Call Quality dashboard in the DI Voice portal is the place to pull per-call evidence.