For a self hosted livekit instance running in tcp only mode due to corporate firewall restriction on UDP- does it require port 7880/7881 open in firewall

Thanks for reaching out, mithun. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

Is the 7880/7881 port used by websock control channel in tcp mode ?

Thanks — I’m responding to your question about whether ports 7880/7881 are used by the WebSocket control channel in TCP-only mode. Short answer: Port 7880 is used for the WebSocket control/signaling channel. Port 7881 is not the WebSocket control channel — it’s used for other LiveKit services (e.g., TURN/related services) and for additional server-side endpoints. Details: • The WebSocket signaling/control channel (room join, publish, subscribe, control messages) runs over TCP on port 7880. • Media traffic is normally UDP; in UDP-restricted environments media can be relayed over TURN (often over TCP/TLS). That TURN/relay-related traffic is associated with port 7881 (and/or configured TURN ports), not the WebSocket control channel. • Even in TCP-only mode you still need TCP 7880 open so clients can reach signaling. TURN/TCP may be configured on port 443 (recommended for corporate firewalls) so media can flow when UDP is blocked. If you want, tell me: • Whether you’re using your own TURN server or LiveKit Cloud TURN, and • Whether you want sample client config to force relay (e.g.,

iceTransportPolicy: 'relay'

) or server-side settings for TURN over TCP/TLS. I can then provide exact config snippets or firewall rule suggestions. Sources: Running LiveKit on AWS | LiveKit | Firewall Tips, with interactive elements

using the turn inbuild in livekit

Thanks — you mentioned you’re using the built‑in TURN in LiveKit. I’ll clarify what that means for ports and configuration when UDP is blocked. What you need to know • Keep TCP 7880 open — this is required for the WebSocket signaling/control channel (room join, publish/subscribe, control messages). • Keep TCP 7881 open as well — LiveKit uses 7881 for TURN/related server services when using the built‑in TURN. So both 7880 and 7881 should be reachable even in TCP‑only setups. • Media over UDP is ideal, but in UDP‑restricted environments the built‑in TURN will relay media over TCP/TLS. You can (and should) make TURN accessible over a firewall‑friendly port such as TCP 443 if your network requires it — this requires configuring the LiveKit TURN to listen on 443 (or proxying/port‑forwarding from 443 to your TURN port). Recommended actions 1. Open TCP ports 7880 and 7881 to the LiveKit server for signaling and built‑in TURN service. 2. Configure the built‑in TURN to support TCP/TLS and, if needed, bind or forward it to port 443 so clients behind strict corporate firewalls can reach TURN over HTTPS‑like traffic. 3. On the client side, force relay-only if you must avoid attempting UDP connectivity: ◦ Example: set

iceTransportPolicy: 'relay'

in your RTC config so clients use TURN/TCP. 1. Test from inside a corporate‑restricted network to confirm signaling (WS to 7880) and media (TURN over TCP/TLS) work end‑to‑end. If you’d like, I can: • Provide the exact LiveKit config snippet for enabling TURN over TCP/TLS and binding/forwarding to 443. • Give a short checklist for firewall rules and a quick client test plan. Which would be most helpful next? , with interactive elements

iceTransportPolicy: 'relay'

) yes I want to force this

Great — you want to force relay-only so clients always use the built‑in TURN (TCP/TLS) instead of attempting UDP. Below are the key steps and example configurations for both client and server, plus firewall guidance and a simple test plan. What to open in the firewall • TCP 7880 — LiveKit WebSocket signaling/control channel (must be open). • TCP 7881 — LiveKit’s built‑in TURN/related service (must be open if you use the default TURN port). • Optional/friendly: TCP 443 — recommended to expose TURN over TCP/TLS on 443 (bind or proxy 443 → 7881) so clients behind strict corporate firewalls can reach TURN as HTTPS-like traffic. Client (force relay-only) • Set the RTC config to force TURN-only transport:

const pc = new RTCPeerConnection({
  iceServers: [
    { urls: ["turn:your-livekit-host:7881?transport=tcp"], username: "TURN_USERNAME", credential: "TURN_PASSWORD" }
  ],
  iceTransportPolicy: "relay"
});

• If you expose TURN on 443 (recommended), update the TURN URL:

{ urls: ["turn:your-livekit-host:443?transport=tcp"], ... }

• In LiveKit SDKs, ensure connect options pass the

iceServers

(or rely on server-provided ICE credentials) and set

iceTransportPolicy: "relay"

where the SDK exposes RTC config options. Server (built-in TURN + TCP/TLS) • Ensure the built‑in TURN is enabled and configured for TCP/TLS. Two common approaches: ◦ Bind the TURN listener to 7881 and also configure TLS for TURN/TCP if supported. ◦ Or proxy/bind external port 443 to the TURN service (e.g., with an HTTPS/TCP proxy or iptables port forward) so corporate clients can reach TURN on 443. • Make sure LiveKit is issuing TURN credentials (username/credential) to clients. The LiveKit server will normally provide ICE servers/credentials as part of signaling; confirm your client uses those credentials. Firewall and proxy checklist • Allow inbound TCP 7880 and 7881 to the LiveKit server. • If you prefer TURN over 443, create a secure forward from 443 → 7881 (or configure TURN to listen on 443) and open TCP 443. • If you use TLS termination (proxy), ensure the TURN signaling between proxy and LiveKit is secure/trusted. • Confirm any corporate proxy doesn’t block the TURN payload on 443. Quick test plan 1. From inside the corporate network, try connecting to signaling: ◦ WebSocket to ws/wss on port 7880 — confirm room join succeeds. 1. Verify client receives ICE servers/credentials from LiveKit. 2. Force

iceTransportPolicy: 'relay'

and connect: ◦ Confirm ICE candidates are TURN candidates (server reflexive vs relay). ◦ Confirm media flows (audio/video) via TURN — observe higher latency but a working stream. 1. If connection fails, test connectivity: ◦ TCP connect to your-livekit-host:7881 (and :443 if forwarded) from within the corporate network (e.g.,

telnet host 7881

or

curl

to a TLS endpoint) to verify port reachability. If you want, I can: • Provide the exact LiveKit config snippet for enabling TURN/TLS (showing relevant config keys). • Give an example of how to let LiveKit return ICE servers automatically in the SDK you’re using (JS, iOS, or Android). • Outline commands to test port reachability from a restricted environment. Which of those would help you next? , with interactive elements

can I raise this as unidirectional wrt to firewall request

Yes — you can raise a unidirectional (inbound-only) firewall request for LiveKit. Below is a clear mapping of which directions and ports need to be reachable and some suggested wording and considerations you can include in the request. Which ports need inbound access to the LiveKit server • TCP 7880 — inbound to server ◦ Purpose: WebSocket signaling / control channel (room join, publish/subscribe, control messages). ◦ Direction: Clients must be able to open TCP connections to the server on 7880 (inbound to your LiveKit host). • TCP 7881 — inbound to server ◦ Purpose: Built‑in TURN / TURN-related services when using LiveKit’s internal TURN. ◦ Direction: Clients must be able to open TCP connections to the server on 7881 (inbound to your LiveKit host) if you keep the TURN on its default port. Optional / recommended • TCP 443 — inbound to server or proxy → forwarded to TURN ◦ Purpose: Expose TURN over TCP/TLS on port 443 so clients behind strict corporate firewalls can reach TURN as HTTPS-like traffic. ◦ Direction: Clients must be able to open outbound TCP connections to port 443 on your public endpoint. You can forward or proxy 443 to 7881 on the server side so the firewall only needs to allow 443. Notes about outbound traffic from the LiveKit server • Your LiveKit server must be able to make outbound connections for updates, external TURNs, or metrics if you rely on external services — but for a self-hosted built‑in TURN scenario, the primary requirement is inbound client connectivity to the server ports above. Suggested unidirectional firewall request text • Short version: ◦ "Please allow inbound TCP traffic to my LiveKit host: TCP 7880 (WebSocket signaling) and TCP 7881 (built‑in TURN). Optionally allow TCP 443 if we will expose TURN on 443 (proxy/forward 443 → 7881). Outbound connections from clients remain standard (HTTPS, etc.)." • Longer version with rationale: ◦ "We are deploying a self‑hosted LiveKit service. Clients need to establish WebSocket signaling connections and TURN relay connections to the LiveKit server. Please allow inbound TCP to: ▪︎ 7880 (WebSocket signaling/control) → required for signaling (room join, track control). ▪︎ 7881 (built‑in TURN) → required for TURN relay when UDP is blocked. We will optionally publish TURN on TCP 443 (forward/proxy 443 → 7881) for corporate clients that only allow HTTPS-like traffic. All connections are TLS where applicable." Things to confirm with your firewall/security team • Whether they prefer opening 7881 directly or exposing TURN on 443 (443 is usually easier to get approved). • If a proxy/termination is required on 443, confirm TLS handling and port forwarding to 7881 on the server. • Ensure any deep packet inspection or proxy on 443 will not break TURN/TCP payloads. • Confirm inbound-only is acceptable; clients initiate outbound connections to these ports (so the server does not need additional outbound firewall exceptions beyond normal operations). If you want, I can: • Draft a one‑page justification or exact ticket body you can paste into your firewall change request system. • Provide the exact LiveKit config snippet and steps for forwarding 443 → 7881 (iptables/nginx/tcp-proxy examples). Which would you like me to prepare? , with interactive elements

so if there is turn - which can be removed

Thanks — you’re asking if the built‑in TURN can be removed when running LiveKit in your TCP‑only environment. I’ll explain the implications and give recommendations so you can decide. Short answer • You should not remove TURN if clients are behind firewalls that block UDP. TURN is required to relay media over TCP/TLS when direct UDP WebRTC transport is unavailable. Why TURN matters • WebRTC’s preferred media path is UDP. If UDP is blocked, peers cannot establish direct media paths. • TURN acts as a relay so media can flow between clients when direct peer-to-peer (UDP) connections fail. • For UDP-restricted networks, TURN over TCP (and TLS on TCP/443) is the usual way to get working audio/video. Removing TURN will prevent clients behind restrictive firewalls from exchanging media. When you can consider removing TURN • All clients are on networks that allow UDP media (so peer-to-peer or server-assisted UDP paths work). • You accept that sessions will fail or have no media for clients behind UDP-only-blocking firewalls. • You have an alternative relay/transport in place (e.g., a corporate-approved TURN or other media relay service) and will configure clients/LiveKit to use that instead. Recommendations • Keep the built‑in TURN if you need reliable connectivity for users on corporate/restricted networks. • If corporate policy forbids running TURN on your LiveKit host, expose or forward TURN on TCP/TLS port 443 (recommended) so it looks like HTTPS traffic and is more likely to pass firewalls. • If you want to remove the built‑in TURN, ensure you: a. Provide an alternate TURN service to clients (external TURN) and update LiveKit/client ICE server configuration accordingly, or b. Accept that clients on UDP‑blocked networks will not have media connectivity. • To force clients to use TURN, set

iceTransportPolicy: 'relay'

on the client side so they won’t attempt UDP even if available. Quick question to help me advise further • Do you want to remove TURN because of security/policy reasons, or because you want to rely on an external TURN provider or plain UDP? Tell me that and I’ll give exact config snippets for removing built‑in TURN safely or for configuring LiveKit to use an external TURN service (including port/proxy suggestions). , with interactive elements

I mean if I am using inbuit turn - can port 7880 7881 be removed ?

Thanks — I’m responding to your question about whether ports 7880 and 7881 can be removed/closed when you use the built‑in TURN. Short answer: No — you cannot remove both ports if you want a working LiveKit deployment with built‑in TURN and TCP-only clients. Why: • TCP 7880 is required for the WebSocket signaling/control channel (room join, publish/subscribe, control messages). Clients must be able to reach this port to establish signaling with the LiveKit server. • TCP 7881 is used by the built‑in TURN/relay service (or other LiveKit server services). If you rely on LiveKit’s built‑in TURN to relay media when UDP is blocked, clients must be able to reach the TURN listener (default 7881). What you can do instead of “removing” them • Rebind or proxy TURN to a different, firewall‑friendly port (commonly TCP 443). You can: ◦ Configure LiveKit / its TURN listener to run on 443 if supported, or ◦ Put a TLS/TCP proxy or port forward (443 → 7881) so corporate networks that only allow HTTPS still reach TURN. • Keep 7880 open for signaling. If your security team refuses 7880, you can similarly proxy 443 → 7880 (but signaling must still be reachable by clients). • Use an external/third‑party TURN service on an allowed port and configure LiveKit/clients to use that instead; then you could close 7881 on the LiveKit host. Implications of closing either port • Closing 7880 → clients cannot perform signaling; rooms can’t be joined even if TURN is reachable. • Closing 7881 while keeping 7880 → signaling works but media won’t flow for clients behind UDP‑blocking firewalls (no TURN relay). • Forwarding/proxying to 443 is the typical compromise for strict corporate environments. If you want, I can: • Draft exact firewall request text saying which ports to open or proxy (7880, 7881, or 443→7881). • Provide the LiveKit config snippet or example iptables/nginx/tcp-proxy commands to forward 443 → 7881. • Show the client-side changes to ensure

iceTransportPolicy: 'relay'

and to use the server-provided TURN credentials. Which option would you like to pursue — keep default ports open, proxy to 443, or use an external TURN? , with interactive elements