Two browsers. One connection.
Build a two-person video room with real WebRTC. Exchange an offer and an answer yourself, then watch the browsers negotiate a direct connection.
- Both people: open this page over HTTPS and choose the same mode below.
- Person A: create an offer, wait for ICE gathering, and privately send the entire output package to Person B.
- Person B: paste A's package into the input box and select “Accept offer + create answer”. Send the resulting answer back privately.
- Person A: paste B's answer and select “Apply answer”. Keep both pages open. For video, enable remote sound when ready; headphones prevent feedback.
01 / Choose your experiment
Camera and microphone are requested only when you click their button. Diagnostic mode sends only a fixed test ping/pong over a real data channel, with no media permission.
Off by default (local-network paths only). Enabling STUN may help discover a public-facing address; it is not a relay or a connectivity promise. When an offer/answer is created, Google can receive your IP address and network metadata. Your peer can learn network addresses even with STUN off. Do not use this with untrusted strangers. End the call before changing this option.
JavaScript is required. No media is captured before you choose to start.
Connection: idle
No session
Your preview
Always muted locally to avoid echo.
Your peer
Starts muted. Sound is your choice.
02 / Exchange connection packages
Version 1 envelope: schema, version, sessionId, mode, type and sdp. The session ID links an answer to its offer; it is not a room address or proof of identity. Start again after refresh, errors or changing devices.
03 / Observe the connection
No diagnostic connection
A returned pong confirms a data-channel round trip, not camera quality or Internet-wide compatibility.
What happens under the hood?
RTCPeerConnection negotiates media and data. The offer and answer describe capabilities and candidate network paths. This lab waits for ICE gathering to finish and includes the candidates in each package (“non-trickle ICE”), so only two manual messages are needed. ICE then tests connectivity.
WebRTC media uses DTLS-SRTP encrypted transport; the data channel uses DTLS. Encryption does not identify the human peer. A malicious signaling intermediary could substitute packages. Verify whom you are talking to through a trusted channel; this demo is not an authenticated conferencing system.
Connection failed, black video, or no sound?
- Use current browsers over HTTPS; embedded views may block media permissions. Open the page directly.
- For media, both users must allow camera and microphone. Device conflicts or denied permissions require correcting browser/OS permission settings yourself.
- Use matching modes and fresh packages from the same session. End/reset closes connections and stops tracks; disabling video is not the same as releasing the camera.
- STUN does not bypass restrictive NATs/firewalls. TURN would require a relay service and secure credential management outside this static demo. Do not weaken firewall or security settings to make the lab work.
- Remote audio starts muted. Press “Enable remote sound” or use the remote video's controls. A peer can record what you send; the lab cannot prevent it.
- Two tabs in media-free mode are useful for a local protocol experiment, but do not prove cross-network calls work.
Official technical references
- MDN: signaling and video calling
- MDN: RTCPeerConnection
- MDN: camera/microphone permissions
- W3C: WebRTC specification
- WebRTC project: STUN/ICE example
Reviewed 24 October 2026. No external library or backend is loaded by this lab's code. The surrounding blog remains subject to its own privacy policy.