Connection Model

The connection has two phases

A browser-to-agent connection uses two phases:

1. Signaling: The browser and agent share connection details through the signaling service.
2. Path selection: WebRTC tries IP addresses and ports until it finds a working route.

Successful signaling does not mean that the browser can connect to the agent.

Direct and relayed connections are different

If the browser and agent can reach each other, EnderDash uses a direct WebRTC data channel.

If a direct route fails, EnderDash can use a TURN relay. A relay is usually slower, but it works on more restrictive networks.

This distinction matters because:

• signaling success does not guarantee direct connectivity
• a domain allowlist is often enough for signaling, but not for direct peer-to-peer traffic
• direct connections depend on the ports that the runtime offers

Signaling relay fallback

EnderDash also supports protobuf RPC through the signaling service when the WebRTC transport is unavailable. This WebSocket fallback is different from TURN, which relays WebRTC traffic. The signaling service also provides an HTTP transport for supported unary calls.

Connection diagnostics distinguish the signaling connection from the live RPC transport. Use a live panel or operation to verify that the complete path works.

Why fixed port ranges exist

By default, the agent selects ports when it starts a connection. These changing ports make firewall rules harder to configure.

The restrictPorts, webrtcMinPort, and webrtcMaxPort values set a fixed port range. You can then create clear firewall rules for that range.

Why you can set a public address

The agent tries to find its public IP. Some NAT setups return the wrong address or block the request.

Use advertisePublicAddress and publicAddress to set the external address. WebRTC then offers this address when it starts a connection.

What to read next

• To fix a connection problem, use Recover an Offline Server.
• For exact hosts and ports, use Network Requirements.