Skip to main content
Clarity voice interviews run in the browser and stream audio to an AI voice service in real time. On managed corporate devices and networks, a firewall, proxy, or device policy can block one of the pieces an interview needs. This page lists exactly what to allow, and how anyone on your team can check a device before involving IT.
Run the connection test first. Before your first Clarity interview, the setup screen asks you to run it: click Test connection, and when the test finishes, click Back to interview. Once you have run it, the setup screen stops asking. You can run it again any time at https://app.duvo.ai/teams/<your-team-id>/diagnostics/connection, and an interview that fails to connect offers Test this connection.The test checks the browser, microphone, and connection requirements on this page in order and produces a report you can copy and send to IT. Duvo also receives the result, so we can help when a network or device blocks interviews. Run it on the same machine and network you will use for the interview.

​
What an interview needs

A supported browser

A current version of Chrome, Edge, or Firefox with WebRTC enabled. With WebRTC disabled by policy, interviews can only use the WebSocket, and only if your team has it turned on. Enable WebRTC to use the faster paths.

Microphone access

The browser must be allowed to use a microphone at three levels:
  • Site permission — the browser prompts for microphone access when the interview starts. Click Allow. If the option is missing or greyed out, the browser is managed and the permission must be granted by policy for https://app.duvo.ai.
  • Operating system privacy settings — on Windows, Settings > Privacy & security > Microphone: Microphone access and Let desktop apps access your microphone must be on. On macOS, System Settings > Privacy & Security > Microphone must list your browser.
  • Device management policy — if your device is managed (Intune, Jamf, Group Policy), the administrator may need to allow microphone access for the browser and for the Duvo site. In managed Chrome or Edge, add https://app.duvo.ai to AudioCaptureAllowedUrls.

Screen sharing (screen-share interviews)

Screen-share interviews also record your screen:
  • Site permission — when the interview starts, the browser asks what to share; choose your entire screen. On managed Chrome or Edge, allow https://app.duvo.ai with the ScreenCaptureAllowedByOrigins policy.
  • Operating system privacy settings — on macOS, System Settings > Privacy & Security > Screen Recording must list your browser.
Voice-only interviews don’t need screen sharing. Clarity never uses the camera.

Access to Duvo

HTTPS to the Duvo app and API. This is the same access needed to use Duvo at all.

A voice connection

Interviews connect over WebRTC, either directly to the voice service or through Duvo’s voice relay. The browser tries three paths in order and uses the first one that connects; the WebSocket is only a last resort:
  • Direct WebRTC — call setup over HTTPS through Duvo, then encrypted audio straight to the voice service’s media servers: over UDP, or over TCP on port 443 to the same servers when UDP is blocked. This is the fastest path.
  • Duvo voice relay — when the media servers can’t be reached (typically a proxy that only lets named hosts through), the same WebRTC connection runs over TLS on port 443 to Duvo’s relay instead. On strict networks this is the path to allow: it needs only Duvo hosts. It exists only on deployments that provide a relay (app.duvo.ai does), and the connection test checks it and lists the relay host in its report.
  • WebSocket (last resort) — port 443 to the voice service, used only when neither WebRTC path connects. Replies are about a second slower. Allowing it is optional. Your Duvo contact can turn it off for your team, or make it the first path where a network needs it.

​
Hosts, ports, and protocols to allow

Allow by hostname where you can. The voice service and Duvo’s platform use cloud infrastructure whose IP addresses change. The one exception is Duvo’s voice relay: turn.prd.duvo.ai has the fixed address 34.78.100.100, for firewalls that can only match on IP.
The hosts below apply to app.duvo.ai. The copied connection-test report always lists the exact hosts configured for your environment — use it as the source of truth if they differ. Notes for network administrators:
  • WebSockets must not be downgraded. Some proxies terminate or strip the Upgrade: websocket handshake. The WSS upgrade to eu.api.openai.com must pass through untouched for the WebSocket path. Duvo’s live updates also use a WebSocket on platform.duvo.ai; they fall back to polling when it’s blocked, so allowing it is recommended rather than required.
  • Exempt the relay from TLS inspection and HTTP-only proxy rules. turn.prd.duvo.ai carries TURN over TLS, not HTTPS, so TLS inspection or a rule that only passes HTTP breaks it.
  • TLS inspection of eu.api.openai.com traffic will usually break the WebSocket connection. Exempt this host from inspection.
  • Don’t cut long-lived connections. Each voice connection stays open for up to 50 minutes before the browser swaps in a fresh one, so allow connections that last at least an hour.
  • If outbound UDP is blocked, the live connection carries its audio over TCP 443 to the voice service’s media servers instead; nothing else changes. If those media servers cannot be reached at all (UDP and TCP 443 both blocked, as on networks that only allow named hosts through a proxy), on deployments that provide a relay the interview moves to the voice relay on its own. The relay carries all interview audio over TLS on port 443 to turn.prd.duvo.ai, so no UDP or direct connection to the voice service’s media servers is needed — allow the relay host and the interview keeps its live connection. Without a relay, the interview moves to the WebSocket instead, unless your team has that path turned off.
  • The connection test report lists the hosts a given device actually used. If your team is on a different region or a custom configuration, trust the report over this table.

​
Troubleshooting with the connection test

The test runs six checks in order — browser support, microphone, Duvo connection, direct voice connection, Duvo voice relay, and WebSocket fallback — and stops early only when a later check cannot run. The relay check is marked not applicable on deployments without a relay. The result tells you whether an interview can start on that device and network, and why not if it cannot.
  • Access denied — the browser or its policy blocks the microphone for the Duvo site. Click the lock or camera icon in the address bar and allow the microphone. If you cannot, the site permission must be allowed by your device policy.
  • No microphone found — no input device is available. Connect a headset or enable the built-in microphone in the OS sound settings.
  • Microphone could not be opened — a device exists but the browser cannot use it. Close other apps that may hold it (Teams, Zoom), then check the OS privacy settings above. On managed devices this is usually a policy setting.
The test still runs the network checks with a silent stand-in stream, so the report tells IT whether the network is fine once the microphone is fixed.
Duvo’s API could not be reached. Check the internet connection, and that platform.duvo.ai is allowed on TCP 443.
The copied report says where the direct connection failed, and the two cases need different fixes:
  • Media path (peer-connection): the connection setup through Duvo worked, but the connection to the voice service’s media servers never established; neither the UDP nor the TCP 443 candidates connected. An interview still starts when a fallback is available: it moves to the voice relay when the deployment provides one and turn.prd.duvo.ai is allowed, and otherwise to the WebSocket if your team has that path enabled. The fix is to allow turn.prd.duvo.ai on TCP 443 (TLS): the media servers’ addresses change, so reaching them directly means opening outbound UDP or TCP 443 broadly.
  • Connection setup (sdp-exchange with network-error, timeout, or http-response): the setup exchange with Duvo’s API failed before any audio was sent. network-error and timeout mean the request never got a usable answer, which points at the network. http-response means the request was answered with an error status, and the copied report shows which one next to the failure: a 5xx status points at Duvo or the voice service, or at a proxy that couldn’t reach them, so send the report to your Duvo contact and to IT; a 4xx status usually means a proxy blocked or rewrote the request. The relay uses the same setup path, so allowing the relay host does not help here; the interview moves straight to the WebSocket if your team has that path enabled. For a network cause, have IT check that platform.duvo.ai is reachable on TCP 443 without a proxy blocking or rewriting requests to it.
The test result states whether an interview can start on this device as configured.
A firewall or proxy blocks every voice path. Confirm with another network (a phone hotspot), then send the copied report to IT with the table above. Unless the report shows the failure at connection setup (sdp-exchange), allowing turn.prd.duvo.ai on TCP 443 (TLS) is usually the smallest change that gets interviews working.

​
Next steps

Clarity

Capture processes with voice interviews, recordings, and documents.

Clarity to Agent

Turn a documented process into a running Agent.