Cloud Calls network requirements

Use a wired connection where you can. Wi-Fi is fine for normal browsing, but voice traffic is unforgiving about jitter and dropped packets, and Wi-Fi produces both. Plugging into Ethernet is the single cheapest fix for choppy audio.

Check your router is current. Older consumer routers handle VoIP traffic badly, particularly under load with several users calling at once.

If you use a USB Ethernet adapter, use a gigabit one. Cheap adapters are often capped at 100 Mbps and drop the link under sustained load. A known-brand USB-C or Thunderbolt gigabit adapter avoids this.

Remote users need a stable connection more than a fast one. A single call uses roughly 100 kbps in each direction, so raw bandwidth is almost never the problem. What matters is consistency. Aim for latency under 200 ms, jitter under 30 ms, and packet loss under 3%.

Before changing any firewall settings, have the member run Twilio's network test on the machine they call from, on the same network and in the same browser: https://networktest.twilio.com

You can point the test to a specific Twilio edge location by adding it as a query parameter, for example: https://networktest.twilio.com/?edge=ashburn or https://networktest.twilio.com/?edge=dublin. Run it twice, once on Wi-Fi and once on a wired connection, and run it during a busy calling period rather than an empty afternoon. Packet loss above 1 to 2%, or jitter above 30 ms, points at the local network or the ISP rather than at Reply or Twilio.

If calls fail to connect, drop, or have audio in one direction only, your network is probably blocking part of the traffic the dialer needs. Apply the settings below to every device that can filter traffic: firewalls, routers, switches, load balancers, VPN clients, and endpoint security software.

Ports to open (outbound)

The UDP range is wide. Twilio expanded it from the old 10,000 to 20,000 range, and allowing only the old range is a common cause of one-way audio and calls that drop after a few seconds.

Domains to allow

Allow these by hostname, not by IP address. Twilio's signalling servers sit behind addresses that change.

Reply's dialer uses Twilio's automatic edge selection, which picks the closest healthy location at call time. That's why the whole list matters and not only the edge nearest your office.

Media IP range

All call audio comes from one global range: 168.86.128.0/18, on UDP ports 10,000 to 60,000.

If your firewall rules still list per-region Twilio addresses from an older configuration, replace them with the range above.

Firewalls and packet inspection

Exclude the Twilio domains and IP range, and run.reply.io, from stateful packet inspection and from any TLS interception. Deep inspection adds delay to every packet and shows up as long connection times and stuttering audio.

If a device on the path is a managed switch that was configured by someone else, have your network team confirm the rules above actually reach it. We have had cases where hardware plugged into a misconfigured smart switch silently overrode the allow list applied further up.

Quality of Service

If user hear jitter or gaps in speech while other traffic is heavy, prioritise the UDP media range above on your router. Given how wide that range is, look at what else on your network uses those ports before you apply the rule.

The dialer already tags its audio packets with DSCP 46 (Expedited Forwarding). If your network honours DSCP, you can prioritise on the tag instead of on the port range, which is cleaner.

If all of that checks out and calls still sound bad, contact Reply support with the network test results, the approximate time of a bad call, and the number that was dialled, so we can pull that call's quality data from Twilio.