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:

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