Voice Calls

Messaging is asynchronous.

Voice calls are real time.

That changes the architecture completely.

Apps usually build this with WebRTC ideas —

Web Real-Time Communication.

WebRTC is a set of standards and APIs for live audio, video, and data between devices,

with low latency,

once a connection is established.

---

Step 1

Alice presses Call.

The server does not carry the audio immediately.

It first performs signaling.

Signaling is the short “call logistics” chat —

not the voice itself.

• Set up: “Alice is calling Bob” → “Bob, incoming call” → “Bob accepted” → “here’s how we can reach each other.”

• Tear down: “hang up” / “call ended” so both sides stop cleanly.

Think of a receptionist connecting two people:

they arrange the meeting,

then step aside so the two can talk directly.

The signaling server only coordinates the connection.

---

Step 2

Both devices need each other’s network addresses so they can connect.

But there’s a catch: NAT — Network Address Translation.

Your home/office router shares one public internet address among many devices.

Inside the Wi‑Fi, phones use private addresses (like 192.168…).

NAT is the translator at the door:

it rewrites traffic so devices can reach the internet,

and replies can find the right phone.

That’s why a phone often doesn’t know its public address on its own.

Through signaling, devices share possible ways to reach each other —

public IP, private IP, and other network candidates —

then try them until one works.

To work around NAT, call setup commonly uses

• ICE — Interactive Connectivity Establishment

  A checklist: try every possible path between Alice and Bob, and pick one that works.

• STUN — Session Traversal Utilities for NAT

  A helper that answers: “From the public internet, what address do I look like?”

  Because of NAT, your phone can’t always see that itself — STUN asks a public server and finds out.

• TURN — Traversal Using Relays around NAT

  A middleman when direct contact fails (strict firewalls, hard NAT).

  Voice goes Alice → TURN → Bob — works, but usually slower/costlier than direct.

---

Step 3

Each side often asks a STUN server:

“How do I appear on the public internet?”

That public address becomes a candidate path in ICE.

Whenever possible,

the devices then communicate directly —

Alice ↔ Bob —

without the signaling server in the middle.

This minimizes latency.

---

How Devices Connect

1. Signaling sets up the call and shares connection info.

2. ICE (with STUN, and TURN if needed) finds a working network path.

3. The media session starts on that path.

---

How Voice Is Transmitted

After the connection is ready,

the mic audio is encoded into small packets.

Those packets flow

• peer-to-peer when possible (Alice ↔ Bob), or

• through a TURN relay when direct paths fail.

They do not go through the signaling server.

Signaling only arranged the call;

the voice takes a different road.

---

TURN Relay

Sometimes direct communication isn't possible.

Example

Corporate firewalls

Strict NAT

In that case,

traffic passes through a TURN relay.

---

Why Separate Signaling?

The signaling server only helps establish the connection.

Once the call begins,

audio usually bypasses the signaling server.

This reduces infrastructure cost.

---

Interview Notes

Interviewer

Does WhatsApp route every voice packet through its backend?

Answer

Not necessarily.

The backend performs signaling.

Whenever possible,

audio flows directly between devices (WebRTC-style peer connection).

TURN is only used when required.

---

Key Takeaways

✔ Signaling sets up and tears down the call — it is not the voice.

✔ WebRTC-style stacks move live audio after a path is found.

✔ ICE tries candidate paths; STUN discovers public addresses; TURN relays when needed.

✔ Direct peer-to-peer communication reduces latency.

---