# 6 — WebRTC Calling Plane: Audit & Protocol Depth

**Rank 7 of 28** · Tier A · `app/GlobalChatService`, `docs/webrtc-chat/`, `deploy/coturn`
**Stack:** WebRTC, pion (Go SFU), coturn (TURN/STUN), gorilla/websocket, Cloudflare Tunnel, Cassandra, Redis, Kafka
**Status:** 20-chapter engineering manual complete. Signaling relay live; SFU path identified as orphaned.

> **Why this ranks here.** Real-time media is the deepest protocol work in the
> tree — NAT traversal, ICE candidate gathering, SDP negotiation, and a media
> plane. And the audit's headline finding is a **fatal concurrent-map race in
> the call path**, which is precisely the class of bug a senior Go interview is
> built to detect.

---

## The manual

`docs/webrtc-chat/` — 20 chapters with mermaid diagrams:

| | |
|---|---|
| 01 Executive summary | 11 Data layer — Cassandra |
| 02 System architecture | 12 Kafka / Redis events |
| 03 Protocol specification | 13 Security & auth |
| 04 Backend — Go GlobalChatService | 14 Observability |
| 05 Signaling & call lifecycle | 15 Deployment & runbook |
| 06 Media plane — SFU and P2P | 16 Gap register |
| 07 ICE / STUN / TURN | 17 Remediation roadmap |
| 08 iOS client | 18 Onboarding guide |
| 09 Web client | 19 Appendices |
| 10 Cloudflare edge | 20 Task list |

## The findings

### It is P2P, and the SFU is orphaned
`SessionManager` (pion SFU), `MediaRouter` (RTP forwarding), and `RoomMedia`
(moderation) are all implemented and **all unreachable from the live call
path**. Calls go peer-to-peer via `CallManager` acting as a pure signaling
relay. The manual states this plainly rather than presenting the SFU as
working — and then explains the consequence: no server-side recording, no
moderation hook, and N² media paths in a group call.

### Calling was down on three independent failures
- **DNS**: the signaling hostname had **no DNS record at all**, yet both
  clients dial `wss://<signaling-host>/ws`.
- **Tunnel**: the Cloudflare tunnel hostname mapping did not route to the WSS
  listener.
- **TURN**: coturn reachability, without which every call behind a symmetric
  NAT fails to connect.

Three separate single points of failure on one feature, each documented with
the exact host, port, and config that proves it.

### G-07 — the fatal map race
A concurrent map access in the call path — the Go runtime's `fatal error:
concurrent map writes`, which is **not recoverable and not catchable**. It
takes the whole process down, so it does not degrade one call, it drops every
connection on the host. Located, documented in the gap register, and given a
remediation entry.

## Why the audit form is itself the credential

Anyone can say "I know WebRTC." This is a document that:
- traces every hostname the client dials to the line of code that dials it,
- states which components are live and which are dead code,
- names the failure as a *class* (unrecoverable runtime fatal) rather than a symptom,
- and ships a numbered remediation roadmap and task list.

That is a design-doc-and-postmortem skill set, written down and reviewable.

## Supporting evidence in-tree

- `TESTS/WEBRTC/rtcstats_dump.gz`, `webrtc_internals_dump.gz` — real captured session stats
- `deploy/coturn/` — TURN server configuration
- `app/GlobalChatService/config/icebind_test.go`, `normalize_webrtc_test.go`, `turnhost_test.go`, `audsplit_test.go`, `apnsbind_test.go` — ICE binding and SDP normalization under test
- `docs/TheOne-WebRTC-Chat-Engineering-Manual.pdf` / `.docx` — the manual, typeset

## Interview surface this opens

- ICE: host / srflx / relay candidates, and why TURN is not optional
- SDP offer/answer, trickle ICE, and glare resolution in signaling
- P2P vs SFU vs MCU: bandwidth, CPU, and moderation trade-offs
- Go's unrecoverable fatals vs panics, and how you design maps out of hot paths
- Diagnosing a feature that is down for three unrelated reasons at once