Browser calling audio troubleshooting: fix no audio and one-way calls
Published
Ryan Erkal
Founder, Redialler
Browser calling audio troubleshooting is fastest when you first classify the symptom. A microphone problem means the browser is not sending usable input. An output problem means the rep cannot hear the remote stream. A network problem causes breakup, delay, or both directions to fail. A remote-party or provider problem can leave the local meter moving while the prospect hears nothing. Work through permissions, devices, browser support, network evidence, and a controlled retest without disabling security controls or guessing from one bad call.
Classify the microphone, output, connection or remote-party symptom
Start with four observations. If the microphone meter does not move, investigate permission, the selected input, operating-system privacy settings, mute state, or hardware. If the meter moves but the prospect cannot hear the rep, check the selected input and call mute first, then investigate the upstream media path. If the prospect hears the rep but the rep hears nothing, check the selected output, the browser audio element, device volume, and whether another application owns the headset.
If both parties hear breakup or delay, treat the connection as the leading suspect. WebRTC sends browser media through signalling and media connections, so a call can connect while its audio quality degrades. If only one prospect reports a problem while the same rep and headset work on a controlled call, record that difference before changing the local setup. A single symptom does not identify the fault owner.
Write down direction and timing. No audio from the start differs from audio that fails after a network change. A local meter proves local input activity only. It does not prove that the remote party received the stream, and a connected call status does not prove that both humans could hear each other.
Check site permissions and selected input and output devices
Use the browser's site controls to confirm microphone access for the exact calling origin. Check the operating system's microphone privacy permission as well. A permission prompt can be accepted for one site and denied for another. Refreshing the page after a permission change can clear a stale device state, but do not start a live call until the preflight or device test succeeds.
Select the intended input and output explicitly when the browser and calling app support it. Browsers can omit devices or show generic labels until microphone permission is granted, and output selection depends on browser support for the setSinkId audio API. A headset can be connected while the browser still uses the laptop microphone or speakers.
Run a local test with the headset disconnected, then reconnect it and select it again. Check the browser tab and system volume. Stop meeting, screen-recording, music, and softphone applications that may hold the same device. If the issue appears only after a device change, save the old and new device names and reproduce once before escalating.
Test Bluetooth profiles, headset contention and one controlled device
Change one variable at a time. First repeat the call with the current headset after closing other audio applications. Then try a known-good USB or wired headset. If the wired test works, record the Bluetooth headset model, operating-system audio mode, selected input, selected output, and whether the problem returns when Bluetooth is restored. This gives support a reproducible device boundary instead of a vague report that the browser is broken.
Keep the test controlled. Use an approved destination or internal test number, a short call, and no sensitive conversation. Confirm microphone input with the local meter, confirm output with a safe test sound, then confirm both directions on the call. Do not record or share customer audio merely to diagnose a headset. Follow the team's recording notice and retention policy if a test call is recorded.
A device change can refresh the browser's available-device list. Browsers fire a devicechange event when hardware is added or removed, so the calling app can notice the change and reselect the input. Those controls help isolate hardware and browser state, but they cannot prove the carrier path or the far-end handset.
Inspect browser support, network quality and firewall requirements
Use a current browser supported by the calling application and test in a clean profile when extensions may interfere. Browser audio features are not uniform. Output device selection is browser-dependent, so if a device selector is unsupported, test the system default and record that limitation rather than assuming the selector is working.
Redialler runs browser calls over WebRTC. The network must allow outbound TCP 443 for signalling and outbound UDP for media, and media traffic should bypass TLS inspection. Redialler support can share the current media ranges for your allowlist. For clear audio, plan for about 40 kilobits per second in each direction, round-trip latency below 200 milliseconds, jitter below 30 milliseconds and packet loss below 3 percent. Use your organization's approved allowlist and IT change process for those requirements.
Do not advise blanket antivirus or firewall disabling. Ask IT to review the specific blocked destination, protocol, port, proxy, VPN, quality-of-service rule, or browser policy. If UDP is restricted, WebRTC can relay media through a TURN server over TCP or TLS, which adds delay and still needs the organization's security review.
Collect call IDs and quality evidence without recording secrets
Capture the call ID, UTC start and end time, direction, browser version, operating system, headset, selected input and output, network type, VPN state, and the exact symptom. Add whether the local meter moved, whether the other party heard anything, and whether a second device changed the result. Never paste access tokens, authentication headers, private recording URLs, or customer details into a public issue.
The browser's WebRTC statistics report quality indicators such as round-trip time, jitter and packet loss, and the browser console shows client errors. Give support the smallest approved evidence bundle and keep any recording behind its normal access controls.
For a CRM issue after the call, keep the audio diagnosis separate from the write-back diagnosis. A clean call can still have a delayed or failed CRM activity. Use the Call activity not syncing to your CRM guide when the audio is usable but the record, note, or attachment is missing.
Escalate reproducible symptoms and retest one change at a time
Use this decision tree. If the mic meter moves but the prospect cannot hear, verify mute, selected input, local permission, a second headset, and the approved network path. If the prospect hears the rep but the rep hears nothing, verify output selection, tab and system volume, headset contention, and the remote audio element. If both parties hear breakup, capture packet loss, jitter, latency, VPN and network details, then test one approved network or device change.
After each change, repeat the same short test and record pass or fail. Revert a change that does not help. If the symptom follows the user across two approved devices and networks, escalate with the same call evidence. If it follows one browser profile, headset, VPN or office network, route the case to that owner. If it occurs only with one destination, preserve the destination and provider evidence for the calling owner.
Redialler performs browser audio preflight before its documented manual, Power and Parallel workflow can start. A successful local test is useful evidence, but it does not replace a controlled call through the provider path. Confirm both directions in a controlled call, and discuss your calling workflow if you need help reviewing the setup.
Explore Redialler
Sources and review
Reviewed 2026-10-10. Product details and provider policies can change.
- MediaDevices: getUserMedia() method (checked 2026-10-10)
- MediaDevices: enumerateDevices() method (checked 2026-10-10)
- HTMLMediaElement: setSinkId() method (checked 2026-10-10)
- MediaDevices: devicechange event (checked 2026-10-10)
- WebRTC connectivity (checked 2026-10-10)
- Identifiers for WebRTC's Statistics API (checked 2026-10-10)