Practical Guide for Call Center Agents

By Olivier Anguenot

Published in others

March 27, 2026

Computer and OS

Browsers

Headsets, Microphones, and Speakers

Network considerations

Troubleshooting Guide

Helping the Support team

Wrapping Up

Call center agents spend their entire day on voice calls.A surprising number of them start their shift without a properly configured workstation. A wrong audio device selected in the browser, an outdated OS, a Wi-Fi connection shared with a cloud backup running in the background: any of these can turn a simple customer call into a frustrating experience for both sides.

WebRTC is the dominant technology behind browser-based softphones, and it works remarkably well when the environment is set up correctly. But WebRTC is sensitive to its surroundings: the headset, the browser version, the network quality, and even the power settings of the laptop all have a direct impact on call quality.

Support teams regularly handle tickets that could have been avoided or at least diagnosed faster if agents had a clear reference for what a correct setup looks like and what to check first when something goes wrong.

This guide is that reference. It covers workstation configuration (OS, hardware, headset, browser, network) and provides a troubleshooting guide for the most common issues agents encounter. The goal is to help agents self-diagnose and resolve problems quickly, and to give support teams a shared baseline when escalation is needed.

One important scope note: this guide focuses exclusively on the agent’s side. It does not cover issues at the platform or solution level (server infrastructure, signaling, media routing), nor problems originating from the caller’s side where a bad network connection is, by far, the most common culprit. If the agent’s setup checks out but call quality remains consistently poor, the problem likely lies elsewhere.

Computer and OS

Supported Systems and Updates

Status	Operating Systems
Recommended	Windows 11, macOS 26.x (Tahoe)
Possible	macOS Sonoma 14.x, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS
Not recommended	Windows 10, macOS Ventura 13.x

In details:

The currently supported operating systems for WebRTC are Windows 11 and macOS 26.x (Tahoe); these versions provide the best compatibility with modern browsers and the latest audio/network stacks.
On Linux, the main supported distributions are Ubuntu 22.04 LTS and Ubuntu 24.04 LTS (or equivalent Debian-based distributions.
Older macOS versions (Sonoma 14.x) are still supported correctly, provided the browser is kept up to date; functionality may be limited on hardware that no longer receives macOS updates.
Windows 10 must not be used: Microsoft ended mainstream support for Windows 10 in October 2025, meaning no further security or audio/network patches are issued; agents on Windows 10 should be migrated to Windows 11 as soon as possible. Even if still supported macOs Ventura 13.x should be used with care.

Note — System Updates: Apply system updates promptly when asked, regardless of the OS. On Windows, also apply BIOS and motherboard firmware updates when available.

CPU, Memory, and Disk Space

Component	Requirement
CPU	Modern multi-core processor (no specific minimum)
Memory	8 GB RAM minimum
Disk	No specific requirement

In details:

RAM: A minimum of 8 GB is required to comfortably run the browser alongside typical agent applications (CRM, back-office tools). WebRTC itself has no special memory demands — the overhead comes from the surrounding applications running in parallel.
CPU: Any modern multi-core processor sufficient for everyday back-office and browser use is adequate for WebRTC audio calls. An audio calls increases the CPU load by 5% to 10% depending on the PC.
Disk: WebRTC has no specific disk space requirement. Standard workstation provisioning is sufficient.

Note: Using the video or the screen sharing may impact the CPU load by more than 50%. If the agent uses background blur or virtual backgrounds, a dedicated GPU is strongly recommended, as this feature is GPU-accelerated and will otherwise heavily load the CPU.

Headsets, Microphones, and Speakers

Device Type	Audio Quality	Connectivity
Integrated / Built-in	Variable	Simple
USB	High	Reliable
Bluetooth	Variable	Complex

In details:

Integrated / Built-in devices: Built-in microphones and speakers offer simplicity. They are managed directly by the OS and updated through standard system updates, requiring no additional drivers. They are functional for WebRTC calls, but audio quality is directly tied to the overall quality of the computer hardware, which is generally lower than that of dedicated peripherals. They are acceptable as a fallback but less recommended. From a privacy and environment standpoint, built-in microphones are omnidirectional and pick up significantly more ambient sound than a headset boom mic — nearby conversations, room noise, and keyboard clicks are all captured and transmitted to the customer. Using an external headset with a directional microphone is strongly preferred, both for confidentiality and to limit sound pollution toward the interlocutor.
USB headsets: USB devices provide secure, reliable connectivity with consistently high audio quality. They are recognized as dedicated sound cards by the OS, with audio processing optimized for voice. However, it is important to keep USB device drivers up to date, as outdated drivers can cause recognition failures or audio degradation.
Bluetooth devices: Bluetooth headsets offer freedom of movement but introduce additional complexity: they are more susceptible to interference, latency can vary depending on the profile in use (A2DP for quality audio vs. HFP/HSP for call control), and pairing stability depends heavily on the adapter. The use of a dedicated USB Bluetooth dongle provided by the headset manufacturer is strongly recommended over the PC’s native Bluetooth, as it provides a more stable and optimized connection. Battery life must be actively monitored: a low battery is a frequent cause of degraded audio quality (robotic or choppy sound) and unexpected disconnections mid-call. Agents should charge their headset at the end of each shift and check the battery level before starting a production session.

Note — Apple Continuity (macOS/iOS): On Apple devices, the Continuity feature may automatically switch the active microphone or audio output to a nearby iPhone or AirPods without explicit user action. This can unexpectedly change the audio device during a WebRTC call. Agents using macOS should verify that the correct audio device remains selected in both the system and the WebRTC application, and disable Continuity handoff if it causes disruptions.

Support of Tablets and Phones

Tablets and smartphones are not recommended as primary agent devices for WebRTC calls. While technically capable of running WebRTC in a browser, they present significant practical limitations in a call center context:

Battery drain: Long call sessions consume battery rapidly, especially when the screen must remain active to keep the WebRTC session alive. This creates a dependency on continuous charging, which is not a sustainable setup for a full production day.
iPad / iOS tablets: Even on iPad, which offers the most consistent WebRTC support among tablets, the experience remains suboptimal compared to a desktop — screen management, peripheral configuration, and background session handling are all more constrained than on macOS or Windows.
Android tablets: The situation is significantly worse on Android tablets due to the extreme fragmentation of the ecosystem. Hundreds of hardware vendors ship devices running custom Android versions that are rarely kept up to date. Audio stack behavior, microphone access policies, and WebRTC compatibility vary widely across models and OS versions, making it very difficult to guarantee a consistent and reliable call experience.

In all cases, a PC or Mac workstation remains the recommended platform for agent use.

Laptop-Specific Settings

WebRTC calls consume more battery than typical office tasks. The recommended approach is to keep the laptop plugged into AC power during production hours whenever possible. This ensures the CPU, Wi-Fi adapter, and USB ports operate at full capacity without any power-saving restrictions.

If the laptop cannot be plugged in, battery optimization features must be disabled to prevent performance throttling:

Windows: Set the power plan to Balanced or Best performance (Settings → System → Power & battery → Power mode). Avoid “Battery saver” mode, which throttles the CPU and reduces Wi-Fi transmission power, both of which directly degrade call quality. Also disable automatic USB port suspension in the advanced power options to prevent headset disconnections.
macOS: Disable Low Power Mode (System Settings → Battery → uncheck Low Power Mode). When enabled, this mode reduces CPU performance and can cause audio processing delays and dropouts during WebRTC calls.

Note — Battery alerts: Pay attention to low battery notifications during a call. A battery level falling below 20% may trigger automatic power-saving behaviors even if they were manually disabled. If a notification appears, plug in the charger as soon as possible.

Browsers

Recommended Browsers

Status	Browsers
First class	Chrome, Edge (Chromium)
Supported	Safari (macOS/iOS), Firefox, Brave, Opera
Not recommended	All others

Note — Safari and Firefox: Both browsers can be used without any risks as Chrome, but some WebRTC features or application-specific functionality may not be available, especially on Firefox. In case of an issue that cannot be reproduced or explained, a good diagnostic practice — when possible — is to reproduce it on Chrome and compare the behavior. Chrome is the reference implementation for WebRTC and the most reliable baseline.

Browser Updates

Browsers must be updated regularly. Unlike OS updates, browser updates are not always automatic — if the computer is left running continuously without being restarted, the update will have been downloaded but not yet applied. In that case, the browser must be fully quit and relaunched to complete the update.

New versions are typically released every 4 to 6 weeks. The recommended practice is to stay on the latest available stable version at all times.
No version older than the equivalent of a Long Term Support (LTS) release should be used in production. Outdated browsers may lack critical WebRTC fixes and security patches.
Beta, Dev, or Canary channel versions should not be used by agents. These early-access versions may introduce regressions and unstable behavior that has not yet been validated.

Incognito / Private Mode

Using incognito or private browsing mode is not a good practice for WebRTC applications. In this mode, browser permissions (including microphone and camera access) are not persisted between sessions, which means the agent will be prompted to re-authorize devices on every session. Some extensions and application features may also be blocked or unavailable in incognito mode.

Device Authorization

Always verify, when the web application is opened, that the browser has permission to use the microphone. The padlock (or settings) icon in the address bar should show microphone access as Allowed for the site. If the permission was previously denied, it must be reset manually in the browser settings before calls can work correctly.

Browser Extensions

Limit the number of browser extensions installed on agent workstations. Aggressive ad blockers, screen recorders, and audio processing tools can interfere with microphone access, inject code into web pages, or disrupt WebRTC media streams. When an unexplained audio or connectivity issue occurs, disabling all extensions temporarily is a useful first diagnostic step.

Tab Discipline: One Instance, Few Tabs

Make sure the application is never open in more than one tab simultaneously. Having two instances of the same softphone open in parallel causes conflicts over microphone access, audio routing, and session state — leading to calls that connect on the wrong tab, missing audio, or silent microphone.

More generally, avoid accumulating unnecessary open tabs during a session. Each browser tab consumes memory independently of whether it is active or not. A large number of open tabs can exhaust available RAM, forcing the OS to swap memory to disk and significantly reducing the performance available for the call. If memory pressure is high, the browser may also deprioritize or throttle inactive tabs, other than the tab where the call occurs.

Headsets, Microphones, and Speakers

General Principle

A headset with a dedicated microphone is recommended in a call center: it isolates the outgoing sound from the microphone and prevents the echo caused by PC speakers. Professional headsets (Jabra, Poly/Plantronics, Logitech, etc.) are designed for extended use and often include noise reduction for both the agent and the customer.

For agents working from home, a headset is also an excellent way to stay acoustically isolated from the surrounding environment — family noise, pets, household sounds — and to prevent those from being transmitted to the customer.

Wired Headsets (USB, Jack)

Wired is the preferred connection mode: it provides the most reliable and consistent audio quality, with no battery dependency, no profile switching, and minimal latency.

USB and jack headsets are recognized immediately by the OS and do not require complex configuration.
Connect directly to the computer whenever possible, without intermediate hubs or adapters, to avoid power and signal degradation.
When a direct connection is not available (e.g., on a MacBook Pro with only USB-C ports), use a quality USB-C adapter or a certified USB hub. Note that on MacBook Pro, native USB-A ports are absent, so an adapter is required for most standard USB headsets — this is expected and works correctly with certified accessories.

USB Docks and Conference Speakers

USB docks (speakerphones / conference devices such as Jabra Speak, Poly Sync, Logi Dock, etc.) combine an embedded microphone array and external speakers in a single unit. They are a valid option for room-based or home office setups where mobility is not required and the environment is reasonably quiet.

Depending on the quality of the device, they can deliver good audio for WebRTC calls. However, compared to a headset, they are more likely to pick up background voices, ambient noise, and room reverberation, as their microphones are designed to capture a wide area rather than a single speaker. In noisy environments — open-plan offices, shared spaces — a headset remains preferable.

Bluetooth Headsets and Dongles

Bluetooth headsets are a valid and comfortable choice when used correctly. They offer freedom of movement and, with a quality device and proper configuration, can deliver reliable audio for WebRTC calls.

Bluetooth is more susceptible to interference, battery issues, and audio profile switching (A2DP ↔ HFP/HSP) which can sometimes degrade quality.
USB Bluetooth dongles provided by the headset manufacturer often create a more stable audio link than the PC’s native Bluetooth, with a voice-optimized profile and call control commands. Using the dedicated dongle is strongly recommended. When using a dongle, disable or unpair the headset from the PC’s native Bluetooth — having both connections active simultaneously can cause audio routing conflicts, duplicate device entries, and unpredictable behavior.
Do not use the same Bluetooth headset simultaneously with multiple real-time audio applications (e.g., Teams + a WebRTC softphone) to avoid control conflicts.
Battery life must be monitored: low battery is a common cause of robotic sound and mid-call disconnections. Charge the headset at the end of each shift and check the level before starting a session.

Built-in Laptop Speakers and Microphone

Using the laptop’s built-in speakers is generally not recommended for call center use, but may be acceptable depending on the environment. In a quiet, isolated setting (private office, dedicated home workspace), built-in speakers can work adequately, but only when used together with the built-in microphone. WebRTC echo cancellation relies on knowing exactly what is being played through the speakers; using an external or headset microphone in combination with built-in speakers breaks this pairing and prevents the echo canceller from working correctly. They cannot match the audio quality or isolation of a dedicated device, and they carry a real risk of acoustic echo — the customer’s voice plays through the speakers, is captured by the microphone, and fed back into the call. Even with WebRTC echo cancellation, the result is imperfect, especially in reverberant rooms.

When using built-in speakers and microphone together, echo risk is at its highest. Always prefer a headset when in doubt or test it before in a real condition.

Avoid “Youtuber” or Streamer Setups

It may be tempting to build a high-quality audio setup inspired by content creators or streamers, but this type of configuration is generally not adapted to call center use and introduces unnecessary complexity.

Mixed devices: Streamers typically use a dedicated headset for listening and a separate external microphone for capture. Mixing two distinct audio devices without careful configuration creates a split audio chain that WebRTC’s echo canceller was not designed for — the output device and input device no longer form a matched pair, which significantly increases the risk of echo and cancellation failures.
XLR microphones and audio interfaces: High-end condenser or dynamic microphones with XLR connectors are popular for voice recording because of their exceptional capture quality. However, they require an external audio interface to convert the analog XLR signal to USB, and often need a preamp, phantom power, and careful gain staging. This hardware chain adds complexity, additional failure points, and configuration overhead that is disproportionate for a call center context.
Additional peripherals: Streamers also commonly use key lights, ring lights, and video capture cards, all of which consume USB bandwidth and can create resource contention or driver conflicts with the audio chain.

A single quality headset — wired USB or Bluetooth with a dedicated dongle — remains the simplest, most reliable, and most support-friendly setup for an agent.

Advanced Audio Features on Modern Headsets

High-end professional headsets now embed a range of audio processing features that can significantly improve call quality when properly understood and configured.

Active Noise Cancellation (ANC): Uses microphones on the outside of the ear cups to sample ambient sound and generate an opposing signal, canceling environmental noise in the listener’s ear. ANC improves agent comfort in noisy environments and reduces fatigue during long call sessions. It acts on the listening side and does not affect what the customer hears.
Microphone Noise Cancellation / Background Noise Suppression: Filters out ambient sounds (keyboard, HVAC, open-space conversations) from the agent’s outgoing audio before it reaches the customer. High-end models use beamforming microphone arrays and AI-based processing. This is distinct from ANC — it acts on the sending side.
Acoustic Echo Cancellation (AEC): Some headsets apply echo cancellation at the hardware level, in addition to (or instead of) the browser’s own WebRTC AEC. Having two independent echo cancellers in the chain is usually harmless, but in rare cases can cause artifacts. When troubleshooting echo, it is worth knowing whether the headset applies AEC itself.
Audio Effects and Equalizers: Many headsets ship with companion software (Jabra Direct, Poly Lens, Logitech G Hub, etc.) that allows tuning of EQ, sidetone level, voice enhancement, and other parameters. Default profiles are generally optimized for voice, but support teams may ask agents to reset these to defaults when diagnosing audio quality issues.
Gain and Microphone Sensitivity: Some headsets allow adjusting the microphone gain either through companion software or directly via buttons on the device. Incorrect gain settings (too high or too low) are a common cause of clipping, distortion, or low volume. When all other parameters seem correct, checking the headset’s own gain setting is a useful diagnostic step.

Note: These features should be used with care. Audio processing can be applied at multiple levels simultaneously — the headset firmware, the companion software, and the OS itself (macOS, for instance, applies its own built-in audio effects and enhancements on some devices). Always know what is active at each level and what effect it has: stacking multiple processors without understanding them is a common source of degraded or unpredictable audio quality. When an issue occurs, systematically disabling effects one layer at a time is a reliable diagnostic approach. These features are generally configured through the headset’s companion software, not the OS or browser. Keep companion software up to date alongside the headset firmware, as both regularly receive audio processing improvements.

Reducing Ambient Noise

A noisy environment (open-plan office, air conditioning, printers, nearby conversations) significantly degrades intelligibility, even with noise suppression algorithms.
Headsets with directional microphones and noise reduction help significantly, but they are not a substitute for a quiet environment. When possible, agents should work from a dedicated, acoustically isolated room to ensure consistent call quality regardless of the headset used.

Network considerations

Connection Type

Status	Connection Type
First class	Wired Ethernet
Supported	Wi-Fi (home or corporate, good signal)
Not recommended	4G/5G mobile hotspot, 4G USB card, public or free access points

In details:

Ethernet: The best configuration for an agent. Wired connections are stable, low-latency, and unaffected by radio interference or neighbor congestion.
Wi-Fi: Acceptable when a wired connection is not available, but more susceptible to interference from other access points, walls, and nearby devices (microwave ovens, cordless phones). Signal strength and stability should be verified before starting a session.
4G/5G mobile hotspot: Using a smartphone’s shared mobile connection is not a good practice and should be avoided whenever a fixed connection is available. It drains the phone’s battery rapidly, and cellular connections are inherently subject to interruptions — coverage variations, tower handoffs, and congestion. Inside buildings, 4G/5G signal can be weak or unstable, making it unreliable for sustained real-time audio.
4G USB card (integrated or dongle): Similar limitations apply to laptops equipped with a built-in 4G/LTE card or a USB cellular dongle. The connection quality depends entirely on cell coverage, which cannot be guaranteed indoors, and is not appropriate as a primary connection for call center use.
Public or free access points (coffee shops, shared coworking Wi-Fi, hotel networks): These networks are shared among many unknown users, often throttled, and offer no Quality of Service guarantees. They are unpredictable for real-time audio and should not be used for production calls. Beyond performance, they also raise serious security concerns.

Note — Test before starting: Always run a quick connection quality check before the start of a production session, especially on Wi-Fi. Use a speed test (e.g., fast.com or speedtest.net) to verify that latency is below 150 ms and that bandwidth is at least a few Mbit/s in both directions. If results are poor, switch to Ethernet or move closer to the access point before taking calls.

VPN Usage

Using a VPN during WebRTC calls is generally not recommended and should be avoided if the platform does not require it.

The main issue is geographic routing: WebRTC relies on connecting to the closest available media server or TURN relay to minimize latency. When a VPN is active, all traffic is routed through the VPN’s exit point, which may be located in a completely different region from the agent. This can significantly increase round-trip latency and introduce jitter, both of which directly degrade call quality.

Additionally, VPN tunnels add encryption overhead and can reduce effective bandwidth, which further impacts real-time audio streams.

Exception: If the agent is connecting from a public or untrusted network (see section 4.1), using a corporate VPN remains the right security decision despite the performance trade-off.

Bandwidth and Quality

The table below summarizes typical network requirements per use case. Values are per-agent (not per site) and assume a single active session.

Use case	Upload	Download	Max latency (RTT)
Audio	15–100 kbit/s	15–100 kbit/s	< 150 ms
Audio + video	1–2 Mbit/s	1–2 Mbit/s	< 150 ms
Conference	2–3 Mbit/s	2–3 Mbit/s	< 150 ms

Key quality thresholds (all scenarios):

Packet loss: < 1% — above this, audio quality degrades noticeably, especially when using the G.711 codec
Jitter: < 30 ms — higher jitter causes choppy or robotic sound even with adequate bandwidth
Latency (RTT): < 150 ms to keep the conversation smooth

Note: These are indicative values for planning purposes. Actual consumption depends on the codec negotiated, the platform’s behavior, and the number of simultaneous streams. When in doubt, measure with the actual application using the connection test tool if available.

Preventing Network Issues

Avoid parallel downloads and updates during production hours. OS updates, application updates, cloud sync (OneDrive, Dropbox, Google Drive), and background backups all consume upload and/or download bandwidth and can directly degrade call quality mid-session.
Stop bandwidth-intensive applications before starting calls: video streaming, large file transfers, software installations, and any tool performing continuous synchronization in the background.
Be aware of security software that may interfere with WebRTC traffic. Tools such as Zscaler, network-level antivirus agents, or corporate firewalls with deep packet inspection can block STUN/TURN signaling, throttle UDP media streams, or introduce significant latency. If calls fail to connect or audio is consistently degraded only on the corporate network, security software should be investigated as a potential cause and reported to IT.

Note — Speed test: Before starting a production session, run a quick speed test to verify that latency is below 150 ms and bandwidth is at least a few Mbit/s in both directions. When available, also use the call center WebRTC application’s built-in connection test page, which typically checks the microphone, bandwidth, and firewall configuration in one step.

Troubleshooting Guide

This chapter provides a symptom-based troubleshooting reference for the most common call issues. Each section describes a specific symptom and lists the steps to follow in order, from the simplest check to the less obvious causes.

The goal is to allow agents to self-diagnose and resolve the most frequent problems without immediately escalating to support.

This list is not exhaustive — it covers the most common issues, but some issues may require deeper investigation specific to the workstation or platform. If none of these steps resolve the problem, escalate to support with the context described in the next chapter.

Common Issues — Quick Reference

The table below lists the most common symptoms and the primary area to investigate first. Each symptom links to the corresponding section for detailed steps.

Symptom	Investigations
I cannot hear the customer	Headset
The customer cannot hear me	Microphone
Customer volume too low ot too loud	Headset
Bad audio quality	Network
Intermittent dropouts	Connectivity
Call fails to connect	Application or Network
Echo heard by the customer	Microphone and Speakers
Frozen or blurry video	Network or CPU
Microphone not detected	Browser or OS

Audio Device Diagnostics

Specific to microphone (customer cannot hear you):

Check in the application that the microphone is not muted (crossed microphone icon).
Verify that the correct input device is selected — it must be the headset microphone, not the built-in PC microphone.
Check the audio level indicator (bar or meter) in the application: if it does not move when you speak, the microphone is not capturing anything.
Close other applications that may be holding the microphone exclusively (Teams, Zoom, recording tools).
Test the microphone in the system settings (Windows Sound panel → Recording tab, or macOS Sound Settings → Input) to verify it works outside the browser.

Specific to headset/speakers (you cannot hear the customer):

Check the physical volume control on the headset (buttons or wheel).
If Bluetooth, check the battery level — low battery is a frequent cause of silent or degraded audio.
Confirm that the correct headset is selected as the output device in the application — the headset name must appear explicitly.
Test with another application: play something on YouTube or equivalent to confirm the headset produces sound outside the call application.

Common checks (both directions affected):

Verify the call is still active and properly connected — not on hold, not silently disconnected.
Open system sound settings and confirm the headset is set as the default device for both input and output, and that system volume is not muted.
Check for system notifications about disconnection. For Bluetooth: verify the headset is still paired. For USB/jack: reseat the cable or try a different USB port.
(Windows only) Disable Exclusive Mode: Windows allows applications to take exclusive control of an audio device, which can prevent other applications (including the browser) from accessing it. To disable: open Sound settings → right-click the audio device → Properties → Advanced tab → uncheck “Allow applications to take exclusive control of this device” for both the playback and recording devices. This is a common but overlooked cause of audio conflicts when multiple communication tools are installed.

Network Diagnostics

Symptoms suggesting a network issue include: robotic or metallic sound, choppy audio, intermittent dropouts, calls that fail to connect.

Diagnostic steps:

Run a speed test (fast.com or speedtest.net) and check that latency is below 150 ms and packet loss is at 0%. Even 1–2% packet loss causes noticeable audio degradation.
Check that no parallel downloads, OS updates, or cloud sync (OneDrive, Dropbox) are running and consuming bandwidth.
If on Wi-Fi, switch to Ethernet and retest. If the issue disappears, the problem is Wi-Fi related (interference, weak signal, roaming between access points or multi-bands switches).
If on Wi-Fi and Ethernet is not available, move closer to the access point and retest.
Close heavy applications and unnecessary browser tabs. Check in Task Manager (Windows) or Activity Monitor (macOS) that CPU usage is not at 100% — CPU overload can produce audio symptoms similar to packet loss.
Check for any antivirus that can have a firewall, vpn or browser’s extension that can block the call to establish.

Echo (Specific)

If the customer hears an echo of their own voice, the problem is almost always on the agent’s side.

Switch to a headset with a close-talking boom microphone if not already using one.
Reduce the headset volume if sound is leaking from the ear cups into the microphone.
Open system sound settings and verify that only the headset microphone is active as the input device — disable the built-in PC microphone if both are listed.
Ensure the microphone boom is positioned 1–2 cm from the corner of the mouth.

Video Quality (Specific)

Frozen or very blurry image: typically caused by insufficient bandwidth or CPU saturation. Disable video if it is not essential to prioritize audio quality, and check network and CPU load as described in section 5.3.
Background blur causing performance issues: background processing is GPU-accelerated but CPU-intensive on machines without a dedicated GPU. Disable the effect if the CPU is under load during calls.

Headset or Microphone Not Detected (specific)

When the headset or microphone does not appear in the application or the OS, follow these steps:

For USB headsets:

Unplug and replug the headset — try a different USB port directly on the PC, avoiding hubs or adapters if possible.
Check in the OS that the device appears: Windows Device Manager (look for audio devices with no warning icon), or macOS System Information → USB. If the device is not listed at all, the cable, USB port, or headset hardware may be faulty.
Update or reinstall the headset driver (Windows only): Device Manager → right-click the audio device → Update driv er. For headsets with companion software, reinstall the companion app.

For Bluetooth headsets:

Verify the headset is powered on and in pairing/connected mode.
Check that it is not already connected to another device (phone, previous PC session) — Bluetooth headsets often connect to the last paired device automatically.
If using a dedicated dongle, ensure the dongle is plugged in and that the headset is paired to the dongle specifically, not to the PC’s native Bluetooth.
If the headset does not appear at all, try unpairing and re-pairing it from scratch.

Browser-level permission denied:

Check the browser’s site permissions: click the padlock icon in the address bar → Microphone must be set to Allow (not Block). If it was previously blocked, reset the permission and reload the page.
On macOS, the OS also manages microphone access independently: System Settings → Privacy & Security → Microphone → ensure the browser is listed and enabled.
On Windows, check Settings → Privacy & Security → Microphone → ensure “Allow apps to access your microphone” is on, and that the specific browser is allowed.

General Reset Steps

When a problem cannot be resolved through symptom-specific steps, or when the cause is unclear, apply the following general reset procedure in order:

Restart the web application: log out and log back in, then check again.
Restart the browser: close it completely (all windows) and reopen it. This resets the audio stack, permissions, and WebRTC state within the browser.
Restart the PC: this resolves a wider range of issues — stale audio drivers, Bluetooth stack state, USB device conflicts, and memory pressure.
Check for pending updates: verify that the OS, the browser, and any headset companion software are up to date, and install any available updates. Restart again if updates were applied.
Test the headset on another device: connect the headset to a smartphone or a different PC and test a call or audio playback. If the headset works correctly on another device, the issue is likely specific to the original workstation configuration. If the headset also fails on another device, the headset itself may be defective.

This list is not exhaustive — it covers the most common reset actions, but some issues may require deeper investigation specific to the workstation or platform. If none of these steps resolve the problem, escalate to support with the context described in the next chapter.

Helping the Support team

When a WebRTC issue occurs and cannot be resolved through standard troubleshooting, the support team may need to collect technical information from the agent’s session. This section explains how to gather the most useful data when asked.

Most of the time, collecting useful information requires reproducing the issue. Also note whether the issue is 100% reproducible or only happens occasionally: this is a valuable pieces of context for the support team.

Context and First Information

When a problem occurs, note the exact time and write a short description of what happened. The timestamp is the single most critical piece of information: it allows the support team to correlate client-side observations with server-side logs.

If support asks, be ready to provide:

OS name and version (e.g., Windows 11 23H2, macOS 15.3)
Browser name and exact version (e.g., Chrome 124.0.6367.92)
A description of the symptom and when it started

In most cases, support will also ask for logs. See the following sections.

WebRTC Debug information

WebRTC exposes lot of statistics (packet loss, jitter, codec, bitrate, etc.) and information. These can be captured by the application itself or via browser tools.

Legacy method — chrome://webrtc-internals: In Chrome or Edge, open a new tab and navigate to chrome://webrtc-internals (or edge://webrtc-internals). This page displays all active and recent WebRTC sessions with statistics. When support asks for an rtcStats dump, click “Download the “rtcstats dump” to export a debug file that can be shared with the team.

Note: Some WebRTC platforms automatically collect and send rtcStats to a backend thanks to the rtcstats open-source. In that case, the support team can retrieve the session data directly (using the userId and timestamp).

Developer Console

The browser developer console captures JavaScript errors, network warnings, and application-level log messages that are not visible in the interface.

To open the developer console:

Chrome / Edge / Firefox (Windows/Linux): Press F12 or Ctrl + Shift + I, then go to the Console tab.
Chrome / Edge / Safari (macOS): Press Cmd + Option + I, then go to the Console tab. On Safari, developer tools must first be enabled in Safari → Settings → Advanced → Show Develop menu.

When support asks for console logs, reproduce the issue if possible, then right-click in the Console area and select “Save as…” or copy the relevant error messages and paste them into the support ticket.

Note: If you need to inspect the network requests and responses, the browser developer console should be opened prior to the manipulations.

Chrome Debug Mode (Low-Level WebRTC Logs)

For deep investigations, Chrome can be launched with additional logging flags that capture low-level WebRTC and audio processing traces.

macOS:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --enable-logging=stderr \
  --v=1 \
  --vmodule=*/webrtc/*=3,*/libjingle/*=3 \
  2> ~/Desktop/chrome_webrtc_debug.log

Windows (run from Command Prompt):

"C:\Program Files\Google\Chrome\Application\chrome.exe" ^
  --enable-logging=stderr ^
  --v=1 ^
  --vmodule=*/webrtc/*=3,*/libjingle/*=3 ^
  2> "%USERPROFILE%\Desktop\chrome_webrtc_debug.log"

Reproduce the issue while Chrome is running in this mode, then share the generated log file (chrome_webrtc_debug.log) with support. These logs are verbose and should only be collected when specifically requested, as they can grow large quickly.

Wrapping Up

Most call quality problems are not caused by bugs in the WebRTC platform itself. They are caused by the environment around it. An unsupported OS, a misconfigured audio device, a Wi-Fi connection competing with a background sync, a browser that hasn’t been restarted in a week: these are the real culprits in the vast majority of support tickets. And the network…

The good news is that most of these issues are preventable. A properly set up workstation, wired headset, stable Ethernet connection, up-to-date browser, eliminates the majority of problems before they even occur. The checklist is not long, and it does not require deep technical knowledge to apply.

When something does go wrong, start with the simplest explanation: check the headset volume, verify the selected audio device, run a speed test, restart the browser. Use the troubleshooting sections in this guide to resolve yourself the issue.

And when self-diagnosis is not enough, give support the right information: the exact time of the incident, the OS and browser version, and the logs described in the debugging section. With that context, most issues can be traced and resolved quickly.

Good calls start with a good setup.