Why architecture matters here
WebRTC fails on NAT (peers can't connect), on bandwidth (media stutters), and on browser variance (different behaviors across Chrome, Firefox, Safari). The architecture matters because each is addressed by a specific layer.
The architecture: every piece explained
The top strip is setup. Signaling exchanges SDP out-of-band (WebSocket, HTTP). ICE gathers candidates (host, srflx via STUN, relay via TURN). STUN / TURN handle NAT — STUN discovers public address, TURN relays when direct fails. DTLS + SRTP encrypt.
The middle row is media + data. Media pipeline encodes with a codec (Opus, VP8/VP9, H.264, AV1), jitter buffer smooths. Data channel uses SCTP over DTLS for arbitrary bytes. Bandwidth adaptation uses REMB or GCC. SFU/MCU handle multiparty.
The lower rows are ops. Observability via getStats. Fallback to TURN when P2P blocked. Ops covers TURN capacity, browser variance, and testing.
End-to-end flow
End-to-end: two peers signal via WebSocket. ICE candidates gathered; STUN discovers public IPs; connection attempts fail through symmetric NAT; TURN relay used. DTLS handshake; media flows via SRTP with GCC-adjusted bitrate. Data channel used for chat. Users A + B communicate low latency.