Connection Model

The connection has two phases

EnderDash does not connect the browser directly to the agent in one step.

It works in two phases:

1. Signaling: the browser and the agent exchange setup information through the signaling service.
2. Media and data path selection: WebRTC tests candidate IP and port pairs until it finds a usable route.

That is why a server can be registered successfully even when the final browser-to-agent path still needs networking work.

Direct connectivity and relay are different outcomes

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

When they cannot, EnderDash can fall back to TURN relay. Relay is usually slower, but it keeps the product usable on 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 connectivity depends on the candidate ports the runtime exposes

Why fixed port ranges exist

Without extra configuration, the agent can choose candidate ports dynamically. That is convenient, but it makes firewall rules harder to predict.

restrictPorts, webrtcMinPort, and webrtcMaxPort exist so operators can trade flexibility for predictable firewall behavior.

Why public-address advertisement exists

The agent tries to discover its own public IP automatically. In some NAT layouts that is enough. In others, the reported address is wrong or the lookup is blocked.

advertisePublicAddress and publicAddress exist so operators can override that value when they need a stable and correct external address for candidate generation and troubleshooting.

What to read next

• Use Recover an Offline Server if you are fixing a real connectivity problem.
• Use Network Requirements if you need exact hostnames and ports.