WebRTC configuration

The WebRTC tab under Configuration → WebRTC is where administrators tune how Sky View negotiates peer connections.

WebRtc configuration form

UI control Purpose Default / environment variable
ICE servers Defines the STUN/TURN servers advertised to browsers. The dialog expects a JSON array compatible with the standard RTCIceServer structure. The backend validates the JSON before using it to configure the WebRTC server. Default: ["stun:stun.l.google.com:19302"].
Loopback ICE candidate Adds a 127.0.0.1 candidate for local testing. Disable this in production when remote peers must not see loopback addresses. Default: true.
Keep host candidates Controls whether LAN interface candidates remain available to peers. Turn this off when exposing only relayed addresses is required. Default: true.
Use full ICE Switches the server from ICE-Lite to full ICE, allowing two-way connectivity checks. Leave enabled when interacting with browsers that expect full ICE support. Default: true.
Force relay Forces all media traffic through TURN relays, which can simplify firewall traversal at the expense of latency and bandwidth costs. Default: false.
Enable 1:1 NAT mapping Advertises a public IP that maps 1:1 to the server. When enabled you must supply the public IP field below; the server falls back to the CLI --publicIp flag if the UI value is blank. Default: false.
Public IP Specifies the address advertised when NAT 1:1 mapping is on. Eenter the routable IP visible to peers. Default: empty.
Ephemeral UDP ports Restricts the UDP port range used for host and server-reflexive (srflx) ICE candidates. When enabled, you must specify both minimum and maximum port values. This is useful for configuring firewall rules to allow only specific UDP ports. Default: false.
Min UDP port The lowest UDP port number to use when ephemeral UDP ports are enabled. Must be between 1024 and 65535. Default: empty.
Max UDP port The highest UDP port number to use when ephemeral UDP ports are enabled. Must be between 1024 and 65535 and greater than or equal to the minimum port. Default: empty.
Enable WebRTC debug page Exposes Debug → WebRtc Debug in the navigation so authenticated users can inspect offers/answers. Useful during deployments; hide it in production environments. Default: false.

Runtime application of changes

When you press Save, the backend decides whether it can update the WebRTC server in-place or needs to restart it. Toggles that affect ICE gathering or candidate advertisement (ICE servers JSON, loopback/host candidates, full ICE, force relay, NAT 1:1, public IP, and ephemeral UDP port range) trigger a controlled restart of the embedded WebRTC server. The restart briefly stops active pipelines and then recreates them with the new settings. In contrast, enabling the WebRTC debug page is applied immediately without a restart.

Interaction with other configuration sources

  • Environment variables seed the defaults listed above at startup. Setting them is a convenient way to preconfigure new deployments before the UI is available.
  • Command-line flags (--loopbackIceCandidate, --fullIce, --forceRelay, --nat1to1Enabled, --publicIp) act as fallbacks that the runtime uses if no value is persisted yet. This is particularly useful when running Sky View without the configuration UI.
  • Runtime updates made in the UI are persisted through the settings service, so subsequent restarts reuse your saved values unless you change the environment/flags. Whenever a restart is required, the application tears down and recreates active pipelines automatically to apply the new WebRTC configuration safely.

💡 By understanding the impact of each field you can tailor WebRTC connectivity for different network topologies—from local lab testing with loopback candidates to hardened production deployments that rely exclusively on TURN relays.

Debugging WebRtc

Use the WebRtc debug console to troubleshoot connectivity or playback quality issues, or to inspect connection methods and statistics.