A Linkside room can open and a guest can join before the screen stream has found a working route. Room setup and screen sharing use separate connections: Linkside’s signaling service creates the room and exchanges connection details, while the screen travels over a browser-to-browser WebRTC connection.
Linkside is peer-to-peer first, not peer-to-peer only. It tries to connect each guest directly. An encrypted TURN relay is also available to eligible free rooms when a direct route cannot connect. The session tells you what happened, so you do not need to work out how the venue’s network is configured.
Before the call
If the venue presents a sign-in page, complete it first. Then make sure both the host and the guest can open Linkside. A TURN relay can carry media inside a working Linkside session, but it cannot provide access to the site or the signaling service.
Use desktop Chrome or Edge on the computer that will share. They are Linkside’s recommended host browsers. There is nothing to install, and neither person needs an account.
Then create a Linkside room, send the invite link, and wait for the guest to join before you start sharing. Linkside supplies relay connection details when the room opens and guests join. Each connection can use that route if it cannot connect directly.
When the relay fallback engages
Linkside tries the direct route first
By default, Linkside tries a direct browser-to-browser media route for each guest. The signaling service helps the browsers connect, but it does not carry the screen stream.
Each guest has a separate connection. One guest may connect directly while another uses the available relay. Connection details can therefore show that all guests are direct, all are relayed, or the room has a mixture of both routes.
For a plain-language explanation of the two routes, see STUN vs TURN.
Check the route each guest uses
The browsers choose from the available direct and relay routes. Relay connection details arrive at room creation and joining; there is no four-second relay-request step to wait for after a failure. A room opening successfully still does not prove that either media route can connect.
Relay setup is automatic, but a working media route is not guaranteed. Watch the connection ledger: Relayed identifies a connection using the relay, and a free relay countdown shows its remaining video time. When that video time ends, the screen says Video paused. Voice is still on. and offers Keep it going. If the total free relay allowance is exhausted, it says Free relay time is up. If a relay is unavailable, read the connection status and use Try again if offered; there is no separate relay-unavailable banner.
Open Connection details in the session menu to see the route actually selected for each guest. Linkside labels it Direct peer-to-peer, Relayed through server, or, for a mixed room, Some guests are direct, some are relayed. The P2P network test explains how to run a two-device check before an important share.
What using the relay means
The route changes; the encryption does not
On a direct route, encrypted media packets travel from the host’s browser to the guest’s browser. On a relayed route, the same encrypted packets pass through the TURN relay on their way to the guest.
The browser uses DTLS-SRTP encryption on both routes. The relay forwards the packets but does not have the media keys needed to read the screen. For a closer look at this boundary, read how Linkside encrypts screen sharing.
Some operational details remain visible
Private does not mean invisible to every part of the network. Linkside’s signaling worker can observe that a room exists, roughly when guests join, and how long the session lasts. When a relay route is used, the TURN relay observes where encrypted packets are routed, and Cloudflare’s edge sees IP-level traffic to the relay endpoints.
Neither the signaling worker nor the TURN relay sees the screen content. Linkside does not record sessions or keep persistent chat logs. The room disappears after the session ends.
Free relay time is limited
An eligible free room has five minutes of relay video. The room’s clock starts when a browser first reports that it is using the relay, not when connection details are first issued. After that video window, relayed guests keep a blurred last frame while voice can continue for up to two more hours of accrued relay use. Direct-connected guests keep their video, and the host preview stays live. A Pass restores relayed video without reconnecting.
The connection ledger shows the remaining free video time. Any admitted participant can add a Pass to the room; a guest waiting for approval must first be admitted.
A public-Wi-Fi checklist
- Join the hotel or cafe network and complete its presented sign-in step.
- Confirm that Linkside loads in both the host and guest browsers.
- Create the room, send the link, and wait for the guest to join.
- Select Pick what to share and watch each guest’s connection status. Relay connection details are already available; there is no relay-activation button.
- If a guest’s connection shows Relayed, that guest is using the relay. A free relay countdown shows the remaining video time.
- Open Connection details to confirm the selected route for each guest. Do not infer it from the Wi-Fi name or the timing of the status messages.
If the screen still does not appear, confirm that both browsers can reach Linkside and read the status message before retrying. If neither route works, move one device to another connection and run the check again.
A loaded room confirms access to signaling, not a working screen stream. Direct peer-to-peer or Relayed through server in Connection details confirms the selected media route. That is the check that matters before an important call.