Call Quality Troubleshooting Guide

Common Issues and Fixes

The table below covers the six most frequent call quality problems. Start here before diving into the detailed sections.

Issue	Likely Cause	Fix
Echo	Speaker audio feeding back into the microphone. Usually happens when using laptop speakers instead of a headset.	Use headphones or a headset. If that is not possible, lower the speaker volume. Chrome's echo cancellation handles most cases, but open speakers at high volume overwhelm it.
One-way audio	The microphone is blocked by the browser, or a firewall is dropping UDP packets in one direction.	Check browser microphone permissions (see below). If permissions are correct, the issue is likely network-related -- verify that your firewall allows UDP traffic on ports 10000-20000 and that TURN is enabled in your account settings.
Choppy / robotic audio	Packet loss or high jitter on the network. Common on congested Wi-Fi or when bandwidth is shared with large downloads or video streams.	Switch to a wired Ethernet connection if possible. Close bandwidth-heavy applications (video calls, large uploads). If on Wi-Fi, move closer to the router. If the problem persists, run a network test (see below).
Call drops after 30-60 seconds	NAT timeout or firewall closing the UDP session. Some corporate firewalls aggressively close idle UDP connections.	Enable TURN relay in your WebCallHub settings (Settings → Network → Force TURN). This routes audio through a relay server using TCP, which firewalls are less likely to block. If the problem is only on one network, check with your IT team about UDP timeout settings.
High latency / delay	Audio is being relayed through a TURN server far from either party, or the network path has high round-trip time.	Check if TURN relay is being forced unnecessarily (Settings → Network). If direct peer-to-peer or STUN connections work on your network, disable forced TURN. For geographically distant calls, some latency is unavoidable.
No audio at all	Microphone permission denied, wrong audio device selected, or the browser tab is muted.	Follow the browser permissions checklist below. Check that the correct microphone is selected in your browser's site settings. Right-click the browser tab and make sure it is not muted.

When to escalate

Contact support if:

• You have tried the fixes above and the problem persists across multiple calls.
• The issue affects all agents, not just one person.
• You see error codes in the call interface (e.g., ICE_FAILED, SIP_ERROR). Include the error code in your support email.

Browser Microphone Permissions

WebCallHub uses your browser's built-in microphone access. If the microphone is blocked, you will hear nothing and the other party will not hear you. Here is how to check and fix permissions on each browser.

Google Chrome

1. Click the lock icon (or tune icon) in the address bar, to the left of the URL.
2. Find Microphone in the permissions list.
3. Set it to Allow.
4. Reload the page.

If you previously clicked "Block" on the microphone prompt, Chrome remembers that choice. You must manually change it using the steps above -- the prompt will not appear again on its own.

Firefox

1. Click the lock icon in the address bar.
2. Click Connection secure → More Information → Permissions.
3. Find Use the Microphone and set it to Allow.
4. Reload the page.

Safari

1. Go to Safari → Settings → Websites → Microphone.
2. Find the WebCallHub site in the list and set it to Allow.
3. Reload the page.

Edge

Edge uses the same Chromium permissions model as Chrome. Click the lock icon in the address bar, set Microphone to Allow, and reload.

Network Requirements

WebCallHub uses WebRTC for browser-to-browser audio. Here is what your network needs to support:

Requirement	Details
Bandwidth	Minimum 100 kbps up and down per call. Recommended: 500 kbps or higher for consistent quality.
UDP ports	Ports 10000-20000 must be open for outbound UDP. This is the range used by the TURN/STUN servers and direct WebRTC media.
TURN fallback (TCP)	If UDP is blocked, WebCallHub falls back to TURN over TCP on port 443. This adds latency but works through most firewalls.
STUN server	The browser needs to reach the STUN server to discover its public IP. This is a lightweight UDP request on port 3478.
WebSocket	A persistent WebSocket connection to app.webcallhub.com on port 443 (WSS) is required for SIP signaling.

Corporate networks with deep packet inspection (DPI) or strict proxy servers sometimes interfere with WebRTC. If you are on a corporate network and calls fail, ask your IT team to whitelist *.webcallhub.com and allow WebRTC traffic.

Testing Tools

Use these to diagnose problems before contacting support:

Browser WebRTC diagnostics

• Chrome: Open chrome://webrtc-internals in a new tab during a call. This shows ICE candidate gathering, codec negotiation, and packet loss stats in real time.
• Firefox: Open about:webrtc during a call for similar diagnostics.

Network speed test

Run a speed test at speed.cloudflare.com. Pay attention to latency (under 100ms is good), jitter (under 30ms is good), and packet loss (should be 0%). High jitter or packet loss directly causes choppy audio.

Microphone test

If you are unsure whether your microphone is working at all, open your operating system's sound settings and check the input level meter while speaking. On macOS: System Settings → Sound → Input. On Windows: Settings → System → Sound → Input.

Collecting Information for Support

If you need to contact support, include the following:

1. Your browser and version (e.g., Chrome 126 on macOS 15).
2. The time and date of the affected call.
3. Which side had the issue (agent, visitor, or both).
4. A screenshot of chrome://webrtc-internals if possible.
5. Your network type (home Wi-Fi, office Ethernet, corporate VPN, mobile).

Send this to [email protected] and we will investigate within one business day.