DeskTest.net
GitHub

Call Readiness Test Guide

A reference for the DeskTest.net Call Readiness Test: the one-page pre-flight that checks your camera, microphone, speakers, and network before a Teams, Zoom, or Meet call. This guide covers what each step checks, how to read the verdict, and what to do about each failure.

Open the Call Readiness Test →

What does the Call Readiness Test check?

The tool drives standard browser APIs: getUserMedia for the camera and microphone, the Web Audio API for the speaker tone and the mic level meter, and a single fetch to the desktest edge for network latency. No plugin, no extension, no upload. It runs four steps in order:

  1. Camera works. Behind a Start button (browsers require a click before granting camera access), it requests getUserMedia and shows a small live preview. It reads the negotiated resolution, frame rate, and device label, confirms frames are actually flowing, then stops the camera track so the camera light turns off.
  2. Microphone works. The audio track from step 1 feeds a Web Audio AnalyserNode. A live input-level meter moves as you speak; a non-zero peak level passes. The mic label is reported, then the audio track is stopped.
  3. Speakers work. A short, gentle 440 Hz tone plays in both the left and right channels. You confirm Yes or No that you heard it.
  4. Network is ready for a call. It reads navigator.onLine and measures round-trip latency to edge.desktest.net. High latency warns, because voice and video calls need a low, steady round-trip.

This is deliberately different from the WebRTC Test, which exercises an actual peer connection (STUN/TURN, ICE, media flow between browsers). The Call Readiness Test checks the local pieces a person controls before a meeting: their own devices and their own network path.

When should I run this?

Reading the results

Each step shows a status badge: Pending (gray), Running (yellow), Pass (green), Warn (yellow), or Fail (red). On a warn or fail, the row expands with what the API returned and a numbered checklist.

The verdict panel at the top summarizes overall readiness with a likely cause and a recommended next step. A blocked camera is a warning, not a hard failure, because you can still join a call audio-only; a blocked or silent microphone is treated as more serious, because nobody will hear you.

Copy Diagnostic Report copies a plain-text report: user-agent, platform, camera label and resolution, mic label and peak level, whether the tone was heard, network latency, and per-step diagnoses. Paste it into a ticket. Send to your IT opens the same text in a pre-filled email.

Common failures and fixes

Camera blocked (warning)

getUserMedia threw NotAllowedError. This is a warning, not a failure - you can still join audio-only. To turn video on: click the camera icon in the address bar (Chrome, Edge, or Firefox) and set this site to Allow, then reload. On Safari, use Settings then Websites then Camera. Also confirm the OS lets the browser use the camera: Windows Settings then Privacy then Camera, or macOS System Settings then Privacy and Security then Camera.

No camera detected

The browser found no video input, or the camera returned no picture. Plug the webcam directly into a USB port, open any laptop privacy shutter, and confirm the OS Camera app can see it. If another app (Teams, Zoom, OBS) already holds the camera, close it - most webcams cannot be shared.

Microphone blocked or silent

If permission was blocked, allow the microphone the same way as the camera (address-bar icon, then reload). If the meter never moved, the mic is reading silence: check for a physical mute switch on the headset or webcam, confirm the correct input is the OS default, and raise its input level. A boom mic should sit near your mouth. Try a different mic to separate a bad device from a driver issue.

No tone heard

The browser played a tone but you clicked No. Confirm system volume is up and not muted, that the right output (speakers or headphones) is selected in the OS sound settings, and that the browser tab itself is not muted (right-click the tab). If you heard it in only one ear, check the OS left/right balance and try another pair of headphones.

Offline or unreachable network

If navigator.onLine is false, reconnect Wi-Fi or ethernet and turn off airplane mode. If the browser thinks it is online but the edge endpoint cannot be reached, a firewall, proxy, or captive portal is likely in the path - which will also block your call app. On guest or hotel Wi-Fi, open any plain http:// site to trigger the sign-in page. Disconnect a VPN and retry.

High latency (warning)

The network is reachable but the round-trip is above roughly 250 ms. Calls will feel delayed and may stutter. Prefer a wired connection over Wi-Fi, move closer to the access point, close background downloads, or disconnect a congested VPN, then rerun. This measures latency to the desktest edge, not the meeting server, but a low, steady round-trip here is a good sign a call will hold up.

Privacy: what stays local

Your camera and microphone never leave this device. The video is shown only in the local preview, the microphone feeds only the on-screen level meter through the Web Audio API, and nothing is ever recorded, saved, or transmitted. Every camera and microphone track is stopped the moment its step finishes - and again on reset and when you leave the page - so the device indicators turn off. The report contains only device labels, the resolution seen, the peak mic level, and the network round-trip. It never contains any audio or video. View source to verify.

For IT admins

Camera and microphone access is governed at two layers: per-site browser permission and the OS privacy switch. Both must allow the browser.

Chrome / Edge. Push via GPO, Intune, or Jamf. Keys: VideoCaptureAllowed and AudioCaptureAllowed (global booleans) plus VideoCaptureAllowedUrls and AudioCaptureAllowedUrls (URL patterns that bypass the prompt, e.g. https://desktest.net).

Firefox. Push policies.json with Permissions.Camera and Permissions.Microphone: an Allow array of origins, plus BlockNewRequests: true.

Windows. Camera and microphone are gated under Settings then Privacy. Push via the Camera and Microphone Policy CSPs (LetAppsAccessCamera, LetAppsAccessMicrophone). Windows feature updates sometimes reset these; check first if a device dies right after an update.

Network. The latency check is a single HTTPS request to edge.desktest.net. If your egress filtering blocks it, the check fails even though the call app might use different hosts - use it as a signal, and confirm against your meeting vendor's own connectivity tester for exact hostnames.