Network and Firewall Requirements

This page describes the network traffic that LiveSwitch Cloud clients send, so network and security teams can configure firewall rules, proxies, and secure web gateways, such as Zscaler, to allow it.

Note

This page applies to LiveSwitch Cloud. If you host LiveSwitch Server yourself, see the LiveSwitch Server Deployment Configuration documentation instead, because you control the ports and addresses of your own deployment.

How LiveSwitch Cloud Traffic Flows

A LiveSwitch client makes two kinds of connections:

  • Signaling and API traffic goes to the LiveSwitch Cloud Gateway and REST API over HTTPS and secure WebSockets on TCP port 443.
  • Media traffic (audio, video, and data channels) uses ICE to try the most efficient path first and fall back to more restrictive ones. Where that traffic goes depends on the connection type.

For SFU and MCU connections, media always goes to a LiveSwitch Cloud Media Server, using the first path that works:

  1. Direct UDP to the Media Server.
  2. TURN relay over UDP or TCP.
  3. TURNS relay, which is TURN wrapped in TLS on TCP port 443. This looks like ordinary HTTPS traffic to the network.

For peer (P2P) connections, media flows directly between the two clients when their networks allow it, and never touches LiveSwitch Cloud. When a direct path isn't possible, media is relayed over TURN or TURNS through the STUN/TURN servers embedded in the LiveSwitch Cloud Media Servers, so relayed peer traffic uses the same Media Server hostnames and ports as SFU and MCU traffic.

For background on these protocols, see What Are STUN, TURN, and ICE?.

Domains

All LiveSwitch Cloud services are addressed under the liveswitch.io domain:

Hostname Purpose
cloud.liveswitch.io Gateway, used by the client SDK for registration and signaling
api.liveswitch.io REST API
ms-<ip>.cloud-<region>.liveswitch.io Media Server TURNS relay, for example ms-3-148-208-3.cloud-001-useast2.liveswitch.io

Allow *.liveswitch.io as a domain-based rule. Gateway, API, and TURNS connections all use TLS, so the hostname is visible in the TLS handshake (SNI) before any decryption. Secure web gateways and proxies can match on it the same way they allow other HTTPS traffic by domain.

Ports

Traffic Protocol Destination ports Required
Gateway and REST API TCP (HTTPS / WSS) 443 Always
TURNS relay TCP (TLS) 443 Recommended; the only media path that works on networks that only allow HTTPS
Direct media (ICE), SFU and MCU UDP 32768-49151 Optional; gives the best call quality
STUN and TURN UDP and TCP 3478 Optional
TURN relay UDP and TCP 49152-65535 Optional

All connections to LiveSwitch Cloud are outbound from the client. LiveSwitch Cloud never needs inbound connections to your network. Direct peer connections between two clients don't use these ports; they use whatever UDP ports the two clients negotiate, and fall back to TURN or TURNS relay when the network blocks them.

If only TCP port 443 is allowed, clients can still connect through TURNS. Opening the UDP ranges lets clients use direct or UDP relay paths, which have lower latency and better quality than TCP-based relay.

Restrictive Networks and Secure Web Gateways

Some secure web gateways, such as Zscaler, classify traffic sent to a raw IP address by doing a reverse DNS lookup or a reputation lookup on that IP. This is unreliable for LiveSwitch Cloud:

  • LiveSwitch Cloud Media Servers run in AWS and use dynamically assigned public IP addresses.
  • These addresses don't have reverse DNS records under liveswitch.io. A reverse lookup returns a generic AWS hostname.
  • AWS reuses public IP addresses across customers over time, so reputation databases may classify the same address differently from one day to the next.

The symptom is usually intermittent: some calls connect right away, others wait several seconds before connecting or fail outright, depending on which Media Server address a call uses.

The reliable fix is to allow *.liveswitch.io by domain and have clients on these networks use TURNS. TURNS connections are addressed by hostname, so the gateway matches them by SNI instead of by IP address.

Force Clients to Use TURNS

By default, the client SDK tries every connection path and uses the best one that works. On a network that only allows TLS on port 443, the client spends time trying UDP and TURN paths that the network blocks before it falls back to TURNS.

If you know a user is on such a network, you can skip those attempts. Make this a setting in your application that a customer or user turns on, rather than forcing it for everyone. Users on open networks get better quality from direct UDP connections.

Relay-Only Connections

Set the connection's ICE gather policy to Relay before you open the connection. The client then uses only TURN and TURNS relay paths. This works for SFU, MCU, and peer connections.

Note

About the code examples on this page:

  • For .NET MAUI and Unity, use the C# code.
  • For macOS, use the iOS code.
connection.IceGatherPolicy = FM.LiveSwitch.IceGatherPolicy.Relay;

TURNS-Only Connections

To go straight to TURNS, also remove every relay server other than TURNS from the list that LiveSwitch Cloud sends to the client. Handle the connection's OnAutomaticIceServers event, which is raised before the client uses the servers, and keep only the turns: entries. Add the handler before you open the connection.

connection.IceGatherPolicy = FM.LiveSwitch.IceGatherPolicy.Relay;
connection.OnAutomaticIceServers += (conn, iceServers) =>
{
    foreach (var iceServer in iceServers.Values)
    {
        if (!(iceServer.IsTurn && iceServer.IsSecure))
        {
            iceServers.Remove(iceServer);
        }
    }
};
Note

If your application also sets its own ICE servers on the connection, LiveSwitch uses them as a backup after the automatic servers. Leave them out when you force TURNS.

IP Address Allow Lists

Use domain-based rules where possible. If part of your network policy must allow traffic by IP address, keep the allow list in sync automatically. LiveSwitch Cloud IP addresses change over time, so a list built by hand from logs or past failures always falls behind.

LiveSwitch provides two endpoints that return the current addresses as JSON. Poll either one on a schedule and update your firewall rules from the result.

Public Endpoint

https://ip.liveswitch.io/ returns the current LiveSwitch Cloud IP addresses. No authentication is required.

curl https://ip.liveswitch.io/

Application Endpoint

Applications/{ApplicationID}/IPAddresses returns the addresses for one Application, grouped by server role. It requires an API key.

curl -X GET "https://api.liveswitch.io/Applications/<your-applicationId>/IPAddresses?api-version=1.0" -H "accept: */*" -H "X-API-Key: <your-api-key>"

An example response looks like this:

{
  "sync": [ //These are IP addresses for the Gateway Servers
    "3.138.248.52",
    "3.20.255.205",
    "3.14.163.200",
    "3.140.141.165"
  ],
  "media": [ //These are IP addresses for the Media Servers
    "3.137.158.14",
    "3.137.158.14"
  ],
  "api": [ //These are the IP addresses for the API Servers
    "3.16.99.72",
    "3.14.95.25",
    "18.221.91.34"
  ]
}

Dedicated IP Addresses

The standard LiveSwitch Cloud service doesn't offer static or dedicated IP addresses. If your security requirements can only be met with a fixed IP range, LiveSwitch offers private cloud deployments with an IP range reserved for your traffic. A private cloud deployment is a separate offering from the standard LiveSwitch Cloud service and costs more. To discuss whether it's right for you, contact LiveSwitch.

When WebRTC Is Blocked Entirely

Some networks inspect packets deeply enough to block WebRTC media even over TURNS. In that case, consider Media-over-WebSockets, which streams media over a standard WebSocket connection.