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. If that attempt fails in an eligible free room, Linkside can add an encrypted TURN relay as another available route. 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. If the direct route fails, Linkside can request the free relay only while the host is sharing, at least one guest is present, and none of the host-to-guest connections is still connected.
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. Even after Linkside makes a relay available and rebuilds the connections, one guest may connect directly while another uses the 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.
Linkside reacts to a failed connection
When a host-to-guest connection reports a failure, Linkside waits four seconds before requesting the free relay. If the connection recovers during that window, Linkside cancels the request. Otherwise, it checks the relay requirements again, requests TURN credentials, rebuilds the host connections, and restarts sharing to the active guests.
The request is automatic, but relay availability is not guaranteed. The host sees Activating relay server… during the request and rebuild. Premium relay active means the relay is available to the connections and the trial clock is running. Trial relay limit reached means the room has already used its trial or the per-IP limit has been reached. Relay server unavailable means Linkside could not provide the relay for that attempt.
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 can use one five-minute relay trial. Trial requests are also limited to one per IP address in a two-hour window. The five minutes start when the trial credentials are granted, not when the room opens. A licence unlocks unlimited relay use.
The host sees the remaining time in the session. If you need more than five minutes, or cannot risk the venue’s public IP having reached the two-hour limit, arrange licensed relay access before the call.
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.
- Start sharing and watch the status area. Linkside waits for a connection failure before beginning its four-second relay delay.
- If Premium relay active appears, the relay is available and the free-trial clock is running.
- 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. Creating another room does not bypass the one-trial-per-IP, two-hour limit. 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.