DEV Community: Rittly Labs

Your Browser Found an Address. Now Let's Find a Path.

Rittly Labs — Tue, 15 Sep 2026 12:09:59 +0000

Part 2 of the WebRTC Blog Series — The Lab

In Part 1, we asked a deceptively simple question:

What address does my browser have?

We discovered that the answer isn't always as simple as 192.168.x.x.

Your browser can discover local addresses, public-facing addresses through STUN, and other possible network candidates.

But there's a problem.

An address isn't a path.

So in this lab, we're going one step further.

We'll let two browser tabs exchange their candidates, form candidate pairs, run ICE connectivity checks, and see when the browser finds a path that actually works.

What We're Building

We'll build a tiny WebRTC connectivity playground.

You'll have:

Browser A
   │
   │ candidates
   ▼
Signaling
   │
   │ candidates
   ▼
Browser B
   │
   ▼
Candidate Pairs
   │
   ▼
ICE Connectivity Checks
   │
   ▼
Working Path

There is one important shortcut here.

We're using the browser's BroadcastChannel API as our signaling mechanism.

That means this is a local experiment, not a production signaling system.

You don't need a backend server.

You only need:

One computer
A modern browser
Two browser tabs
Python 3

1. Create the Playground

Create a directory:

mkdir webrtc-connectivity-playground
cd webrtc-connectivity-playground

Create an index.html file:

touch index.html

We'll put the entire experiment in that one file.

2. The Complete Lab

Copy this into index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />

  <title>WebRTC Connectivity Playground</title>

  <style>
    body {
      font-family: system-ui, sans-serif;
      max-width: 1000px;
      margin: 40px auto;
      padding: 0 20px;
      line-height: 1.5;
    }

    h1 {
      margin-bottom: 8px;
    }

    .controls {
      display: flex;
      gap: 10px;
      margin: 20px 0;
      flex-wrap: wrap;
    }

    button {
      padding: 10px 16px;
      border: 1px solid #ccc;
      border-radius: 6px;
      cursor: pointer;
      background: white;
    }

    button:disabled {
      cursor: not-allowed;
      opacity: 0.5;
    }

    .status {
      padding: 12px;
      border: 1px solid #ddd;
      border-radius: 8px;
      margin: 20px 0;
    }

    pre {
      background: #f5f5f5;
      padding: 16px;
      border-radius: 8px;
      overflow-x: auto;
      white-space: pre-wrap;
    }

    .section {
      margin-top: 28px;
    }
  </style>
</head>

<body>

  <h1>WebRTC Connectivity Playground</h1>

  <p>
    Open this page in exactly two browser tabs.
    Choose <strong>Caller</strong> in one tab and
    <strong>Receiver</strong> in the other.
  </p>

  <div class="controls">
    <button id="callerBtn">Caller</button>
    <button id="receiverBtn">Receiver</button>

    <button id="inspectBtn" disabled>
      Inspect Candidate Pairs
    </button>
  </div>

  <div class="status">
    <strong>Role:</strong>
    <span id="role">Not selected</span>
    <br />

    <strong>ICE gathering:</strong>
    <span id="gathering">new</span>
    <br />

    <strong>ICE connection:</strong>
    <span id="ice">new</span>
    <br />

    <strong>Connection:</strong>
    <span id="connection">new</span>
  </div>

  <div class="section">
    <h2>ICE Candidates</h2>
    <pre id="candidates">Waiting...</pre>
  </div>

  <div class="section">
    <h2>Logs</h2>
    <pre id="logs">Waiting...</pre>
  </div>

  <div class="section">
    <h2>Candidate Pair Statistics</h2>
    <pre id="stats">Click "Inspect Candidate Pairs" after connecting.</pre>
  </div>

<script>
  const signaling = new BroadcastChannel(
    "webrtc-connectivity-lab"
  );

  const pc = new RTCPeerConnection({
    iceServers: [
      {
        urls: "stun:stun.l.google.com:19302"
      }
    ]
  });

  let role = null;
  let pendingCandidates = [];
  let pendingOffer = null;

  const callerBtn = document.getElementById("callerBtn");
  const receiverBtn = document.getElementById("receiverBtn");
  const inspectBtn = document.getElementById("inspectBtn");

  const roleEl = document.getElementById("role");
  const gatheringEl = document.getElementById("gathering");
  const iceEl = document.getElementById("ice");
  const connectionEl = document.getElementById("connection");

  const candidatesEl = document.getElementById("candidates");
  const logsEl = document.getElementById("logs");
  const statsEl = document.getElementById("stats");

  function log(message) {
    const time = new Date().toLocaleTimeString();

    logsEl.textContent += `[${time}] ${message}\n`;
    logsEl.scrollTop = logsEl.scrollHeight;
  }

  function showCandidate(candidate) {
    const type = candidate.type || "unknown";
    const protocol = candidate.protocol || "unknown";
    const address =
      candidate.address || candidate.candidate || "unknown";
    const port = candidate.port || "";

    candidatesEl.textContent +=
      `${type} | ${protocol} | ${address}:${port}\n`;
  }

  async function setRole(selectedRole) {
    if (role) return;

    role = selectedRole;

    roleEl.textContent = role;

    callerBtn.disabled = true;
    receiverBtn.disabled = true;

    log(`Role selected: ${role}`);

    if (role === "Caller") {
      await createOffer();
    }

    if (role === "Receiver" && pendingOffer) {
      await handleOffer(pendingOffer);
      pendingOffer = null;
    }
  }

  callerBtn.addEventListener("click", () => {
    setRole("Caller");
  });

  receiverBtn.addEventListener("click", () => {
    setRole("Receiver");
  });

  pc.onicecandidate = (event) => {
    if (!event.candidate) return;

    showCandidate(event.candidate);

    log(
      `Candidate gathered: ${event.candidate.type || "unknown"}`
    );

    signaling.postMessage({
      type: "candidate",
      candidate: event.candidate.toJSON()
    });
  };

  pc.onicegatheringstatechange = () => {
    gatheringEl.textContent = pc.iceGatheringState;

    log(
      `ICE gathering state: ${pc.iceGatheringState}`
    );
  };

  pc.oniceconnectionstatechange = () => {
    iceEl.textContent = pc.iceConnectionState;

    log(
      `ICE connection state: ${pc.iceConnectionState}`
    );

    if (
      pc.iceConnectionState === "connected" ||
      pc.iceConnectionState === "completed"
    ) {
      inspectBtn.disabled = false;
    }
  };

  pc.onconnectionstatechange = () => {
    connectionEl.textContent = pc.connectionState;

    log(
      `Peer connection state: ${pc.connectionState}`
    );
  };

  /*
   * The Caller creates the DataChannel.
   * The Receiver gets it through the datachannel event.
   */
  pc.ondatachannel = (event) => {
    const channel = event.channel;

    log("DataChannel received.");

    channel.onopen = () => {
      log("DataChannel opened.");

      channel.onmessage = (messageEvent) => {
        log(
          `Message received: ${messageEvent.data}`
        );
      };
    };
  };

  async function handleOffer(description) {
    try {
      log("Offer received.");

      await pc.setRemoteDescription(description);

      await flushPendingCandidates();

      const answer = await pc.createAnswer();

      await pc.setLocalDescription(answer);

      signaling.postMessage({
        type: "answer",
        description: pc.localDescription
      });

      log("Answer sent.");

    } catch (error) {
      log(`Offer handling error: ${error.message}`);
      console.error(error);
    }
  }

  signaling.onmessage = async (event) => {
    const message = event.data;

    try {
      if (message.type === "offer") {
        if (role !== "Receiver") {
          pendingOffer = message.description;

          log(
            "Offer received and waiting for Receiver role."
          );

          return;
        }

        await handleOffer(message.description);
      }

      if (message.type === "answer") {
        if (role !== "Caller") return;

        log("Answer received.");

        await pc.setRemoteDescription(
          message.description
        );

        await flushPendingCandidates();
      }

      if (message.type === "candidate") {
        await handleRemoteCandidate(
          message.candidate
        );
      }

    } catch (error) {
      log(`Signaling error: ${error.message}`);
      console.error(error);
    }
  };

  async function handleRemoteCandidate(candidate) {
    if (pc.remoteDescription) {
      await pc.addIceCandidate(candidate);

      log("Remote candidate added.");
    } else {
      pendingCandidates.push(candidate);

      log("Remote candidate queued.");
    }
  }

  async function flushPendingCandidates() {
    for (const candidate of pendingCandidates) {
      await pc.addIceCandidate(candidate);
    }

    if (pendingCandidates.length > 0) {
      log(
        `Added ${pendingCandidates.length} queued candidate(s).`
      );
    }

    pendingCandidates = [];
  }

  async function createOffer() {
    try {
      log("Creating offer...");

      const channel = pc.createDataChannel("probe");

      channel.onopen = () => {
        log("DataChannel opened.");

        channel.send(
          "Hello from the other side!"
        );
      };

      const offer = await pc.createOffer();

      await pc.setLocalDescription(offer);

      signaling.postMessage({
        type: "offer",
        description: pc.localDescription
      });

      log("Offer sent.");

    } catch (error) {
      log(`Offer error: ${error.message}`);
      console.error(error);
    }
  }

  inspectBtn.addEventListener("click", async () => {
    try {
      const stats = await pc.getStats();

      let output = "";

      stats.forEach((report) => {
        if (report.type !== "candidate-pair") {
          return;
        }

        output +=
          `state: ${report.state || "n/a"}\n` +
          `localCandidateId: ${
            report.localCandidateId || "n/a"
          }\n` +
          `remoteCandidateId: ${
            report.remoteCandidateId || "n/a"
          }\n` +
          `currentRoundTripTime: ${
            report.currentRoundTripTime ?? "n/a"
          }\n` +
          `bytesSent: ${
            report.bytesSent ?? "n/a"
          }\n` +
          `bytesReceived: ${
            report.bytesReceived ?? "n/a"
          }\n\n`;
      });

      statsEl.textContent =
        output || "No candidate-pair reports found.";

    } catch (error) {
      statsEl.textContent =
        `Stats error: ${error.message}`;

      console.error(error);
    }
  });
</script>

</body>
</html>

There's a lot happening here.

Don't worry.

We're going to peel it apart one piece at a time.

3. Start the Lab

From the same directory:

python3 -m http.server 8000

Open:

http://localhost:8000

Now open the page in exactly two tabs.

Something important:

BroadcastChannel only communicates between pages on the same origin.

So this lab is intentionally limited to two tabs on the same browser/computer.

It is a tiny replacement for a real signaling server.

In a real application, your signaling layer could be WebSocket, HTTP, or another transport.

4. Open Two Tabs

In the first tab:

Caller

In the second tab:

Receiver

Once the Caller is selected, it creates an SDP offer.

The Receiver accepts that offer and creates an answer.

Meanwhile, both browsers are gathering ICE candidates.

You'll start seeing things like:

host | udp | ...
srflx | udp | ...

depending on what your browser and network expose.

This is where Part 1 comes back.

We already found the addresses.

Now we're going to find out which of them can actually be used.

5. Watch ICE Work

Look at the status section.

You'll see:

ICE gathering: gathering
ICE connection: checking
Connection: connecting

and eventually, if everything works:

ICE gathering: complete
ICE connection: connected
Connection: connected

The important transition is:

checking
   ↓
connected

That means ICE has found a viable way for the two peers to communicate.

6. Look at the Candidates

Scroll down to ICE Candidates.

You may see several candidates.

For example:

host | udp | ...
srflx | udp | ...

These represent different possibilities.

A host candidate is associated with a local interface.

A srflx candidate represents an address discovered through STUN.

You might also see .local hostnames instead of raw local IP addresses. Modern browsers can use mDNS to avoid exposing local IP addresses directly to web pages.

The important idea is:

A candidate is a possibility, not a connection.

We haven't selected a path yet.

7. Prove the Path

If the connection succeeds, you'll also see:

DataChannel opened.
Message received: Hello from the other side!

This is the fun part.

Something actually crossed the connection.

The browser didn't just discover an address.

It found a working path and opened a WebRTC DataChannel through it.

But let's inspect what happened underneath.

8. Inspect the Candidate Pairs

Click:

Inspect Candidate Pairs

The browser's statistics API will show candidate-pair reports.

You may see something similar to:

state: succeeded
localCandidateId: ...
remoteCandidateId: ...
currentRoundTripTime: ...
bytesSent: ...
bytesReceived: ...

The important field is:

state: succeeded

A candidate pair is made by combining:

Local Candidate
       +
Remote Candidate
       =
Candidate Pair

The browser can have multiple combinations.

ICE checks those possibilities and determines which ones are usable.

The statistics output here shows the candidate-pair reports the browser currently exposes.

It is useful for seeing what ICE knows about the connection.

What's Happening Underneath?

Let's zoom out.

Imagine Browser A has:

A1 → host candidate
A2 → server-reflexive candidate

Browser B has:

B1 → host candidate
B2 → server-reflexive candidate

ICE can form combinations:

A1 ↔ B1
A1 ↔ B2
A2 ↔ B1
A2 ↔ B2

Those are candidate pairs.

Now the browser starts asking:

Can I actually reach you using this pair?

ICE connectivity checks use STUN transactions to test those possible paths.

Conceptually:

Browser A
   │
   │ STUN connectivity check
   ▼
Browser B
   │
   │ response
   ▼
Browser A

If the check succeeds, that candidate pair is viable.

If it fails, ICE can try another pair.

So the process looks roughly like this:

Candidates
    ↓
Candidate Pairs
    ↓
Connectivity Checks
    ↓
Working Pair
    ↓
WebRTC Connection

That's the missing piece from Part 1.

We had addresses.

Now we have a path.

What About TURN?

So far, we've been talking about finding a direct path.

But what if the browsers can't reach each other directly?

That's where TURN enters the story.

Instead of:

Browser A ─────────────── Browser B

we may need:

Browser A
     │
     ▼
 TURN Server
     │
     ▼
Browser B

The TURN server acts as a relay.

The browsers still use ICE to discover and test possible paths, but a relay candidate gives them another option when direct connectivity isn't possible.

This is why WebRTC doesn't simply say:

"Here's my IP address. Connect to me."

There can be several possible paths.

Some work.

Some don't.

And sometimes you need a relay.

Try Something Different

Now reload both tabs and run the experiment again.

Watch the logs.

Pay attention to the order:

Candidate gathered
Candidate exchanged
Remote candidate added
ICE connection state: checking
ICE connection state: connected
DataChannel opened

The exact order can vary.

That's part of the lesson.

Networking isn't a neat sequence where every message arrives exactly when you expect it.

Candidates can arrive before the remote description is ready.

That's why the example keeps them temporarily:

let pendingCandidates = [];

and later adds them:

await pc.addIceCandidate(candidate);

after the remote description has been installed.

This is one of those small details that becomes very important when you build a real WebRTC application.

The Important Mental Model

At this point, keep these three things separate:

1. Candidate

"Here's one address I might be reachable through."

2. Candidate Pair

"Let's combine one of my candidates with one of yours."

3. Connectivity Check

"Let's see if this particular combination actually works."

That gives us:

Address
   ↓
Candidate
   ↓
Candidate Pair
   ↓
Connectivity Check
   ↓
Working Path

And that is what ICE is doing for us.

What Did We Actually Learn?

In Part 1, we discovered that a browser can have multiple network addresses.

But having an address doesn't mean another browser can reach you through it.

In this lab, we went one step further.

We:

Gathered ICE candidates.
Exchanged candidates between two peers.
Formed candidate pairs.
Ran ICE connectivity checks.
Observed the ICE connection state.
Opened a DataChannel.
Inspected candidate-pair statistics.
Saw where TURN fits when direct connectivity isn't possible.

The important distinction is:

A candidate tells you where you might be reachable. ICE determines whether a path actually works.

The Road Is Ready

We've solved one problem.

The browsers found a way to reach each other.

But now we have a new question.

Now that we have a path, what can we actually send through it?

That's where we'll go next.

Part 3 — Your Browser Found a Path. Now Let's Send Something Through It.

We'll finally move from:

"Can these browsers reach each other?"

to:

"Can they actually exchange data?"

And that's where WebRTC starts to feel less like networking theory and more like something alive.

References

Your Browser Is Behind a Router. Let's See What It Actually Knows.

Rittly Labs — Fri, 11 Sep 2026 14:50:57 +0000

In the Medium(https://medium.com/@rittlyofficial/your-browser-is-behind-a-router-now-what-e0154fe778aa) article, we looked at a deceptively simple problem:

Alice's browser knows its address.

Bob's browser knows its address.

Both browsers are online.

And yet, neither browser can simply use the other's private IP address.

The reason is that an IP address does not automatically mean reachability.

Now let's stop talking about the problem for a moment.

Let's ask the browser what it actually knows.

We'll build a small WebRTC playground, run it locally, and inspect the network candidates that the browser gathers.

By the end of this article, you should be able to answer:

What is an ICE candidate?
What is a host candidate?
Why does a browser sometimes discover a srflx candidate?
What does STUN actually tell the browser?
Why does gathering candidates not mean that two browsers are connected?

Let's start.

1. Prerequisites

You don't need to run a WebRTC backend or signaling server for this experiment.

You only need:

a modern browser
Python 3
a terminal
a text editor
internet access for the STUN part of the experiment

We'll use plain HTML and JavaScript.

No framework.

No Node.js.

No signaling server.

No backend.

The goal is to see what the browser itself can discover.

2. Create the playground

Create a directory:

mkdir webrtc-connectivity-playground
cd webrtc-connectivity-playground

Create the HTML file:

touch index.html

If you're using an editor, you can simply create index.html manually.

Add the following code:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <title>WebRTC Connectivity Playground</title>

  <style>
    body {
      font-family: system-ui, sans-serif;
      max-width: 1000px;
      margin: 40px auto;
      padding: 0 20px;
      line-height: 1.5;
    }

    button {
      padding: 10px 16px;
      font-size: 16px;
      cursor: pointer;
    }

    table {
      width: 100%;
      border-collapse: collapse;
      margin-top: 24px;
    }

    th,
    td {
      text-align: left;
      padding: 10px;
      border-bottom: 1px solid #ddd;
      vertical-align: top;
    }

    code {
      word-break: break-word;
    }

    pre {
      margin-top: 24px;
      padding: 16px;
      background: #f4f4f4;
      border-radius: 8px;
      overflow-x: auto;
      white-space: pre-wrap;
      word-break: break-word;
    }

    #status {
      margin-top: 20px;
      font-weight: 600;
    }
  </style>
</head>

<body>

  <h1>WebRTC Connectivity Playground</h1>

  <p>
    Ask the browser to gather the network candidates it knows about.
  </p>

  <button id="start">
    Discover Candidates
  </button>

  <div id="status">
    Waiting...
  </div>

  <table>
    <thead>
      <tr>
        <th>Type</th>
        <th>Address</th>
        <th>Port</th>
        <th>Protocol</th>
      </tr>
    </thead>

    <tbody id="candidates"></tbody>
  </table>

  <pre id="raw">No candidates yet.</pre>

  <script>
    const button = document.getElementById("start");
    const status = document.getElementById("status");
    const candidates = document.getElementById("candidates");
    const raw = document.getElementById("raw");

    button.addEventListener("click", async () => {
      button.disabled = true;

      status.textContent = "Gathering ICE candidates...";
      candidates.innerHTML = "";
      raw.textContent = "";

      const pc = new RTCPeerConnection({
        iceServers: [
          {
            urls: "stun:stun.l.google.com:19302"
          }
        ]
      });

      pc.createDataChannel("probe");

      pc.addEventListener("icecandidate", (event) => {
        if (!event.candidate) {
          return;
        }

        const candidate = event.candidate;

        const row = document.createElement("tr");

        row.innerHTML = `
          <td>
            <code>${candidate.type ?? "unknown"}</code>
          </td>

          <td>
            <code>${candidate.address ?? "hidden"}</code>
          </td>

          <td>
            <code>${candidate.port ?? "—"}</code>
          </td>

          <td>
            <code>${candidate.protocol ?? "—"}</code>
          </td>
        `;

        candidates.appendChild(row);

        raw.textContent +=
          candidate.candidate + "\n\n";
      });

      pc.addEventListener("icegatheringstatechange", () => {
        if (pc.iceGatheringState === "complete") {
          status.textContent =
            "ICE gathering complete.";
        }
      });

      try {
        const offer = await pc.createOffer();

        await pc.setLocalDescription(offer);

      } catch (error) {
        status.textContent =
          `Error: ${error.message}`;
      }
    });
  </script>

</body>
</html>

3. Run it

From the same directory, run:

python3 -m http.server 8000

You should see something similar to:

Serving HTTP on 0.0.0.0 port 8000

Now open:

http://localhost:8000

You should see the playground.

Click:

Discover Candidates

After a moment, the table should start filling with candidates.

4. What should you see?

Depending on your browser and network, you may see something like:

Type    Address          Port    Protocol

host    192.168.1.20     54321   udp
srflx   203.0.113.50     62001   udp

Your values will almost certainly be different.

You may see only:

host

You may see:

host
srflx

And you may see a .local hostname instead of a private IP address.

All of these can be normal.

The result depends on:

your network
your router
your browser
VPN configuration
firewall policies
browser privacy mechanisms

The important part is understanding what the candidate types mean.

5. What is an ICE candidate?

Let's start with the simplest definition.

An ICE candidate is information describing a possible way for a browser to communicate.

A candidate can contain information such as:

Address
Port
Protocol
Candidate type

For example:

192.168.1.20:54321

is an address and port.

The complete candidate string contains more information, which is why the raw output can look intimidating:

candidate:...

Don't worry about decoding every field yet.

For this article, we care mainly about the candidate type.

6. The `host` candidate

The first candidate type you'll usually encounter is:

host

A host candidate represents an address available directly from the local machine or one of its network interfaces.

For example:

192.168.1.20:54321

Conceptually:

Alice's Laptop

192.168.1.20
      │
      ▼
   Network

If Alice and Bob are on the same local network, their browsers may be able to communicate using local addresses.

For example:

Alice                    Bob

192.168.1.20             192.168.1.21
     │                         │
     └──────── Wi-Fi ─────────┘

That can be a perfectly valid path.

But now put them on different networks.

Alice
192.168.1.20
     │
     ▼
  Router
     │
     ▼
 Internet
     │
     ▼
  Router
     │
     ▼
Bob
192.168.0.15

Alice's private address doesn't tell Bob how to reach her across the internet.

That's the problem we started with.

7. Let's inspect the candidate object

The browser gives us more than the raw candidate string.

We can inspect the candidate object directly.

Open your browser's DevTools console and change the event handler to:

pc.addEventListener("icecandidate", (event) => {
  if (!event.candidate) {
    return;
  }

  console.log({
    candidate: event.candidate.candidate,
    type: event.candidate.type,
    address: event.candidate.address,
    port: event.candidate.port,
    protocol: event.candidate.protocol
  });
});

Now run the experiment again.

You should see an object similar to:

{
  candidate: "...",
  type: "host",
  address: "...",
  port: 54321,
  protocol: "udp"
}

The exact values depend on your environment.

This is much easier to reason about than the complete candidate string.

8. Why does `setLocalDescription()` matter?

Look at these lines:

const offer = await pc.createOffer();

await pc.setLocalDescription(offer);

It is tempting to think that createOffer() is what gathers the candidates.

That's not quite the right mental model.

The local description is set, and ICE gathering begins as part of the peer connection process.

The browser then reports candidates through:

icecandidate

So our experiment is essentially:

Create RTCPeerConnection
          │
          ▼
Create data channel
          │
          ▼
Create offer
          │
          ▼
Set local description
          │
          ▼
ICE gathering
          │
          ▼
icecandidate events

We're watching the browser discover possible network addresses.

9. Why did we create a data channel?

You may have noticed this:

pc.createDataChannel("probe");

We aren't actually sending data through it.

That's intentional.

The data channel gives the peer connection something to negotiate, allowing us to create an offer for this experiment.

Think of it as giving the WebRTC connection a small piece of work to prepare for.

We're not establishing a connection to another browser yet.

10. Where does NAT enter the picture?

Now let's return to Alice.

Her laptop might have:

192.168.1.20:54321

Her router may translate that connection to something like:

203.0.113.50:62001

Conceptually:

Alice Browser
192.168.1.20:54321
       │
       ▼
     Router
       │
       ▼
203.0.113.50:62001

The browser does not necessarily own the public-side address.

The router does the NAT translation.

So the browser has a problem:

How can I discover how I appear from outside my network?

This is where STUN becomes useful.

11. Add a STUN server

Our playground already contains a STUN server:

const pc = new RTCPeerConnection({
  iceServers: [
    {
      urls: "stun:stun.l.google.com:19302"
    }
  ]
});

The important part is:

iceServers

We're telling the WebRTC implementation:

"You may use this server when gathering ICE candidates."

STUN stands for:

Session Traversal Utilities for NAT

At a high level, STUN allows the browser to ask an external server what address and port the request appeared to come from.

Conceptually:

Alice Browser
192.168.1.20:54321
       │
       ▼
     Router
       │
       ▼
  STUN Server
       │
       ▼
203.0.113.50:62001

The STUN server can observe the public-side mapping.

The browser can then use that information as another candidate.

12. The `srflx` candidate

If STUN successfully discovers a server-reflexive address, you may see:

srflx

srflx is short for:

server-reflexive

Conceptually:

host
192.168.1.20:54321

and:

srflx
203.0.113.50:62001

Now the browser has two different pieces of information:

host
  ↓
local address

srflx
  ↓
public-side address observed through STUN

This is a big improvement.

But there is still an important limitation.

13. A candidate is not a connection

This is worth repeating.

Seeing:

srflx
203.0.113.50:62001

does not mean Bob can successfully connect to Alice using that address.

It means:

The browser discovered a possible address.

That's all.

We haven't:

exchanged candidates with another browser
built candidate pairs
performed connectivity checks
selected a working path
configured TURN

Those are separate steps.

This distinction is extremely important when debugging WebRTC.

Candidate gathering
        │
        ▼
"Here are possible addresses."

Connectivity checking
        │
        ▼
"Let's see which paths actually work."

Our playground currently stops at the first part.

14. What if I don't see `192.168.x.x`?

This is a common point of confusion.

You may expect to see:

192.168.1.20

but instead see something like:

something-random.local

Modern browsers can use mDNS hostnames for local candidates instead of exposing the local IP address directly.

So don't treat:

192.168.x.x

as a requirement for the experiment to work.

Look at:

candidate.type

If you see:

host

the browser has gathered a host candidate.

The exact representation of the address can vary.

15. Try it on different networks

Now the experiment gets more interesting.

Run the playground on your normal Wi-Fi connection.

Record what you see.

Then try another network.

For example:

Wi-Fi
   ↓
Gather candidates

and then:

Mobile hotspot
   ↓
Gather candidates

You may see different candidate information.

You can also try:

another browser
a VPN
Ethernet
another computer

The point isn't to produce one perfect output.

The point is to observe that the network environment affects what the browser can discover.

16. What we have learned

Let's summarize what our little playground has shown us.

A browser can have multiple network interfaces and addresses.

WebRTC gathers possible network candidates from that environment.

The simplest candidate type is:

host

A STUN server can help the browser discover a server-reflexive candidate:

srflx

And the browser exposes these candidates through the:

icecandidate

event.

Our current flow looks like this:

Network interfaces
        │
        ▼
ICE gathering
        │
        ├──────────────┐
        ▼              ▼
      host           srflx
        │              │
        │              └── STUN
        │
        └── local interface

But we're still missing the most important part.

Another browser.

17. One browser isn't enough

Our playground asks:

"What addresses can I discover about myself?"

A real WebRTC connection needs two peers.

For example:

Alice Browser                 Bob Browser

    host                         host
    srflx                        srflx
      │                            │
      │                            │
      └──────── Candidates ────────┘

Now the browsers have to exchange those candidates.

Then they need to test whether the possible paths actually work.

Only after that can WebRTC select a usable path.

That is where ICE connectivity checks enter the picture.

And that's where we'll continue in the next article.

18. The important mental model

At this point, don't try to memorize candidate grammar.

Remember this:

The browser
     │
     ▼
"What network addresses do I have?"
     │
     ▼
Candidate gathering
     │
     ├── host
     │
     └── srflx
            │
            └── discovered using STUN

The browser has now collected possibilities.

It hasn't proved that any of them can reach the other browser.

That's the next problem.

19. Where we are in the WebRTC journey

We've gone from:

Private IP
    │
    ▼
NAT
    │
    ▼
"What does the outside world see?"
    │
    ▼
STUN
    │
    ▼
ICE candidates

The next step is:

Alice candidates
        +
Bob candidates
        │
        ▼
Candidate pairs
        │
        ▼
Connectivity checks
        │
        ▼
Working path

And if direct connectivity isn't possible, we'll eventually need another option:

TURN

But that's the next layer.

For now, we've accomplished something useful.

We made the browser's hidden networking process visible.

In Part 2, we'll finally put Alice and Bob together.

We'll exchange their candidates and watch ICE test the possible paths.

We'll look at:

candidate pairs
connectivity checks
ICE states
successful and failed paths
selected candidate pairs
STUN in the complete connection flow
TURN and relay candidates

The browser has found some addresses.

Next, we'll find out which one actually works.

The Call That Hasn't Started Yet

Rittly Labs — Wed, 09 Sep 2026 12:49:37 +0000

A technical companion to the WebRTC connection journey: signaling,
SDP, Offer/Answer, ICE, STUN, TURN, Trickle ICE, and connectivity
debugging.

What this article adds

The Medium article follows a WebRTC connection as a story. This
companion gets closer to the implementation.

We will build a small two-browser WebRTC application with:

a WebSocket signaling server
SDP Offer/Answer negotiation
trickled ICE candidates
a WebRTC DataChannel
connection-state logging
no framework and no build step

The key distinction is simple:

Signaling carries the information needed to establish the
connection. WebRTC carries the actual peer data once connectivity is
established.

1. Architecture

             Signaling
        WebSocket Server
          /           \
         /             \
        ▼               ▼
   Alice Browser    Bob Browser
        │               │
        │   WebRTC      │
        └───────────────┘
          Peer Connection

The signaling server forwards:

SDP offers
SDP answers
ICE candidates
room information

It does not automatically become the media or DataChannel path.

2. Project

webrtc-demo/
├── server.js
└── public/
    └── index.html

Create it:

mkdir webrtc-demo
cd webrtc-demo
npm init -y
npm install ws
mkdir public

3. Signaling server

Create server.js:

const http = require("http");
const fs = require("fs");
const path = require("path");
const WebSocket = require("ws");

const PORT = 8000;

const server = http.createServer((req, res) => {
  const file = path.join(
    __dirname,
    "public",
    req.url === "/" ? "index.html" : req.url
  );

  fs.readFile(file, (error, data) => {
    if (error) {
      res.writeHead(404);
      res.end("Not found");
      return;
    }

    res.writeHead(200, {
      "Content-Type": "text/html"
    });

    res.end(data);
  });
});

const wss = new WebSocket.Server({ server });
const rooms = new Map();

wss.on("connection", (socket) => {
  let roomId = null;

  socket.on("message", (rawMessage) => {
    let message;

    try {
      message = JSON.parse(rawMessage);
    } catch {
      return;
    }

    if (message.type === "join") {
      roomId = message.room;

      if (!rooms.has(roomId)) {
        rooms.set(roomId, new Set());
      }

      const room = rooms.get(roomId);

      if (room.size >= 2) {
        socket.send(JSON.stringify({
          type: "error",
          message: "Room is full"
        }));
        return;
      }

      room.add(socket);

      socket.send(JSON.stringify({
        type: "joined",
        initiator: room.size === 1
      }));

      // The first peer creates its Offer only after a second peer is present.
      if (room.size === 2) {
        for (const peer of room) {
          if (peer !== socket && peer.readyState === WebSocket.OPEN) {
            peer.send(JSON.stringify({
              type: "peer-joined"
            }));
          }
        }
      }

      return;
    }

    if (!roomId || !rooms.has(roomId)) {
      return;
    }

    for (const peer of rooms.get(roomId)) {
      if (peer !== socket && peer.readyState === WebSocket.OPEN) {
        peer.send(JSON.stringify(message));
      }
    }
  });

  socket.on("close", () => {
    if (!roomId || !rooms.has(roomId)) {
      return;
    }

    const room = rooms.get(roomId);
    room.delete(socket);

    if (room.size === 0) {
      rooms.delete(roomId);
    }
  });
});

server.listen(PORT, () => {
  console.log(`WebRTC demo running at http://localhost:${PORT}`);
});

Run it:

node server.js

Open http://localhost:8000 in two browser tabs and join the same room.

4. Browser application

Create public/index.html:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>WebRTC Demo</title>
  <style>
    body {
      font-family: system-ui, sans-serif;
      max-width: 800px;
      margin: 40px auto;
      padding: 20px;
    }

    input, button {
      padding: 8px 12px;
      margin: 4px;
    }

    #log {
      background: #111;
      color: #eee;
      padding: 16px;
      min-height: 300px;
      white-space: pre-wrap;
    }
  </style>
</head>

<body>

  <h1>WebRTC Demo</h1>

  <input id="room" value="demo-room">
  <button id="join" disabled>Join Room</button>
  <button id="send" disabled>Send Message</button>

  <pre id="log"></pre>

  <script>
    const logElement = document.getElementById("log");

    function log(message) {
      logElement.textContent += message + "\n";
    }

    const roomInput = document.getElementById("room");
    const joinButton = document.getElementById("join");
    const sendButton = document.getElementById("send");

    const socket = new WebSocket(
      `ws://${window.location.host}`
    );

    socket.onopen = () => {
      log("Signaling connected");
      joinButton.disabled = false;
    };

    socket.onerror = () => {
      log("Signaling connection failed");
    };

    const pc = new RTCPeerConnection({
      iceServers: []
    });

    let dataChannel = null;
    const pendingCandidates = [];

    async function addRemoteCandidate(candidate) {
      if (!pc.remoteDescription) {
        pendingCandidates.push(candidate);
        log("Remote ICE candidate queued");
        return;
      }

      await pc.addIceCandidate(candidate);
      log("Remote ICE candidate added");
    }

    async function flushPendingCandidates() {
      while (pendingCandidates.length > 0) {
        await pc.addIceCandidate(pendingCandidates.shift());
        log("Queued remote ICE candidate added");
      }
    }

    function createDataChannel() {
      dataChannel = pc.createDataChannel("demo");

      dataChannel.onopen = () => {
        log("Data channel: open");
        sendButton.disabled = false;
      };

      dataChannel.onclose = () => {
        log("Data channel: closed");
        sendButton.disabled = true;
      };

      dataChannel.onmessage = (event) => {
        log("Received: " + event.data);
      };
    }

    pc.ondatachannel = (event) => {
      dataChannel = event.channel;

      dataChannel.onopen = () => {
        log("Data channel: open");
        sendButton.disabled = false;
      };

      dataChannel.onclose = () => {
        log("Data channel: closed");
        sendButton.disabled = true;
      };

      dataChannel.onmessage = (event) => {
        log("Received: " + event.data);
      };
    };

    // Trickle ICE: forward candidates as they are discovered.
    pc.onicecandidate = (event) => {
      if (event.candidate) {
        socket.send(JSON.stringify({
          type: "ice-candidate",
          candidate: event.candidate
        }));

        log("ICE candidate sent");
      } else {
        log("ICE gathering complete");
      }
    };

    pc.oniceconnectionstatechange = () => {
      log("ICE state: " + pc.iceConnectionState);
    };

    pc.onconnectionstatechange = () => {
      log("Connection state: " + pc.connectionState);
    };

    socket.onmessage = async (event) => {
      const message = JSON.parse(event.data);

      try {
        if (message.type === "joined") {
          log("Joined room");

          if (message.initiator) {
            log("You are the initiator");
          }

          return;
        }

        if (message.type === "peer-joined") {
          log("Peer joined room");

          createDataChannel();

          const offer = await pc.createOffer();
          await pc.setLocalDescription(offer);

          socket.send(JSON.stringify({
            type: "offer",
            description: pc.localDescription
          }));

          log("SDP Offer sent");
          return;
        }

        if (message.type === "offer") {
          log("SDP Offer received");

          await pc.setRemoteDescription(
            message.description
          );

          await flushPendingCandidates();

          const answer = await pc.createAnswer();
          await pc.setLocalDescription(answer);

          socket.send(JSON.stringify({
            type: "answer",
            description: pc.localDescription
          }));

          log("SDP Answer sent");
          return;
        }

        if (message.type === "answer") {
          log("SDP Answer received");

          await pc.setRemoteDescription(
            message.description
          );

          await flushPendingCandidates();

          log("Remote description set");
          return;
        }

        if (message.type === "ice-candidate") {
          await addRemoteCandidate(message.candidate);
          return;
        }

        if (message.type === "error") {
          log("Error: " + message.message);
        }
      } catch (error) {
        log("WebRTC error: " + error.message);
      }
    };

    joinButton.onclick = () => {
      if (socket.readyState !== WebSocket.OPEN) {
        log("Signaling is not connected yet");
        return;
      }

      const room = roomInput.value.trim();

      if (!room) {
        log("Enter a room name");
        return;
      }

      socket.send(JSON.stringify({
        type: "join",
        room
      }));

      log("Joining room: " + room);
      joinButton.disabled = true;
      roomInput.disabled = true;
    };

    sendButton.onclick = () => {
      if (!dataChannel || dataChannel.readyState !== "open") {
        return;
      }

      const message = "Hello from WebRTC!";

      dataChannel.send(message);
      log("Sent: " + message);
    };
  </script>

</body>
</html>

5. What happens?

Open two tabs:

Tab A → demo-room
Tab B → demo-room

The first peer becomes the initiator and waits for the second peer to
join.

The second peer becomes the receiver. When it joins, the server tells
the initiator that a peer is ready; only then does the initiator create
and send the Offer.

The sequence is:

Alice                    Signaling                    Bob
  │                         │                          │
  │──── join(room) ────────►│                          │
  │                         │◄──── join(room) ─────────│
  │◄──── peer-joined ───────│                          │
  │                         │                          │
  │ createOffer()           │                          │
  │                         │                          │
  │──── Offer ─────────────►│──── Offer ──────────────►│
  │                         │                          │
  │                         │             setRemoteDescription()
  │                         │             createAnswer()
  │                         │                          │
  │◄──── Answer ────────────│◄──── Answer ─────────────│
  │                         │                          │
  │──── ICE candidate ─────►│──── ICE candidate ──────►│
  │◄──── ICE candidate ─────│◄──── ICE candidate ──────│
  │                         │                          │
  │        ICE connectivity checks                       │
  │                         │                          │
  │════════════ WebRTC connection established ══════════│
  │                         │                          │
  │──────── DataChannel message ───────────────────────►│

6. Signaling is application-defined

WebRTC does not require your application to use WebSocket.

The application decides how peers exchange:

SDP offers
SDP answers
ICE candidates
room information
authentication metadata

The transport could be WebSocket, HTTP, or another application-level
mechanism.

In this demo, WebSocket is simply the signaling transport.

The important separation is:

Application signaling
        │
        ├── Offer
        ├── Answer
        └── ICE candidates
                │
                ▼
         RTCPeerConnection
                │
                ▼
       WebRTC connectivity

7. Creating the Offer

The initiator calls:

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

createOffer() generates an SDP description representing the proposed
session.

The SDP can describe session information such as:

media sections
codecs
media directions
transport information
ICE-related information

The exact SDP is browser- and configuration-dependent.

Treat SDP as a protocol artifact. In normal application code, you should
let the browser generate it rather than manually constructing it.

8. Why `setLocalDescription()` matters

These operations have different responsibilities:

const offer = await pc.createOffer();

await pc.setLocalDescription(offer);

createOffer() creates the proposed description.

setLocalDescription() applies that description to the local peer
connection.

After the local description is set, ICE gathering can begin.

That is why the application sends:

pc.localDescription

through signaling.

9. Receiving the Offer and creating the Answer

Bob receives Alice's Offer:

await pc.setRemoteDescription(
  message.description
);

Bob then creates an Answer:

const answer = await pc.createAnswer();

await pc.setLocalDescription(answer);

The Answer goes back through signaling:

socket.send(JSON.stringify({
  type: "answer",
  description: pc.localDescription
}));

Alice applies it:

await pc.setRemoteDescription(
  message.description
);

The Offer/Answer exchange establishes the negotiated session
configuration.

It does not, by itself, prove that the peers have a working network
path.

10. ICE candidates

An ICE candidate represents a possible way to reach the remote peer.

A simplified model is:

Host candidate
    └── local interface

Server-reflexive candidate
    └── address observed through STUN

Relay candidate
    └── address provided by TURN

Candidates are exposed through:

pc.onicecandidate = (event) => {
  if (event.candidate) {
    // Send candidate through signaling.
  }
};

The remote peer supplies received candidates to its ICE agent:

await pc.addIceCandidate(
  message.candidate
);

11. Trickle ICE

This demo sends candidates as soon as the browser discovers them.

That is Trickle ICE:

Candidate discovered
       ↓
Send candidate
       ↓
Remote peer receives it
       ↓
addIceCandidate()
       ↓
Connectivity checks

The application does not need to wait for all candidates before
beginning candidate exchange.

This can reduce connection setup time.

12. ICE connectivity checks

After candidates have been exchanged, ICE evaluates candidate pairs:

Alice candidates        Bob candidates

      A1 ───────────────── B1
      A1 ───────────────── B2
      A2 ───────────────── B1
      A2 ───────────────── B2
      A3 ───────────────── B1
      A3 ───────────────── B2

ICE performs connectivity checks and works toward selecting a usable
candidate pair.

The signaling server helped exchange the candidates.

The ICE agent determines whether the candidate pair actually works.

13. STUN and TURN

The demo intentionally uses:

const pc = new RTCPeerConnection({
  iceServers: []
});

This keeps the local experiment simple.

Real Internet connectivity is more complicated because peers can be
behind NATs and firewalls.

STUN can help discover the public-facing address observed by a STUN
server.

TURN can provide a relay when a direct path cannot be established.

Conceptually:

Direct:

Alice ───────────────────── Bob


Relay:

Alice ───────► TURN ───────► Bob

A real deployment might configure:

const pc = new RTCPeerConnection({
  iceServers: [
    {
      urls: "stun:stun.example.com:3478"
    },
    {
      urls: "turn:turn.example.com:3478",
      username: "temporary-user",
      credential: "temporary-password"
    }
  ]
});

Do not put permanent TURN credentials in production frontend code. Use
an appropriate authenticated mechanism to issue temporary credentials.

14. Watching the state machines

ICE state:

pc.oniceconnectionstatechange = () => {
  console.log(pc.iceConnectionState);
};

Overall connection state:

pc.onconnectionstatechange = () => {
  console.log(pc.connectionState);
};

You may see states such as:

new
checking
connected
completed
failed
disconnected
closed

The exact transitions depend on the browser and network.

For a successful connection, the overall connection should eventually
reach:

connected

15. Why use a DataChannel?

The demo uses a DataChannel instead of immediately introducing camera
and microphone capture.

The initiator creates one:

const dataChannel = pc.createDataChannel("demo");

Once open:

dataChannel.onopen = () => {
  console.log("Data channel is open");
};

We can send:

dataChannel.send("Hello from WebRTC!");

The remote peer receives:

dataChannel.onmessage = (event) => {
  console.log(event.data);
};

This proves that the WebRTC connection is carrying application data.

The same peer connection can also carry media tracks.

16. Adding audio and video later

Once the basic connection is understood, media can be added:

const stream =
  await navigator.mediaDevices.getUserMedia({
    audio: true,
    video: true
  });

stream.getTracks().forEach((track) => {
  pc.addTrack(track, stream);
});

The media tracks then participate in the Offer/Answer negotiation.

The architecture remains:

             RTCPeerConnection
                    │
          ┌─────────┴─────────┐
          │                   │
     DataChannel          Media Tracks
          │                   │
          ▼                   ▼
       Data            Audio / Video

17. Debugging a failed connection

When a connection fails, identify which stage failed.

Did signaling work?
        ↓
Did the Offer arrive?
        ↓
Did the Answer arrive?
        ↓
Are ICE candidates being exchanged?
        ↓
Did ICE reach "checking"?
        ↓
Did ICE find a working candidate pair?
        ↓
Did the peer connection reach "connected"?
        ↓
Is the DataChannel or media flowing?

Useful diagnostics:

pc.onicegatheringstatechange = () => {
  console.log(
    "ICE gathering:",
    pc.iceGatheringState
  );
};

pc.oniceconnectionstatechange = () => {
  console.log(
    "ICE connection:",
    pc.iceConnectionState
  );
};

pc.onconnectionstatechange = () => {
  console.log(
    "Connection:",
    pc.connectionState
  );
};

pc.onsignalingstatechange = () => {
  console.log(
    "Signaling:",
    pc.signalingState
  );
};

Once a connection exists, getStats() becomes useful:

const stats = await pc.getStats();

stats.forEach((report) => {
  console.log(report.type, report);
});

Statistics can expose information about candidate pairs, packets, bytes,
round-trip time, codecs, RTP, and DataChannels.

18. A common mistake: confusing signaling with connectivity

This is one of the most important debugging distinctions.

A successful signaling exchange:

Offer sent
Answer received

does not mean:

WebRTC connected

The browsers still need to exchange candidates and perform ICE
connectivity checks.

Think of the process as two separate problems:

Problem 1
"How do the browsers exchange setup information?"
              │
              ▼
          Signaling


Problem 2
"Can the browsers actually reach each other?"
              │
              ▼
              ICE

Solving the first problem does not automatically solve the second.

19. Another common mistake: calling `addIceCandidate()` too early

Remote candidates should be applied only after the relevant remote
description has been set.

This ordering matters:

setRemoteDescription()
        ↓
addIceCandidate()

A signaling layer should queue candidates that arrive before the remote
description is ready. This demo does that with pendingCandidates and
applies them after setRemoteDescription() completes.

The exact handling becomes especially important when messages can arrive
asynchronously or out of order.

20. Offer collisions and renegotiation

The demo assumes a simple call setup:

one initiator
one receiver
one Offer
one Answer

Real applications are more complicated.

Both peers can potentially attempt negotiation at the same time.

This creates an offer collision.

For production applications, the WebRTC community commonly uses the
perfect negotiation pattern to handle simultaneous offers and
renegotiation safely.

This becomes important when:

tracks are added or removed
transceivers change
screen sharing starts or stops
connections are renegotiated
both peers can initiate changes

The small demo intentionally avoids this complexity.

21. ICE restart

Network conditions can change after a connection has already been
established.

For example:

Wi-Fi
  ↓
network changes
  ↓
old path no longer works

WebRTC supports ICE restart so the peers can gather new connectivity
information and attempt to establish a new path.

This is one of the reasons a production WebRTC application should not
treat connection establishment as a one-time event.

Connectivity can change during the lifetime of a call.

22. Production architecture

A production system usually adds more components around this core:

                     Application
                          │
               ┌──────────┴──────────┐
               │                     │
          Signaling                 Auth
               │                     │
               ▼                     │
        WebSocket / HTTP             │
               │                     │
        ┌──────┴──────┐              │
        ▼             ▼              │
     Browser A     Browser B ◄────────┘
        │             │
        └──────┬──────┘
               │
        RTCPeerConnection
               │
        ┌──────┴──────┐
        │             │
      STUN           TURN
        │             │
        └──────┬──────┘
               │
          Network path

Production concerns include:

authentication
authorization
room lifecycle
reconnects
offer collisions
renegotiation
ICE restarts
TURN credential management
metrics
observability
rate limiting
abuse prevention
browser compatibility
failure handling

The demo deliberately leaves these out so the connection lifecycle
remains visible.

23. The complete lifecycle

Put everything together:

Create RTCPeerConnection
          ↓
Configure media / data
          ↓
Create SDP Offer
          ↓
setLocalDescription()
          ↓
ICE gathering
          ↓
Send Offer through signaling
          ↓
Remote setRemoteDescription()
          ↓
Create SDP Answer
          ↓
setLocalDescription()
          ↓
Send Answer through signaling
          ↓
Remote setRemoteDescription()
          ↓
Exchange ICE candidates
          ↓
ICE connectivity checks
          ↓
Select usable candidate pair
          ↓
WebRTC connection established
          ↓
DataChannel / Audio / Video

This is the sequence hidden behind the application's Call button.

24. The mental model

After working through the implementation, the terminology becomes easier
to remember:

Signaling moves negotiation information between applications.

SDP describes the proposed session.

Offer proposes a session configuration.

Answer responds with the configuration accepted by the other peer.

ICE discovers and tests possible network paths.

ICE candidate describes one possible network endpoint.

STUN helps discover a server-reflexive network address.

TURN provides a relay when a direct path cannot be established.

Trickle ICE sends candidates as they are discovered.

The relationship is:

Signaling
    │
    ├── Offer
    ├── Answer
    └── ICE candidates
            │
            ▼
      RTCPeerConnection
            │
            ├── ICE connectivity
            ├── DataChannel
            └── Audio / Video

25. Break the demo on purpose

Once the demo works, deliberately break one part.

For example, temporarily remove:

socket.send(JSON.stringify({
  type: "ice-candidate",
  candidate: event.candidate
}));

The peers can still exchange:

Offer
Answer

but they are no longer exchanging trickled ICE candidates.

Watch the connection state.

This is where WebRTC becomes much easier to understand.

Don't just read the terminology. Change something. Break something.
Watch what changes.

DEV Community: Rittly Labs

Your Browser Found an Address. Now Let's Find a Path.

What We're Building

1. Create the Playground

2. The Complete Lab

3. Start the Lab

4. Open Two Tabs

5. Watch ICE Work

6. Look at the Candidates

7. Prove the Path

8. Inspect the Candidate Pairs

What's Happening Underneath?

What About TURN?

Try Something Different

The Important Mental Model

1. Candidate

2. Candidate Pair

3. Connectivity Check

What Did We Actually Learn?

The Road Is Ready

Part 3 — Your Browser Found a Path. Now Let's Send Something Through It.

References

Your Browser Is Behind a Router. Let's See What It Actually Knows.

Let's start.

1. Prerequisites

2. Create the playground

3. Run it

4. What should you see?

5. What is an ICE candidate?

6. The host candidate

7. Let's inspect the candidate object

8. Why does setLocalDescription() matter?

9. Why did we create a data channel?

10. Where does NAT enter the picture?

11. Add a STUN server

12. The srflx candidate

13. A candidate is not a connection

14. What if I don't see 192.168.x.x?

15. Try it on different networks

16. What we have learned

17. One browser isn't enough

18. The important mental model

19. Where we are in the WebRTC journey

The Call That Hasn't Started Yet

What this article adds

1. Architecture

2. Project

3. Signaling server

4. Browser application

5. What happens?

6. Signaling is application-defined

7. Creating the Offer

8. Why setLocalDescription() matters

9. Receiving the Offer and creating the Answer

10. ICE candidates

11. Trickle ICE

12. ICE connectivity checks

13. STUN and TURN

14. Watching the state machines

15. Why use a DataChannel?

16. Adding audio and video later

17. Debugging a failed connection

18. A common mistake: confusing signaling with connectivity

19. Another common mistake: calling addIceCandidate() too early

20. Offer collisions and renegotiation

21. ICE restart

22. Production architecture

23. The complete lifecycle

24. The mental model

25. Break the demo on purpose

References

6. The `host` candidate

8. Why does `setLocalDescription()` matter?

12. The `srflx` candidate

14. What if I don't see `192.168.x.x`?

8. Why `setLocalDescription()` matters

19. Another common mistake: calling `addIceCandidate()` too early