The Four Audio Problems and What Causes Them

Most VoIP quality complaints fall into four categories. Each has a distinct root cause and a different diagnostic path.

  1. Choppy / cutting out audio — caused by packet loss or jitter
  2. One-way audio — caused by NAT/firewall issues or codec mismatch
  3. Echo — caused by acoustic feedback or improper sidetone handling
  4. Robotic / distorted voice — caused by CPU overload, severe packet loss, or codec problems

Problem 1: Choppy Audio

What you hear

Your voice (or the other person's) cuts in and out rhythmically, drops words, or sounds like a scratched record.

Root causes

Packet loss is the primary culprit. VoIP packets travel over UDP — there is no retransmission mechanism, so lost packets result in gaps in the audio stream. The jitter buffer can conceal brief losses, but sustained loss above 5–8% becomes audible.

Jitter is the second cause. Even if no packets are dropped, packets that arrive out of order or with highly variable timing create choppy audio because the jitter buffer either runs dry (causing silence gaps) or overflows (causing it to drop packets to catch up).

How to diagnose

Run a network quality test from your browser's developer tools or from a site like fast.com with the "more info" panel open. Look for:

  • Packet loss: Anything above 1% warrants investigation
  • Latency jitter (variation): Should be under 30 ms for comfortable calls

How to fix

  1. Switch from Wi-Fi to wired ethernet. This is the single most effective fix. Wi-Fi, especially on congested 2.4 GHz networks, has highly variable latency and packet loss.
  2. Check for bandwidth saturation. Someone downloading a large file or streaming 4K video on the same network can cause call packet loss. QoS settings on your router can prioritise VoIP traffic.
  3. Close other browser tabs. Heavy JavaScript applications can cause audio processing to stutter on underpowered machines.
  4. Check your ISP connection. Run a ping test to a nearby server (e.g., `ping 8.8.8.8`) and look for packet loss or spikes above 100 ms.

Problem 2: One-Way Audio

What you hear

You can hear the other person but they cannot hear you — or vice versa.

Root causes

One-way audio is almost always a NAT traversal or firewall problem. WebRTC uses ICE to punch through NAT, but some corporate firewalls block the UDP ports used for ICE, or have stateful firewall rules that allow outbound traffic but block the return path.

Less commonly, it is caused by a microphone permission issue where the browser was denied access to the audio input.

How to diagnose

  1. Check the browser's site permissions (the lock icon in the address bar). Confirm microphone access is allowed for the Voxa domain.
  2. Open the browser's developer console (F12) and look for WebRTC ICE-related errors during call setup.
  3. Try from a different network (e.g., mobile hotspot). If one-way audio resolves on a different network, the problem is your network's firewall configuration.

How to fix

  1. Allow UDP egress on ports 3478 (STUN) and ephemeral ports (typically 1024–65535) from your network to Voxa's infrastructure.
  2. If UDP is fully blocked, WebRTC will fall back to TURN relay over TCP port 443 — ensure this port is not blocked.
  3. In corporate environments, work with your network team to whitelist Voxa's STUN/TURN server IP ranges.

Problem 3: Echo

What you hear

You hear your own voice echoed back with a short delay, or the other person complains they hear themselves echoed.

Root causes

Acoustic echo occurs when the speaker output is picked up by the microphone and sent back to the far end. This happens with:

  • Laptop or desktop built-in speakers (microphone is near the speaker)
  • High speaker volume
  • Speakerphone use without proper AEC

WebRTC includes Acoustic Echo Cancellation (AEC) that handles this in most cases, but it can be overwhelmed by very loud speakers or unusual acoustic environments.

Sidetone echo is less common and is caused by AEC miscalibration — the browser's AEC filter has a reference signal mismatch and fails to cancel the echo path correctly.

How to fix

  1. Use a headset. This is the definitive fix. Headphones physically separate the speaker output from the microphone pickup, eliminating the acoustic feedback path entirely.
  2. Reduce speaker volume. Lower output gives AEC less signal to cancel.
  3. Ensure only one browser tab or audio application is active. Multiple applications capturing audio simultaneously can confuse the AEC reference signal.
  4. If you are in a room with a lot of hard surfaces (glass, concrete), soft furnishings significantly improve acoustic conditions.

Problem 4: Robotic or Distorted Voice

What you hear

Speech sounds compressed, garbled, digitised, or like a broken radio. Words are recognisable but the voice quality is severely degraded.

Root causes

Severe packet loss (above 15–20%): The Opus codec's error concealment breaks down at very high loss rates. The FEC and PLC algorithms can only fill so many gaps before the audio becomes unintelligible.

CPU throttling: On older machines, if the browser's audio processing thread is CPU-starved, the encoder may drop frames or produce malformed packets. This is most common on machines with many active browser tabs or background processes.

Codec negotiation failure: In rare cases, a codec negotiation issue results in audio being decoded at the wrong sample rate or bit depth, producing the characteristic robotic distortion.

How to diagnose

  • Open Chrome's built-in WebRTC diagnostic page at `chrome://webrtc-internals` during a call. Look at the `packetsLost` counter on the inbound RTP stream — it should be near zero for good calls.
  • Check CPU usage during a call. If the audio thread is showing high CPU on the WebRTC internals page, the issue is processing capacity.

How to fix

  1. Close unnecessary browser tabs and applications consuming CPU.
  2. Ensure your browser is up to date. Browser vendors regularly improve WebRTC performance and codec handling.
  3. Try a different browser. Chrome generally has the most optimised WebRTC implementation, but Firefox and Edge are both solid alternatives.
  4. Address any underlying network issues (see Problem 1 above).

Quick Diagnostic Checklist

Before calling support, run through this checklist:

  • [ ] Wired ethernet connection, not Wi-Fi
  • [ ] Microphone permission granted in browser
  • [ ] No other applications using the microphone
  • [ ] Browser is up to date
  • [ ] No active large downloads or uploads on the network
  • [ ] Headset in use (not built-in speakers)
  • [ ] CPU usage is not consistently above 80%

Resolving the issues on this list will fix the vast majority of VoIP audio quality problems without any server-side changes. If problems persist after working through this list, contact support with your browser type and version, the approximate time of the affected calls, and the destination number — that information lets us pull the specific call records and diagnose from the server side.