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.
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 statsdeploy/coturn/ — TURN server configurationapp/GlobalChatService/config/icebind_test.go, normalize_webrtc_test.go, turnhost_test.go, audsplit_test.go, apnsbind_test.go — ICE binding and SDP normalization under testdocs/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