WebRTC Test

Introduction

The DeviceHub WebRTC Test is a free online capability smoke test for RTCPeerConnection and closely related constructor availability, so you can learn whether realtime APIs were stripped from your profile before debugging video chat apps, without treating this page as an IP leak audit or network penetration tool. Developers, IT staff, and support agents confirm WebRTC exists after policy changes; they should not expect STUN-based public IP disclosure results here. DeviceHub states the scope plainly: capability and smoke testing only, do not claim this page proves IP leak outcomes; Network category DeviceHub tools will address leak-style checks later when they ship. Pair with Browser Features for broader API rows and dedicated camera/microphone hardware tools when media paths fail after constructors pass. Hospital telehealth vendors verifying managed Chrome builds use constructor smoke before rolling out browser-based consult rooms to clinics with strict GPO templates. Headless Chrome may strip RTCPeerConnection though interactive profiles include it, label automation context. Telehealth vendors must not cite this smoke as HIPAA network proof, constructor presence is only the first gate before separate security review. Insertable Streams APIs are out of scope, video pipeline teams need separate checks beyond RTCPeerConnection smoke. Hospital IT verifying Chrome policy did not strip realtime APIs uses constructor smoke, not IP leak audits, before enabling telehealth URLs. Telehealth IT uses constructor smoke, not IP leak audits, before enabling browser consult URLs on managed Chrome. VPN changes real calling paths beyond constructor checks, note VPN state in calling app tickets. Corporate SSL inspection rarely removes RTCPeerConnection yet often breaks TURN, constructor smoke passing still leaves network work. H.264 hardware encode availability is separate from RTCPeerConnection presence, video codec tickets need getCapabilities checks elsewhere.

What this tool does

Lightweight checks verify RTCPeerConnection, related interfaces, and baseline API presence without gathering ICE candidates for exfiltration, running full peer connectivity, or displaying public IP readouts. UI copy repeats that VPN, mDNS, TURN configuration, and firewall rules affect real calls beyond constructor success. Failures may reflect enterprise policy, old WebViews, or non-secure contexts rather than DeviceHub server errors. Success here means the constructor existed, not that UDP flows will traverse corporate firewalls. Corporate TLS inspection breaking TURN is invisible to constructor smoke, network teams still have work when constructors pass. mDNS host candidates and STUN reflexive candidates are intentionally not gathered here, Network category tooling will cover leak-style analysis later. Insertable Streams APIs are out of scope, video pipeline teams need separate checks beyond RTCPeerConnection smoke. Optional data channel constructor checks when listed are separate from media tracks, signaling-only apps still care about RTCPeerConnection. Constructor success does not prove UDP traverses corporate firewalls, network path stays separate investigation. Enterprise GPO removing WebRTC leaves missing constructors, paste policy context beside smoke failures. RTCRtpSender setParameters bandwidth tuning is beyond constructor smoke, call quality tickets need media path tools. Browser autoplay policies block remote audio playback even when peer connection constructs, media element policy is another layer.

When to use it

Run after GPO or extension policy blocks realtime apps, when embedded WebViews lack RTCPeerConnection, or before blaming network hardware for missing APIs. Do not use this page when the ticket explicitly demands IP leak verification, wait for Network tools or use appropriate security processes outside DeviceHub. Run before escalating WebRTC calling apps on Citrix when the real issue may be stripped APIs in the published browser profile. Insertable streams and encoded transforms are not covered, video pipeline features extend beyond this smoke. Insertable Streams APIs are out of scope, video pipeline teams need separate checks beyond RTCPeerConnection smoke. Headless automation may strip RTCPeerConnection though interactive Chrome includes it, label capture context. Data channel constructor rows when listed differ from media tracks, signaling-only apps still need RTCPeerConnection. Simulcast and SVC negotiation layers sit above constructor checks, Zoom-like apps need end-to-end call repro. getStats() polling for packet loss is out of scope, constructor smoke does not open peer connections or gather ICE candidates.

How it works

Smoke logic inspects globals and may instantiate peer connection objects in guarded try blocks without connecting to remote peers or leaking addresses. getUserMedia is out of scope on this page permissions-none design, media belongs on hardware-category tools. Secure HTTPS aligns with WebRTC expectations on many engines. Safari and Firefox may differ in optional interfaces compared with Chromium; document engine names in tickets. mDNS ICE candidates and host candidates are not collected here by design. Insertable Streams APIs are out of scope, video pipeline teams need separate checks beyond RTCPeerConnection smoke. Insertable Streams and encoded transforms extend beyond this smoke, video teams need additional checks. Do not interpret smoke success as public IP leak proof, DeviceHub scope is capability only until Network tools ship. Enterprise TLS inspection breaking TURN over TLS is invisible here, constructor success still leaves calls failing. Screen capture getDisplayMedia is separate from RTCPeerConnection, conference apps failing screen share need media tools next.

Step-by-step instructions

1. Open WebRTC Test over HTTPS because many WebRTC-related APIs expect secure context on modern engines. State clearly in ticket header: WebRTC smoke only, not IP leak audit, before network joins thread.
2. Run the capability smoke and record whether RTCPeerConnection and listed helpers exist in this profile. If constructors missing, capture Browser Information policy hints and extension list same session.
3. Do not interpret success as proof of public IP leak, DeviceHub limits scope to API presence smoke until Network category tools exist. Do not attach STUN server logs to this smoke, they are out of scope for constructor checks.
4. If constructors pass but calls fail in apps, investigate TURN servers, VPN, firewall, and media permission tools separately. Retest on local machine when initial smoke ran inside remote desktop session.
5. Capture Browser Information when enterprise policy may have disabled WebRTC while leaving other APIs intact. If constructors pass, escalate media paths to camera/mic hardware tools separately from this page.
6. Note in tickets that this smoke does not replace packet capture or ICE troubleshooting, it only answers whether APIs were present in script. Note VPN connected state when calling apps fail despite constructor success here.

Common problems

Users expecting ICE leak demos misunderstand page scope. VPN and corporate proxies change real calling paths beyond constructor checks. WebView shells may strip RTCPeerConnection entirely. Confusing this smoke with WebRTC bandwidth or quality testing overpromises. Passing constructor smoke while UDP is blocked company-wide leads to false “browser is fine” conclusions, network path remains separate. Insertable Streams APIs are out of scope, video pipeline teams need separate checks beyond RTCPeerConnection smoke. Confusing constructor success with UDP firewall passage keeps network teams in loops, this page never claimed to test UDP. mDNS and STUN candidate gathering intentionally omitted, Network category tools will address leak analysis later. TURN server misconfigurations invisible here, constructor passing still leaves calls failing in apps. WebRTC data channels for game networking need separate latency tests, constructor presence is only the first gate. Perfect negotiation pattern in modern apps sits above constructor checks, signaling state machine bugs need application-level logs.

Privacy explanation

Constructor smoke does not upload SDP or ICE candidate lists. No camera or microphone permission is required for API presence checks on this page. Closing the tab ends the smoke UI. Nothing in this test dials outbound STUN to fingerprint your network, that behavior is intentionally omitted. Insertable Streams APIs are out of scope, video pipeline teams need separate checks beyond RTCPeerConnection smoke. WebView shells stripping RTCPeerConnection produce undefined constructors, environment scope, not DeviceHub bugs. Safari WebRTC interfaces differ slightly from Chromium, document engine when comparing smoke across browsers. RTCPeerConnection iceTransportPolicy relay-only settings in apps are not applied during constructor smoke, calls may still fail behind symmetric NAT.