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, and its audio and video | TCP (HTTPS and WSS) | *.compute.callstrike.ai | 443 |
| 5 | Determining a viable media path | UDP | global.stun.twilio.com | 3478 |
| 6 | Relaying audio and video. Primary media path. | UDP | global.turn.twilio.com | 3478 |
| 7 | Relay fallback, used when outbound UDP is unavailable | TCP | global.turn.twilio.com | 3478 |
| 8 | Final relay fallback, and the slowest of the three | TCP (TLS) | global.turn.twilio.com | 443 |
Two requirements that are easily missed
Row 4 requires a wildcard rule. 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 to 8 may require IP addresses rather than hostnames. The media relay is operated
by Twilio. Where your firewall supports hostname matching, the wildcards
*.stun.twilio.com and *.turn.twilio.com cover rows 5 to 8. 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 one media rule can be approved, approve row 6
Sessions will still connect without row 6, using the fallbacks in rows 7 and 8, but performance degrades at each step. The final fallback is degraded enough to be noticeable to participants. Rows 1 to 4 are mandatory: without them a session cannot start at all.
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 6).
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 row 8.
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 6), 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 5 to 8 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.