Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.apifycloud.io/llms.txt

Use this file to discover all available pages before exploring further.

Organised by symptom — search for what your users report, not what you think the cause is. Each entry links to the relevant guide for the full context.

​
The meeting page doesn’t load

WebRTC requires HTTPS. The page embedding the meeting and the meeting URL itself must both be served over HTTPS. See Network requirements.
Some blocklists flag third-party embedded runtimes. Ask the user to allowlist the meeting origin, or test with blockers disabled to confirm.
Some in-app browsers strip WebRTC support or block camera permissions. Ask the user to open the link in the system browser via the app’s “Open in browser” menu. See Browser & device support.

​
Camera or microphone won’t start

Browsers cache the denied state indefinitely per origin. The user has to reset it from the browser’s site-settings menu (the lock icon next to the URL). Pages can’t programmatically re-prompt after a denial. See Permissions.
macOS, Windows, iOS, and Android all have an OS-level camera / microphone toggle per app. If that toggle is off for the browser, no permission in the browser will help until the OS gate is opened.
When the meeting is embedded, the outer <iframe> must explicitly allow the features. See Permissions — Embedding.
Some native video apps — for example Zoom, Microsoft Teams, Google Meet, Slack huddles, Discord, and similar tools — take an exclusive lock on the camera or microphone and hide it from the browser. This applies to any app that captures camera / microphone, not just the ones listed. Ask the user to close the other app and reload.
Built-in hardware disabled in BIOS, broken USB cable, or a webcam that lost power. Confirm the device shows up in another app (the OS camera app, for example).

​
Joined but no audio / video from the other side

Obvious but the single most common cause. Check the participant list — the tile shows mic / cam state.
Browsers require a user gesture to play audio in some configurations. If the user navigated to the meeting URL without tapping a button first, autoplay may be suppressed — tapping anywhere in the meeting unblocks it.
Ask the user to open meeting settings and verify the speaker / output device. Bluetooth headsets can appear and disappear without notice.
Strict firewalls can block UDP so WebRTC falls back to TCP or TLS. The call still connects but audio can degrade. See Network requirements.

​
Call connects but audio or video is poor

The most common cause of bad meetings. Ask the user to move closer to the access point, switch to 5 GHz, or — if on a busy office Wi-Fi — try tethering off a phone as an A/B test.
Many corporate VPNs force traffic over TCP which degrades WebRTC. Disconnecting the VPN (when policy allows) is a useful A/B test.
BT headsets introduce latency and artefacts that sound like bad network. Retry on wired earbuds or the laptop’s built-in hardware to isolate.
A surprising share of “bad call” reports trace back to cheap USB headsets with variable mic gain. Standardise on tested hardware for agents.

​
Call drops mid-meeting

WebRTC sessions don’t survive IP changes. This is a protocol limitation — the meeting will reconnect or drop. Ask mobile users to stay on one network for the duration of the call.
Sustained high loss causes the session to tear down. The root cause is network, not the meeting runtime. See Network requirements.
Desktops sleeping typically kill the connection. Mobile devices locking the screen usually keep the call alive for a short period.
Aggressive tab suspension on low-memory devices can kill the media pipeline. Keep the meeting tab in the foreground.

​
Guest can’t join — “waiting for host”

The preset may enforce a wait-for-host rule. The guest stays in the preview until the host arrives, at which point they’re admitted. Ask the agent to join first.
Some presets are configured with “deny guest if no host”. In that case the guest is bounced out instead of waiting. Check the preset used for the link.
Presets can cap how many times the guest retries before giving up. Increase the cap in the preset or pair the link with a scheduled slot so the host is present on time.

​
Recording doesn’t start

Auto-record is driven by the preset’s Record on start flag. See Recording.
The host preset has to expose the recording control for manual start / stop mid-meeting. Check the preset’s control list.
If the meeting is short and the host never taps Start, no recording exists. Consider enabling Record on start for flows where recording is mandatory.

​
Virtual background doesn’t work

Background segmentation runs locally and needs a modern GPU or a fast CPU. On low-end devices the background is disabled or becomes laggy. Ask the user to try without the virtual background.
The list of backgrounds is driven by the preset. If nothing is configured, the user sees only the built-in blur option.
Virtual backgrounds rely on features only present in current browsers. An out-of-date browser falls back to no background.
The corporate user may be on a network that blocks TURN. See Network requirements.
Permissions are per-browser per-origin. The user who previously denied needs to reset the permission.
Host vs guest presets differ. If the link is a host link and the user isn’t authorised, the meeting refuses to admit them. Check which role the link was generated for.

​
Embedding in an iframe doesn’t work

The <iframe> must declare allow="camera; microphone; autoplay; display-capture". See Permissions — Embedding.
A parent page with frame-src or frame-ancestors rules can prevent the meeting iframe from rendering. Review the parent page’s Content Security Policy.
When the meeting iframe is itself nested inside another iframe (e.g. inside a CMS that embeds a page that embeds the meeting), every layer has to delegate camera and microphone permissions.

​
Advanced diagnostics

This section is for technical teams — your IT, the developer who embedded the meeting, or your support engineer working with ours. End customers will not need any of this to make a call.
When the symptom-based entries above don’t land, the browser itself exposes everything needed to diagnose a bad meeting. Four tools cover almost every case.

​
1. Browser console (F12 → Console)

Open DevTools on the page that shows the problem and look for errors thrown around the moment the meeting misbehaves. Common names to search for:
ErrorWhat it means
NotAllowedErrorCamera or microphone permission was denied — in the browser, the OS, or an iframe that didn’t declare allow.
NotFoundErrorThe browser doesn’t see any camera / microphone. Device unplugged, disabled in BIOS, or OS is hiding it.
NotReadableErrorAnother app is holding the device. Close the other app (see “Camera or microphone won’t start” above).
OverconstrainedErrorThe requested resolution or device id isn’t available on this machine.
Refused to frame …Parent site’s Content Security Policy is blocking the iframe.
Permissions Policy violationThe outer page didn’t delegate camera / microphone to the meeting iframe.
WebSocket connection … failedSignalling can’t reach us — usually firewall, VPN, or a proxy breaking WebSockets.

​
2. Network tab (F12 → Network)

Filter by WS (WebSocket) and Fetch/XHR. Things to look at:
  • The HTTP request that loads the meeting — status should be 200. A 401 / 403 means the meeting id or auth is wrong, a 404 means the meeting doesn’t exist or was cancelled.
  • The WebSocket connection — should move to 101 Switching Protocols and stay open. A pending or immediately-closed socket is usually firewall / proxy interference.
  • Blocked requests (highlighted red with blocked: in the status). Ad blockers, privacy extensions, and corporate proxies sometimes block third-party origins.

​
3. Real-time stats

Chrome and Edge ship a built-in page that shows the live media stats for every active call on the tab: 
chrome://webrtc-internals
Open it in a second tab before the user reproduces the problem, then read the active session. The most useful fields:
FieldWhat it tells you
iceConnectionStateIf it never leaves checking, the browser can’t reach our media servers. failed / disconnected during a call = network interruption.
packetsLost / packetsReceivedRising packetsLost with a low receive rate → packet loss. This is a network problem, not the app.
jitterConsistently high → unstable latency on the path (congested Wi-Fi, overloaded cellular).
framesReceived / framesDecoded at 0You aren’t getting video from the other side. Check whether the other participant’s camera is actually on.
bytesReceived at 0 for audioNothing is reaching the browser at all — firewall or no media path.
There’s a Download PC stats button at the top of the page — capturing that during the bad call is the single most useful thing for support. Firefox has the equivalent page at: 
about:webrtc
Safari doesn’t expose a built-in diagnostics URL, but its Web Inspector (enabled from the Develop menu) shows the same console and network information as Chrome.

​
4. What to capture before escalating

When opening a support ticket for a call that failed, attaching the following dramatically shortens resolution time:
  • App ID and Meeting ID / call ID
  • Timestamp of the problem (with timezone)
  • Browser name and version, OS and version
  • Network type — home Wi-Fi, mobile, office, VPN
  • Screenshot of the browser console (errors, not just the messages area)
  • Network tab export (.har file) — right-click in the Network tab → Save all as HAR
  • chrome://webrtc-internals dump — the Download PC stats button — captured while the call was active, not after it ended
  • Steps to reproduce

​
Getting support

If none of the above matches, open a support ticket. Include the items from What to capture before escalating above.

​
What’s next

Network requirements

Ports, firewalls, bandwidth.

Browser & device support

Supported combinations.

Permissions

Camera and microphone access.