WebRTC API basics

WebRTC enables peer-to-peer **media** (audio/video) and **data channels** in browsers with low latency. It is not a generic REST replacement — it solves realtime P2P after signaling establishes session parameters.

Core pieces:

• **getUserMedia** — capture camera/mic (permissions, device selection).
• **RTCPeerConnection** — ICE candidates, codecs, encryption (DTLS-SRTP).
• **RTCDataChannel** — arbitrary binary/text between peers.
• **Signaling** — out-of-band API (often WebSocket/HTTP) exchanges SDP offers/answers and ICE candidates; WebRTC does not standardize signaling.

NAT traversal:

• **STUN** discovers public address.
• **TURN** relays when direct P2P fails (cost and ops heavy).

					const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
const channel = pc.createDataChannel('chat');
pc.onicecandidate = (e) => signaling.send({ candidate: e.candidate });
				

On interviews: where WebRTC fits (calls, screen share, low-latency data), why you still need a signaling server, and TURN operational cost.

Common pitfalls: no TURN fallback (fails on strict NAT), signaling without auth, assuming WebRTC replaces server media mixing for large conferences.

The trade-off is P2P efficiency versus operational complexity — most products need managed TURN and monitoring.

Checklist:

• Signaling channel authenticated.
• STUN + TURN for production reliability.
• Handle connection state and renegotiation.
• Separate media path from application REST API.