Calling: network and firewall requirements

Most people never need this page. Home broadband, mobile hotspots and ordinary office wifi all work with no setup. Read on only if calls fail to connect, connect with no sound one way, or drop after a few seconds, and only on a corporate or school network.

How the call actually travels. When a rep places or answers a call, the audio goes straight from their browser to our telephony carrier. It does not pass through HuntSales servers. That is why call quality tracks the rep's own internet connection rather than anything in the CRM, and why a network that blocks the carrier stops calls even though the rest of HuntSales works perfectly.

What a restrictive network has to allow. All of it is outbound from the rep's computer; nothing needs to be opened inbound, and no port forwarding is involved.

• Secure WebSockets over TCP 443 for call signalling, the same port normal HTTPS uses. A network that allows ordinary web browsing usually allows this already.
• UDP for the audio itself. This is the one corporate firewalls most often block. When UDP is blocked the call falls back to a relay (TURN), which is what the IP range below is for.
• The relay range 64.16.246.128/26, which covers 64.16.246.128 to 64.16.246.191.

The relay range is changing on 14 September 2026. Our carrier is widening it. If your IT team allowlists the old ranges 64.16.246.96/27 or 64.16.246.128/29, they must move to 64.16.246.128/26 before that date or relayed calls will start failing. The old /29 sits inside the new /26, so the new range is a superset: allowlisting it is safe to do today and needs no coordination with us. Nothing inside HuntSales has to change, and if your network does not filter outbound traffic there is nothing to do at all.

Symptoms that point at the network rather than at us. The softphone signs in and shows Ready, but calls never connect. Or the call connects and one side hears nothing. Or every call drops at roughly the same number of seconds. Those three are the classic signature of blocked UDP with no working relay. By contrast, if the softphone cannot sign in at all, or shows Connecting and stays there, that is usually signalling or credentials, not media.

Other things worth checking first, because they are far more common than a firewall. The browser needs microphone permission, which it will only ask for over HTTPS. The tab has to stay open to receive inbound calls. And a headset selected in the operating system but not in the browser is the usual cause of "they cannot hear me".

Still stuck? Send your IT team this page, then contact support with the rep's location, the time of a failed call and the number dialled. Every call attempt is logged with a reason, so support can normally tell you which of the above it was rather than guessing.