Network requirements
Callstrike live video and audio sessions require outbound access to a small number of Callstrike and Twilio endpoints. Most corporate networks already permit this traffic. Where they do not, this page lists every destination, protocol and port your network team requires.
What to allow
Everything is outbound only, initiated by the browser. No inbound rules are needed: return traffic is handled by your firewall's existing connection tracking.
| # | What it is for | Protocol | Destination | Port |
|---|---|---|---|---|
| 1 | The Callstrike console | TCP (HTTPS) | callstrike.ai, www.callstrike.ai | 443 |
| 2 | The Callstrike API | TCP (HTTPS) | api.callstrike.ai | 443 |
| 3 | The training portal used by your employees | TCP (HTTPS) | learner.callstrike.ai | 443 |
| 4 | The session host, its audio and video, and its encrypted relay fallback | TCP (HTTPS and WSS) | *.compute.callstrike.ai | 443 |
| 5 | Optional. The session host's own relay, used if Twilio's relay (rows 8 to 10) is unavailable | UDP | *.compute.callstrike.ai | 3478 |
| 6 | Optional. The same relay over TCP | TCP | *.compute.callstrike.ai | 3478 |
| 7 | Determining a viable media path | UDP | global.stun.twilio.com | 3478 |
| 8 | Relaying audio and video. Primary media path. | UDP | global.turn.twilio.com | 3478 |
| 9 | Relay fallback, used when outbound UDP is unavailable | TCP | global.turn.twilio.com | 3478 |
| 10 | Final relay fallback, and the slowest of the three | TCP (TLS) | global.turn.twilio.com | 443 |
| 11 | Optional. A secondary check for a viable media path | UDP | stun.l.google.com | 19302 |
Three requirements that are easily missed
Row 4 requires a wildcard rule, and so do rows 5 and 6 if you approve them. Each session is assigned its own subdomain under
compute.callstrike.ai, created when the session starts and removed when it ends. A rule
that names individual hosts will succeed once and then fail for every subsequent session.
Permit *.compute.callstrike.ai.
Rows 5 and 6 cannot be written as IP addresses, and are not required. Each session host receives a new address when the session starts, so there is no fixed range to permit. If your firewall cannot match a wildcard hostname on UDP or TCP 3478, leave rows 5 and 6 out: the session's audio and video use Twilio's relay in rows 8 to 10 instead, whose addresses are published. Denied traffic to port 3478 on an unfamiliar address during a session is this traffic, and is expected when rows 5 and 6 are not approved.
Rows 7 to 10 may require IP addresses rather than hostnames. This media relay is
operated by Twilio. Where your firewall supports hostname matching, the wildcards
*.stun.twilio.com and *.turn.twilio.com cover rows 7 to 10. Many firewalls cannot match
hostnames on UDP traffic. In that case, use Twilio's published static IP ranges for your
region, documented at
STUN-TURN IP Addresses & Ports.
Those ranges are deliberately not reproduced on this page. Twilio adds and retires them over time, and an out-of-date copy would be worse than no copy at all: your firewall rules would appear correct while the traffic continued to be dropped. Take the ranges from Twilio and re-check them whenever you review your rules.
If only two media rules can be approved, approve rows 7 and 8
Sessions will still connect without them, using the fallbacks, but performance degrades at each step. The final fallbacks are degraded enough to be noticeable to participants. Rows 1 to 4 are mandatory: without them a session cannot start at all. Rows 5, 6 and 11 are optional: a session connects normally without them.
Checking a network before a session
The session setup screen measures the network the operator is connected to and reports the result before the session begins. The check runs automatically, completes in a few seconds, and never prevents a session from starting: the result is advisory.
Run the check from the location the session will be delivered from, on the connection that will be used. A result recorded on a home connection describes that connection, not the meeting room the session will actually run from. Results are retained, and a stored result is always displayed with the time it was recorded.
What each result means
Direct connection available
No action required. Audio and video are sent directly and no firewall changes are needed.
Relayed connection over UDP
Direct connections are not permitted on this network, so audio and video are relayed. This path performs well and sessions should run normally. No traffic is being blocked that opening a port would resolve, so no firewall change is required.
Relayed connection over TCP
Sessions will run on this network. Callstrike delivers live video and audio using the same open web standard as browser-based video services such as Google Meet, and where outbound UDP is not permitted it falls back automatically to TCP. That fallback is deliberate and tested. TCP recovers from lost packets more slowly than UDP, so quality can be slightly below that of a direct connection.
Run a session and assess it. If the quality is acceptable, no change is required. For the
most reliable experience we recommend permitting UDP 3478 to global.turn.twilio.com
(row 8).
Relayed connection over TLS on port 443
Sessions will run on this network. Callstrike delivers live video and audio using the same open web standard as browser-based video services such as Google Meet, and where outbound UDP and direct TCP are both blocked it falls back automatically to a single encrypted connection on port 443. That fallback is deliberate and tested, and your firewall is currently permitting it as rows 4 and 10.
It is, however, the slowest path available. Because every stream shares one connection, a single lost packet delays all of them, and participants may occasionally see the video stall for a few seconds.
Run a session and assess it. If the quality is acceptable, no change is required. For the
most reliable experience we recommend permitting UDP 3478 to global.turn.twilio.com
(row 8), which removes the stalls.
Live sessions are blocked on this network
Every available connection method was attempted and all of them were refused. A session cannot connect on this network. Permit rows 7 to 10 in the table above, and confirm that rows 1 to 4 are also permitted: if the console and the session host are unreachable, the media rules have no effect.
Not measured
The check did not complete, so no result is available. This is not an indication that the network is blocking anything. The usual causes are on the Callstrike side or an unsupported browser. Run the check again, and if the result does not change, contact Callstrike support rather than altering any firewall rules.
Common causes
- Outbound UDP blocked. By far the most common cause, and the reason for every relayed result described above.
- A proxy that permits only port 443. Produces the TLS result, together with the stalls described above.
- Deep packet inspection. May allow the check to pass while still degrading a live session, because inspecting media traffic adds delay to every packet.
If sessions continue to stall after UDP 3478 has been permitted, send Callstrike support the result the check now reports and we will investigate.