Five stair-stepped panes joined by one orange thread that ends bridging two browser windows

When you click Share in a browser screen-sharing tool, your screen is not simply uploaded to a meeting server. A few things happen in order: your browser asks what you want to share, Linkside helps your browser and the viewer’s browser exchange setup messages, the browsers look for a network path, and WebRTC encrypts the media before any screen frames move.

That sequence matters if you are deciding whether to trust Linkside. Linkside is peer-to-peer first: it tries to send media directly from browser to browser. If the network blocks that direct route, it can fall back to an encrypted TURN relay. In both cases, the browser handles WebRTC media encryption, and Linkside does not record the session.

The cast

Three pieces are involved in every Linkside session:

  • Host browser - the one sharing the screen.
  • Guest browser - the one watching.
  • Signaling service - the Linkside service that helps the two browsers exchange setup messages.

Sometimes there is a fourth piece:

  • TURN relay - a fallback path when the browsers cannot reach each other directly.

The signaling service is not the screen-sharing pipe. It helps set up the call. Once WebRTC connects, media flows over the selected WebRTC path: direct browser-to-browser when possible, or through the encrypted relay when direct networking fails.

Step 1: capture the screen

When the host clicks Share, the page calls navigator.mediaDevices.getDisplayMedia({ video: true, audio: true }). The browser shows its own picker (tab / window / screen), the user chooses a surface, and the browser hands back a MediaStream.

This is an important trust boundary. The browser prompts you before capture starts. Linkside only gets the resulting media tracks after you choose what to share.

Step 2: create the peer connection

Now there is a stream to send, but no viewer connection yet. The host creates an RTCPeerConnection, configured with the ICE servers the browser can use to find a path:

const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    { urls: 'stun:stun.cloudflare.com:3478' },
    { urls: 'stun:stun1.l.google.com:19302' },
    // TURN servers are added when relay credentials are available.
  ],
});

for (const track of stream.getTracks()) {
  pc.addTrack(track, stream);
}

Adding tracks tells WebRTC what the host wants to send. It does not mean the screen is flowing yet. The two browsers still need to agree on the session and find a working route.

Step 3: build the offer

The host calls pc.createOffer(). The browser looks at the tracks, supported codecs, transport details, and encryption parameters, then produces an SDP offer.

Think of the offer as a proposal, not the media itself. It says: “Here is what I can send, here is how this session should be configured, and here is the information you will need to answer.” pc.setLocalDescription(offer) stores that proposal in the host’s peer connection and moves the host into the offer side of WebRTC negotiation.

Step 4: send the offer through signaling

The offer needs to reach the guest. The two browsers cannot use the media path yet, because ICE has not found one. So the host sends the offer through Linkside’s signaling service, which relays it to the guest.

The three setup message kinds that matter here are:

  • offer - the SDP offer from host to guest.
  • answer - the SDP answer from guest to host.
  • ice_candidate - one possible network route, sent as the browser discovers it.

This is setup traffic, not screen content. The signaling service can observe that a room exists and that setup messages are moving between participants, but it is not receiving the screen stream.

Step 5: the guest answers

The guest browser receives the offer message. It creates its own RTCPeerConnection, calls pc.setRemoteDescription(offer), then pc.createAnswer(), then pc.setLocalDescription(answer).

The answer is the guest saying: “I understand that proposal, and here is what I can receive.” The guest sends it back through signaling. When the host receives the answer and calls pc.setRemoteDescription(answer), both browsers have agreed on the WebRTC session shape. They still need the network path.

Step 6: ICE candidate trickling

While the offer and answer are moving through signaling, both browsers are also gathering ICE candidates.

A candidate is one possible address-and-port pair the browser might be able to use. ICE classifies candidates into a few broad types:

  • Host candidates - local addresses from the device’s network interfaces.
  • Server-reflexive candidates - public-facing addresses discovered with STUN.
  • Relayed candidates - addresses allocated on a TURN relay.

As each candidate is discovered, the browser fires an icecandidate event. Linkside sends that candidate through signaling to the other peer as an ice_candidate message. This is called trickle ICE: candidates arrive incrementally instead of waiting for a complete list.

Each peer feeds incoming candidates into its RTCPeerConnection with pc.addIceCandidate(c). The browser then runs ICE connectivity checks, testing candidate pairs until it finds one that works.

RFC 8445 defines this process. The practical version is simple: WebRTC tries to find the best reachable route between the two browsers, and a relay candidate is there for cases where direct routes fail.

Step 7: DTLS handshake

Once ICE finds a working candidate pair, the two browsers can send packets to each other. WebRTC then uses DTLS-SRTP for the media path. DTLS handles the key exchange and peer authentication; SRTP encrypts the media packets.

RFC 8827 requires WebRTC media to use DTLS-SRTP. Linkside does not add its own screen-sharing encryption layer on top of that standard path. The browser creates and manages the media keys; Linkside’s signaling service and TURN relay do not hold keys that decrypt your screen.

Step 8: media flows

The first SRTP-encrypted media packets arrive at the guest. The guest browser decrypts them, decodes the video frames, and renders them to the <video> element on the page. The guest sees the host’s screen.

For the user, all of this collapses into a short wait after clicking Share: capture, offer, answer, ICE, DTLS-SRTP, first frame. When the direct path works, there is no Linkside media server in the middle of the screen stream. When the direct path does not work, the relay path keeps the session possible while still carrying encrypted media.

What happens when direct connection fails

ICE does not always find a direct route. Restrictive networks, corporate firewalls, VPNs, and double NAT setups can block the path the browsers would otherwise use. When that happens, WebRTC can use relayed candidates: packets routed through a TURN server.

The encryption property that matters is unchanged: the relay forwards encrypted WebRTC media packets and does not hold the browser-managed media keys. The tradeoff is operational. Relay traffic costs more to run and usually adds another network hop.

In Linkside, a free room that needs relay gets a 5-minute relay trial. A license unlocks unlimited relay use. For more detail on the network pieces, see STUN vs TURN explained.

Where each piece lives in Linkside

Mapped to the browser APIs and Linkside pieces:

  • Display capture — the browser’s getDisplayMedia API, called once when the host clicks Share.
  • Peer connection management — one RTCPeerConnection per remote viewer, with the host’s display tracks added to it.
  • ICE server configuration — Google and Cloudflare STUN endpoints by default, plus TURN servers when relay credentials are available.
  • Signaling client — the browser connection to Linkside’s signaling service, used for SDP offers, SDP answers, ICE candidates, and room control messages.
  • Signaling service — the Linkside service that manages live room state and forwards setup messages between participants.

With multiple viewers, the host repeats the WebRTC setup per viewer. Each viewer gets a peer connection with its own offer, answer, ICE checks, and encrypted media path.

What Linkside can and cannot see

This is the trust boundary in plain English:

  • Linkside’s signaling service can observe that a room exists, roughly when guests join, and how long the live session lasts.
  • If TURN relay is needed, the relay handles encrypted packets and IP-level routing.
  • Neither the signaling service nor the relay sees the screen contents.
  • Linkside does not record sessions, keep persistent chat logs, or require an account.
  • Rooms are temporary and disappear when the session lifecycle ends.

That does not make a screen share magic. Viewers can still see whatever you choose to share. What Linkside controls is narrower: it does not build recording, transcription, account history, or server-side media inspection into the product.

The shape of the handshake

Once you have seen it once, the WebRTC handshake stops looking like a black box. Two browsers use a signaling channel for setup, then WebRTC carries encrypted media over the best path ICE can find. Linkside’s job is to keep the setup short, keep rooms temporary, and stay out of the media path whenever the network allows it.

If you want to watch this happen, open Chrome DevTools’ chrome://webrtc-internals page during a Linkside session. You’ll see the offer, the answer, the candidate pairs, and which one ICE selected. It’s the most concrete way to learn the protocol.