Before a peer-to-peer screen share can begin, two browsers have to find a route to each other. That sounds simple. Usually, neither browser has an address the other can reach directly from the public internet.
NAT traversal is the work of finding that route. Most of the time it produces a direct connection. When the networks will not allow one, a well-designed service needs an encrypted relay fallback.
Why your laptop is hard to reach
Your laptop probably has a private IPv4 address. RFC 1918 reserves three blocks for private networks: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. These addresses conserve the limited supply of globally unique IPv4 addresses, but they are not routed on the public internet.
Your router bridges the gap with network address translation, or NAT. In practice, home routers commonly use NAPT, the form described in RFC 2663 that translates port numbers as well as addresses. That lets several devices share one public IP address.
Think of the router as a receptionist. When your browser sends a packet out, the router records which device asked for it and creates a public address-and-port mapping. Replies can follow that record back in. An unexpected inbound packet has no record to follow, so the router does not know which private device should receive it. Traditional NAT therefore allows a private device to start a session outward, but not the reverse.
Why NAT breaks peer-to-peer calls
The usual client-server pattern fits NAT neatly: your browser starts an outbound connection to a server with a public address. Peer-to-peer media is harder because both browsers may sit behind NATs. Each can call out, but neither initially knows a reachable address for the other.
Linkside is peer-to-peer first. It tries to establish a direct browser-to-browser WebRTC connection, which keeps the media path between the participants rather than placing a media server in the middle. The full connection sequence includes signaling, address discovery, path checks, and encryption. NAT traversal is the part that turns two outward-only connections into a usable route.
UDP hole punching, in plain English
The classic technique is UDP hole punching, documented in RFC 5128:
- Both browsers contact a public rendezvous service from inside their networks.
- They learn and exchange the public address-and-port mappings their NATs created.
- Both send packets toward the other’s public endpoint at about the same time.
Those outbound packets create mappings in both NATs. If the NAT behavior cooperates, the packet arriving from the other browser now matches an open mapping and gets through. Both sides still initiated traffic outward; together, they made a temporary path for the peer’s packets.
Two supporting jobs are easy to confuse here. Signaling carries connection information between the browsers. STUN helps a browser discover the public endpoint its NAT assigned. STUN and TURN serve different roles; TURN is the relay used when a direct candidate pair cannot be made to work.
Why some NATs do not cooperate
RFC 4787 separates NAT behavior into two questions:
- Mapping: Does the NAT reuse one external port when the same device contacts different destinations, or create a different mapping for each destination?
- Filtering: After a mapping exists, which outside addresses and ports may send packets back through it?
Mapping is usually the decisive part for basic hole punching. With endpoint-independent mapping, the public endpoint learned through one server remains useful when contacting a peer. With address-and-port-dependent mapping, the NAT may create a new external port for every destination. The endpoint learned through the rendezvous service then does not reliably tell the peer where to send.
That second behavior is roughly what older material calls a symmetric NAT. RFC 4787 retired the old full-cone, restricted-cone, and symmetric labels because they do not describe real NAT behavior precisely enough. The old name remains common, but the practical question is simpler: does the mapping stay stable when the destination changes?
Even difficult mapping behavior does not prove that a WebRTC connection will fail. WebRTC tests several possible routes. If none of the direct candidate pairs works, both browsers can still make outbound connections to a TURN relay.
ICE turns the trick into a protocol
WebRTC uses ICE rather than relying on one guessed route. Each browser gathers candidate addresses and checks candidate pairs in both directions. The checks use the same addresses and ports that media would use, so a successful check identifies a working media path.
ICE can also learn a new translated address during a check. It records that address as a peer-reflexive candidate and can test it too. This is one reason real WebRTC NAT traversal is more capable than the three-step hole-punching sketch suggests.
The goal is not “peer-to-peer at any cost.” It is to prefer a working direct path and retain a relay as the dependable fallback.
Carrier-grade NAT adds another layer
Some internet providers place subscribers behind carrier-grade NAT, or CGNAT. RFC 6598 reserves 100.64.0.0/10 as shared address space for this purpose.
On such a connection, traffic may pass through your home router’s NAT and then the provider’s NAT before reaching the public internet. ICE has to find a route through both translation layers. If their combined behavior prevents a direct path, relay fallback is what keeps the session possible.
What Linkside does
Linkside starts with a direct browser-to-browser connection. Its client uses three STUN servers and sends ICE candidates through the signaling service as they are discovered, allowing connectivity checks to begin without waiting for the entire candidate-gathering process to finish.
If ICE enters a failed state in a free room, the client allows four seconds for the connection to recover before automatically requesting the room’s one-time, five-minute TURN relay trial if it remains eligible and disconnected. A licence removes that relay time limit. Development builds can also force relay-only transport so that the fallback path is tested deliberately.
A direct media path does not mean no Linkside service is involved. The signaling worker helps the browsers establish the room and can observe that a room exists, roughly when guests join, and how long the session lasts. If TURN is needed, the relay observes the routing of encrypted packets. Neither service can read the screen or audio content.
Media uses DTLS-SRTP encryption on both routes. The browsers hold the media keys; no Linkside server does. In other words, a relayed screen share is still encrypted end to end. The relay changes where encrypted packets travel, not who can decrypt them.
Does IPv6 remove the problem?
IPv6 removes NAT’s original address-sharing requirement. As RFC 4864 puts it, the address-amplification benefit of NAT “is not needed in IPv6.” That does not guarantee that two browsers can reach each other: both still need a compatible network path, and network policy may still reject unsolicited inbound traffic.
For now, WebRTC still needs ICE to test the available routes and TURN for the cases where no direct route succeeds. That machinery should stay invisible to the people sharing a screen, but its behavior matters when deciding whether to trust the service carrying it.
Create a Linkside room and the browsers will try the direct path first, with encrypted relay fallback available when the networks refuse it.