I want to use livekit (self hosted on aws eks) on a corporate network. The corporate network is private and connected to aws via direct connect. The security team is not allowing to open range of udp port 50000-60000 in firewall due to security concerns. What are my other options ?

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 possible to make it work with only few udp ports enabled ?

Thanks — I’m replying to your question about whether LiveKit can work with only a few UDP ports enabled instead of the full 50000–60000 range. Short answer: yes. You can run LiveKit with a small UDP port range (even a single port) and rely on TCP/TLS TURN as a fallback. Below are practical recommendations and what to check. What to do • Limit LiveKit’s UDP port range ◦ Configure your LiveKit media nodes to advertise and use a small UDP range (you can use a single UDP port like 7882 or a small range). This reduces the surface that must be opened in the firewall while still allowing direct UDP media when possible. ◦ Keep in mind that a single UDP port works for smaller deployments or low concurrent peer counts; larger concurrency benefits from a broader range. • Provide TURN over TCP/TLS (port 443) as a fallback ◦ Enable TURN on your LiveKit media nodes and ensure it’s reachable on TCP/443 so clients can relay media if UDP is blocked or limited. ◦ Clients will automatically fall back to TURN/TCP when UDP connectivity fails. You can also force TURN by setting the client ICE policy to relay: set

iceTransportPolicy: 'relay'

in your client rtc configuration to test or ensure TURN is used. Practical checklist 1. Select the UDP port(s) you will allow (for example, 7882 or a small range). 2. Configure LiveKit media node(s) to use and advertise that port/range. 3. Enable embedded TURN and expose it on TCP/443 (TLS) so corporate firewalls allow media relays. 4. If using Direct Connect/private endpoints, advertise private ICE candidates so traffic stays on the private network. 5. If a corporate DPI/proxy (e.g., ZScaler) inspects traffic, add bypass rules for your LiveKit/TURN domains to avoid breaking encrypted WebRTC traffic. 6. Test from inside the corporate network and inspect ICE logs to verify UDP direct connections when possible and TURN/TCP when not. When a small UDP range can be a problem • If you expect high concurrency or many simultaneous media sessions, a single UDP port may become a bottleneck; a slightly larger but still-restricted range helps throughput. • If corporate proxies perform TLS interception or deep protocol inspection, TURN over TCP/443 may still be blocked unless you add bypass/exemption rules. If you want, I can: • Provide the exact LiveKit server YAML snippet to restrict the UDP port range. • Provide a client snippet showing

iceTransportPolicy: 'relay'

and WSS configuration for testing. • Help decide an appropriate small UDP range based on expected concurrent sessions. Which would you like next — the server YAML snippet, a client example, or guidance on picking a UDP range for your expected concurrency? Sources: Running LiveKit on AWS | Firewall Tips for LiveKit Connectivity | LiveKit

is this list fine

Thanks — I can review that for you. Can you paste the specific list or configuration you want me to check (firewall rules, UDP ports, TURN endpoints, and any proxy/DNS exceptions)? Once I see it I’ll: • Confirm whether it’s sufficient for typical LiveKit deployments. • Point out any missing ports, TURN or signaling entries, and proxy/DPI considerations. • Suggest exact LiveKit server/client config snippets if you want.

TCP 443 TCP 7880 TCP 7881 TCP 443 UDP 3478 UDP 3479 UDP 7882 TCP 7880 TCP 7881 TCP 443 UDP 3478 UDP 3479 UDP 7882

Thanks — I reviewed the list you pasted. I’ll respond to your question: “is this list fine?” and point out what’s correct, what’s redundant, and what’s missing for reliable LiveKit operation in a restrictive corporate environment. Summary of your list (cleaned): • TCP 443 • TCP 7880 • TCP 7881 • UDP 3478 • UDP 3479 • UDP 7882 What’s correct • TCP 443 — required. Used for WSS signaling and TURN over TLS (recommended fallback when UDP is restricted). • TCP 7880 — used for LiveKit signaling (WebSocket) in self-hosted setups. Keep it if your setup uses this port for signaling. • TCP 7881 — used for agent/health endpoints (useful for monitoring agents); include if you run Agents and want health checks. • UDP 7882 — the default UDP media port LiveKit uses; keep it if you want to allow some direct UDP media. What’s redundant or duplicated • Your original list contained duplicate blocks of the same ports — you only need to list each port once. What’s risky / likely insufficient • UDP 3478/3479 — these are typical STUN/TURN ports, but simply opening these two UDP ports is not sufficient to guarantee direct WebRTC media. WebRTC media often uses ephemeral UDP ports (large ranges) for RTP. Restricting to only a few UDP ports can work for small deployments or limited concurrency, but it can break or limit direct UDP media in many real-world cases. • If you expect higher concurrency or many simultaneous peer connections, a single UDP port (or just 3478/3479/7882) can become a bottleneck. Recommended approach for strict firewalls • If your security team will not open a wide UDP range, force TURN over TCP/TLS on port 443 so all media is relayed over TCP/443 (no large UDP range required). This is the most reliable enterprise-friendly option. ◦ Client-side test/force: set

iceTransportPolicy: 'relay'

in the client rtc config to force use of TURN. ◦ Ensure TURN is available on TCP 443 and that the firewall/proxy allows outbound TCP 443 to your TURN endpoint. • Prefer domain-based allowlisting rather than relying only on ports: ◦ Whitelist your LiveKit domain(s) and TURN domain (for example,

*.livekit.cloud

or your private domain) in proxy/DNS rules. ◦ If your corporate proxy uses DPI (e.g., ZScaler), add bypass rules for LiveKit/TURN domains so protocol inspection doesn’t break encrypted WebRTC/TURN traffic. Concrete recommended firewall rules (minimal, secure): • Allow outbound TCP 443 to your LiveKit/TURN domain(s) (required). • Allow inbound/outbound TCP 7880 (signaling) to your LiveKit host(s) if you use that port. • Allow inbound/outbound TCP 7881 if you need agent/health access. • Option A (allow limited UDP direct media): Allow UDP 7882 (and optionally UDP 3478/3479 for STUN), understanding this may be insufficient at scale. • Option B (recommended for strict policies): Block UDP media and rely on TURN/TCP 443 — no wide UDP range needed. If you want, I can: • Provide the exact LiveKit server YAML snippet to restrict/advertise a specific UDP port (e.g., 7882). • Provide a client snippet showing

iceTransportPolicy: 'relay'

and WSS configuration for testing TURN/TCP. • Help decide a small UDP range if you need some UDP for performance but want to keep the surface minimal (tell me expected concurrent sessions). Which would you like next — a server YAML example, the client config snippet, or guidance on picking a small UDP range? Sources: Firewall Tips for LiveKit Connectivity | LiveKit | server-sdk-js | livekit/livekit_composite | DeepWiki | Self-hosted deployments | LiveKit Documentation | Running LiveKit on AWS | Configure ZScaler proxy for LiveKit connections | LiveKit

• Provide the exact LiveKit server YAML snippet to restrict/advertise a specific UDP port (e.g., 7882). • Provide a client snippet showing

iceTransportPolicy: 'relay'

and WSS configuration for testing TURN/TCP. yes please

Thanks — below are the exact config snippets you asked for plus short notes on where to change values. This will let your LiveKit media nodes advertise a single UDP port (7882) and force clients to use TURN over TCP/TLS (port 443) for testing in restrictive corporate networks. Important notes before you apply: • Replace placeholder domains, certificate paths, and tokens with your real values. • For production, ensure TLS certs are valid for the domain you expose to clients. • If your corporate proxy performs DPI (e.g., ZScaler), add proxy bypass rules for your LiveKit/TURN domains so protocol inspection doesn’t break TURN/TLS. 1) LiveKit server YAML — restrict UDP to port 7882 and enable TURN over TLS (443)

# livekit.yaml
# Basic server listening port (signaling)
port: 7880

# Bind addresses; leave empty to bind all interfaces or set specific private IPs
bind_addresses:
  - ""

rtc:
  # Restrict UDP port usage to a single port
  port_range_start: 7882
  port_range_end: 7882

  # Optional: TCP port used for WebRTC TCP fallback (if desired)
  tcp_port: 7881

  # TURN server settings (embedded TURN using TLS)
  turn_server:
    enabled: true
    # domain exposed to clients for TURN/WSS (use your DNS name)
    domain: <http://your-livekit-domain.example.com|your-livekit-domain.example.com>
    # TLS cert + key used for TURN/TLS on 443
    cert_file: /etc/ssl/certs/fullchain.pem
    key_file: /etc/ssl/private/privkey.pem
    # Expose TURN TLS on 443
    tls_port: 443
    # Keep the UDP port entry if you allow UDP 7882 for direct media
    udp_port: 7882

Firewall summary for this setup (minimal): • Allow outbound TCP 443 to your TURN domain (clients -> TURN/TLS). • Allow inbound/outbound TCP 7880 to your LiveKit signaling host (if signaling runs on that port). • Allow inbound/outbound TCP 7881 if you use the rtc tcp fallback/agent endpoints. • Allow UDP 7882 if you want to permit direct UDP media on that single port; otherwise UDP can be blocked and all media will use TURN/TCP 443. 2) Client snippet (TypeScript) — force TURN/TCP (relay) and use WSS for signaling

import { Room } from "livekit-client";

// Example connect options to force TURN relay via TCP/TLS (port 443)
const connectOptions = {
  rtcConfig: {
    // Force usage of TURN (no direct P2P/UDP)
    iceTransportPolicy: 'relay',
    // Explicitly list TURN servers (use your TURN domain if self-hosted)
    iceServers: [
      {
        urls: [
          // secure TURN over TLS/TCP on 443
          'turns:<http://your-livekit-domain.example.com:443?transport=tcp|your-livekit-domain.example.com:443?transport=tcp>',
          'turn:<http://your-livekit-domain.example.com:443?transport=tcp|your-livekit-domain.example.com:443?transport=tcp>'
        ],
        // if your TURN requires username/password, include them here
        // username: 'turn-username',
        // credential: 'turn-credential'
      }
    ]
  },
  // Optional client-side settings
  websocketTimeout: 10000,
  autoSubscribe: true
};

// Connect over WSS (signaling) — replace domain and token
const wsUrl = '<wss://your-livekit-domain.example.com>';
const token = 'YOUR_ACCESS_TOKEN';

const room = new Room();

try {
  await room.connect(wsUrl, token, connectOptions);
  console.log('Connected and using TURN/TCP (relay) over TLS');
} catch (err) {
  console.error('Connection failed', err);
}

What to test and verify • From a client on the corporate network, run the connection and inspect ICE candidate logs in the browser devtools. You should see TURN candidates and the selected candidate should indicate relay over TCP/TLS. • If connection fails, confirm: ◦ TCP 443 to your TURN domain is allowed outbound. ◦ WSS (TCP 443) to your signaling domain is allowed. ◦ Your TLS certs are valid and match the domain the client connects to. ◦ If a proxy/DPI is in place, add domain bypass rules (example for ZScaler): url.domain=turn.livekit.cloud detect_protocol(no) url.domain=your-livekit-domain.example.com detect_protocol(no) If you want, I can now: • Provide the exact LiveKit YAML snippet tailored to your existing values (domain names, cert paths). • Provide a minimal TURN credential generation example and where to plug username/credential into the client snippet. Which one would be most helpful next? Sources: Firewall Tips for LiveKit Connectivity | LiveKit | Configure ZScaler proxy for LiveKit connections | LiveKit

when using fallback tcp any issues ? have there been users using it reliably in their deployment

Thanks — I’m addressing your question about using TCP fallback (TURN over TCP/TLS, usually on port 443): whether it’s reliable and if others use it successfully in production. Short answer • Yes — TURN over TCP/TLS on port 443 is a reliable, commonly used solution for corporate networks that block UDP. It’s the recommended approach when firewalls prevent opening large UDP ranges. Why it’s reliable • TURN/TCP on 443 looks like normal HTTPS traffic to firewalls and proxies, so it reliably passes where UDP is blocked. • LiveKit clients and servers implement transport fallback logic: if direct UDP or TCP can’t be used, clients fall back to TURN (and ultimately TURN/TLS), so connections recover automatically in restrictive networks. • This approach is documented for corporate firewall scenarios and is used in production deployments where organizations require strict egress rules. Known trade-offs and caveats • Latency and throughput: relaying media through a TURN server over TCP generally increases latency and can reduce throughput compared to direct UDP peer/SFU paths. Expect somewhat higher end-to-end latency and more server bandwidth usage. • Server load and costs: TURN relays all media, so your media nodes (or dedicated TURN server) will carry the bandwidth that would otherwise be peer-to-peer. Plan capacity accordingly. • Proxy/DPI issues: Some enterprise proxies (e.g., ZScaler) may inspect or break TURN/TLS unless you add domain bypass rules. If you see failures even though TCP 443 is allowed, check for DPI interception and add proxy bypasses for your LiveKit/TURN domains. • Rare UDP fallbacks inside media nodes: in some setups, embedded media components may still try UDP internally; if UDP is blocked on those paths, ensure your TURN/TLS config is correct and reachable. Best practices to run TURN/TCP reliably • Force relay during testing or for restricted clients: set

iceTransportPolicy: 'relay'

in the client to ensure TURN is used. • Expose TURN on TCP/443 with valid TLS certs and allow outbound TCP 443 to that domain from client networks. • Whitelist by domain (your LiveKit/TURN domain) and add proxy/DPI bypass rules if your corporate stack inspects traffic. • Monitor and size TURN/media nodes for the extra bandwidth and concurrent sessions you expect. • Test end-to-end from inside your corporate network and confirm ICE candidate selection in browser devtools (you should see relay candidates selected). If you’d like, I can: • Provide a short checklist for capacity planning (bandwidth per concurrent user) based on your expected concurrency. • Help you generate a TURN credential example and where to plug it into client code. • Review your corporate proxy/DPI rules and suggest exact bypass entries for your domain. Which of those would be most useful next? Sources: Firewall Tips for LiveKit Connectivity | LiveKit | Firewall Tips

is there any impact of using kong as proxy

Thanks — I’ll address whether using Kong as a proxy will cause issues with a LiveKit deployment and what to watch for. I’ll keep it practical so you can map it to your setup quickly. Short answer • Kong can proxy LiveKit signaling (WSS) safely if configured correctly. • Problems arise if Kong is used for TURN/media traffic (non-HTTP protocols) or if it applies buffering, short timeouts, or DPI that interferes with WebSocket/TURN/TLS. In most deployments, best practice is to let TURN/media traffic bypass Kong. What to verify / configure 1) Signaling (WSS) via Kong • Ensure Kong supports WebSocket upgrade and passes binary frames unchanged. • Increase idle/keep-alive timeouts (WebSocket connections are long-lived). Default short timeouts can drop connections. • Avoid request/response buffering or body inspection on the WSS route. • TLS termination is OK at Kong for signaling, but ensure certs are valid and match client domains. 2) TURN and media traffic • TURN over TCP/TLS (port 443) is the recommended fallback through firewalls. TURN traffic ideally goes directly to your TURN endpoint (e.g., your TURN domain or turn.livekit.cloud). • Kong (L7 HTTP proxy) typically cannot proxy raw TURN (non-HTTP) unless you use Kong Gateway’s Stream/TCP proxying features. If you try to route TURN through Kong without stream support, TURN will likely fail. • Recommendation: do not route TURN/media through Kong unless you explicitly enable TCP stream routing and have tested it thoroughly. 3) Proxy behavior that can break real-time flows • Timeouts: set long idle timeouts for WebSocket routes so they aren’t dropped. • Buffering/inspection: disable body inspection/modification and turn off buffering on WSS routes. • DPI/interception: if Kong or an upstream component performs deep packet inspection (or TLS interception), TURN/TLS can be broken. Add bypass rules for TURN domains in your DPI appliance or avoid terminating TURN TLS at the proxy. 4) TLS termination and certificate handling • If Kong terminates TLS for signaling, make sure the internal channel to LiveKit is secure/trusted. • For TURN/TLS, clients must see a valid cert for the TURN domain. If TLS is intercepted by enterprise proxies, TURN may fail unless the proxy is configured to allow it. 5) Monitoring and testing • Test from inside the corporate network and inspect browser devtools for ICE candidate types (should see relay candidates when using TURN). • Monitor connection drop rates, latency, and resource usage on TURN/media endpoints since relaying increases server bandwidth. • If you must route TURN via Kong, smoke-test with Kong’s stream/TCP proxying and verify large-file / continuous media flows. Practical recommendations • Use Kong for HTTP/WSS signaling only (token endpoints, API gateway, WSS passthrough), with WebSocket upgrades enabled and long timeouts. • Let TURN/TLS (port 443) be reachable directly by clients to the TURN domain (or configure Kong Stream/TCP proxying only if you have strong reasons and can verify behavior). • Add domain-based bypasses for any enterprise DPI product (e.g., ZScaler) so TURN domains aren’t inspected. • Validate end-to-end by forcing relay (

iceTransportPolicy: 'relay'

) and ensuring clients successfully establish media over TURN/TCP 443. If you want, tell me: • Which Kong edition are you using (OSS vs Gateway/Enterprise)? • Are you planning to proxy signaling only, or also TURN/TCP via Kong? With those details I can give a concrete Kong route/example (including timeout settings and stream config if you need TURN proxied). Sources: Diagnosing Connection Errors with the Connection Test Utility | LiveKit | Client SDKs | livekit/livekit_composite | DeepWiki | Firewall Tips for LiveKit Connectivity | LiveKit | Best practices for managing webhook event streams | LiveKit | Configure ZScaler proxy for LiveKit connections | LiveKit

if I going with tcp as fallback - what all ports need to be open

Thanks — I’ll list exactly which ports you need to allow when you rely on TCP fallback (TURN over TCP/TLS) for LiveKit, plus optional ports you may want for monitoring or partial UDP media. I’ll keep it concise and tell you which ports are mandatory vs optional. Mandatory (for a deployment that uses TURN over TCP/TLS as the media fallback) • TCP 443 (outbound from clients to TURN endpoint and signaling if using WSS on 443) ◦ Purpose: TURN over TLS (turns/turn with transport=tcp) and WSS signaling when signaling is served on 443. ◦ Ensure clients can reach your TURN domain (e.g., your TURN host or

turn.livekit.cloud

) on TCP 443. • TCP 7880 (inbound/outbound between clients and your LiveKit signaling host) — if your LiveKit signaling is on 7880 ◦ Purpose: LiveKit WebSocket signaling (WSS) when not served on 443. ◦ If you serve signaling on 443 instead, this is not required. Optional / recommended (depending on your deployment) • TCP 7881 ◦ Purpose: agent/health endpoints and optional WebRTC TCP fallback port inside LiveKit. ◦ Include if you run Agents or want the TCP fallback listener there. • UDP 7882 (optional) ◦ Purpose: direct WebRTC media over UDP if you want to allow limited UDP. You can keep this for direct media when UDP is permitted. ◦ Note: a single UDP port may work for small deployments but can be a bottleneck at scale. • UDP 3478 / UDP 3479 (optional) ◦ Purpose: STUN/TURN UDP. Helpful only if you intend to allow some UDP STUN/TURN. Not required when using TURN/TCP exclusively. Domain-based and proxy considerations (important) • Whitelist domains rather than only ports where possible: ◦ your LiveKit domain (e.g.,

<http://your-livekit-domain.example.com|your-livekit-domain.example.com>

) ◦ your TURN domain (e.g.,

turn.livekit.cloud

or your TURN host) • If a corporate proxy/DPI (like ZScaler) is present, add bypass rules for your LiveKit/TURN domains so TLS inspection doesn’t break TURN/TLS: ◦ Example:

url.domain=turn.livekit.cloud detect_protocol(no)

and

url.domain=<http://your-livekit-domain.example.com|your-livekit-domain.example.com> detect_protocol(no)

Summary checklist for a strict TCP-fallback setup 1. Allow outbound TCP 443 to your TURN domain (required). 2. Allow WSS (TCP 443) to your signaling domain, or TCP 7880 if signaling runs there (required depending on your setup). 3. Optionally allow TCP 7881 for agent/health or internal TCP fallback. 4. Optionally allow UDP 7882 / UDP 3478/3479 only if you want partial UDP direct media; not necessary if you force TURN/TCP relay. 5. Whitelist domains and add proxy/DPI bypasses as needed. If you tell me: • Are you serving signaling on 443 or 7880? • Are you planning to keep any UDP port(s) open (e.g., 7882) or block UDP entirely? I’ll give a final minimal firewall rule set you can hand to your security team.

what is the benifit of this

Good question — I’ll explain the concrete benefits of keeping a small UDP port (e.g., 7882) open versus blocking UDP entirely, and when you might choose each approach. Key benefits of keeping UDP (even one port) open • Lower latency: UDP avoids TCP head‑of‑line blocking and retransmission behavior, so media packets arrive faster. That improves perceived interactivity for real‑time audio/video. • Better media quality and throughput: WebRTC over UDP handles jitter and packet loss with media‑specific strategies (e.g., selective retransmits) that preserve quality more effectively than TCP relays. • Less server/TURN load: When UDP is available, clients can connect directly to the SFU or use TURN/UDP rather than relaying all media over TURN/TCP. That reduces bandwidth on your TURN/media nodes and lowers operational cost. • Faster ICE negotiation / more direct paths: ICE prefers ICE/UDP first. Allowing UDP increases chance of direct or optimal SFU paths, reducing connection setup time and improving reliability. • Scalability: Direct UDP media paths scale better than forcing every session through TURN/TCP, which must handle every packet for every user. Trade-offs and why you might block UDP • If security policy forbids any UDP, using TURN/TLS (TCP 443) ensures connectivity through restrictive firewalls — it’s reliable for connectivity but has downsides: ◦ Higher latency and potentially worse media quality. ◦ Increased bandwidth and cost on TURN/media servers because they relay all media. ◦ Possible issues with corporate DPI/proxy unless you add domain bypasses for TURN domains. When a single UDP port (like 7882) is appropriate • Small deployments or lower concurrency where you want better quality but the security team will only open a minimal surface. • Hybrid approach: allow UDP 7882 for best-effort direct media, but keep TURN/TCP(443) as a guaranteed fallback. When to block UDP entirely • Strict security policy that disallows UDP; accept the performance and cost trade-offs and force relay with client setting

iceTransportPolicy: 'relay'

. Practical recommendation • Best balance: allow UDP 7882 (or a small range) plus TURN on TCP 443. This gives optimal performance when possible and reliable fallback when UDP is blocked. • If policy mandates no UDP, plan capacity for TURN (bandwidth, CPU) and ensure TLS/TURN endpoints are whitelisted and bypassed from DPI. If you want, I can: • Produce a minimal firewall rule set you can hand to security for the “allow UDP 7882 + TURN/TCP443” option. • Estimate TURN bandwidth needs if you tell me expected concurrent users and average bitrate. Which would you like next? Sources: How We Built a Globally Distributed WebRTC Mesh Network | Firewall Tips for LiveKit Connectivity | LiveKit | Running LiveKit on AWS | Configure ZScaler proxy for LiveKit connections | LiveKit

Purpose: STUN/TURN UDP. Helpful only if you intend to allow some UDP STUN/TURN. Not required when using TURN/TCP exclusively - waht is this

Great question — I’ll explain that sentence in plain terms and show why UDP STUN/TURN ports are optional when you use TURN over TCP/TLS. What STUN/TURN UDP does • STUN (Session Traversal Utilities for NAT) on UDP helps clients discover their public IP/port and often assists in establishing direct peer-to-peer or SFU connections using UDP. • TURN (Traversal Using Relays around NAT) on UDP relays media when direct UDP paths fail. Both are commonly used over UDP because WebRTC prefers UDP for real‑time media. What “Not required when using TURN/TCP exclusively” means • If you force clients to always use TURN over TCP/TLS (typically on port 443), clients will send and receive media through a TURN server via TCP (encrypted with TLS). In that mode: ◦ They do not need UDP STUN/TURN ports to be open to establish or relay media. ◦ ICE will select the TURN/TCP (relay) candidate and never try UDP candidates, so opening UDP ports such as 3478, 3479, or 7882 becomes unnecessary for connectivity. • In short: TURN over TCP/TLS replaces the need for UDP-based STUN/TURN because all signaling and media go over TCP/TLS connections. Why you might still allow UDP STUN/TURN • Performance: UDP is faster and better for media (lower latency, less head-of-line blocking). • Efficiency: If UDP is available, clients can use ICE/UDP or TURN/UDP, reducing load on TURN servers and improving media quality. • Redundancy: Allowing UDP lets clients use the best available path (UDP first) and only fall back to TCP if needed. When to choose each approach • Allow UDP ports (recommended when possible): Best media quality and lower server load. Open ports like UDP 7882 (or a small range) plus STUN/TURN UDP if security permits. • Block UDP and use TURN/TCP only: Required if security policy forbids UDP. Works reliably for connectivity but increases latency, degrades some media characteristics, and raises TURN bandwidth/cost. If you want, I can: • Give a minimal firewall rule set for both approaches (UDP-allowed vs UDP-blocked). • Show how to force relay on the client (

iceTransportPolicy: 'relay'

) for TURN/TCP-only testing.