> ## Documentation Index
> Fetch the complete documentation index at: https://docs.duvo.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Clarity network requirements
> Hosts, ports, and protocols your network and devices must allow for Clarity voice interviews, plus a self-serve connection test.
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//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 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.
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-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.
HTTPS to the Duvo app and API. This is the same access needed to use Duvo at all.
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.
| Purpose | Host | Port / protocol |
| - | - | - |
| Duvo app | `app.duvo.ai` | TCP 443, HTTPS |
| Duvo sign-in | `login.duvo.ai` | TCP 443, HTTPS |
| Duvo API, including WebRTC call setup | `platform.duvo.ai` | TCP 443, HTTPS |
| Duvo voice relay (recommended for strict networks) | `turn.prd.duvo.ai` (fixed IP `34.78.100.100`) | TCP 443, TLS (TURN over TLS) |
| Voice service — direct WebRTC audio | OpenAI media servers | Outbound UDP (SRTP/DTLS), or TCP 443 to the same servers when UDP is blocked. Their addresses change; if you can't allow them, the relay above carries the audio. |
| Voice service — WebSocket (last resort) | `eu.api.openai.com` | TCP 443, WSS |
| Recording upload | `storage.googleapis.com` | TCP 443, HTTPS (PUT) |
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
Capture processes with voice interviews, recordings, and documents.
Turn a documented process into a running Agent.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.