Symptoms
You may come across different kinds of audio issues in Communication Panel (for example, the first call of the day being muted).
Solution
Check the following settings on the user’s workstation.
Disable Windows power-saving settings
New Windows versions introduce more aggressive power-saving behaviors. USB headsets may be in low-power mode on first use, causing the first call to be muted.
These settings can be in multiple places, depending on the computer. Go through all of the following.
Power options:
- Go to Control Panel (view by Large icons) > Power Options > Change plan settings (of the active power plan) > Change advanced power settings > USB settings > USB selective suspend setting.
- Set both On battery and Plugged in to Disabled.
Device Manager:
- Go to Control Panel (view by: Large icons) > Device Manager > Universal Serial Bus controllers.
- Edit the properties of each controller with “Hub” in the title.
- Select the Power Management tab.
- Deselect Allow the computer to turn off this device to save power.
Install headset manufacturer-specific drivers and firmware
The Brands selection in Communication Panel audio settings can cause problems if the manufacturer-specific headset drivers and firmware are not installed.
Make sure that drivers and firmware have been installed before selecting the brand in Communication Panel audio settings. If the drivers and firmware have not been installed, select Other Brand. Otherwise, the integration may not work as expected and it can cause various other problems.
You can find more information about prerequisites for different brands in the Operation Guide document.
Ensure the browser has permission to use the microphone
Windows 11 has tightened app permission handling for microphones. On first use, the system may delay or block microphone access. This can cause the first call to have no outbound audio (agent can’t be heard). Audio works after the first conversation.
Ensure that the browser has permission to use the microphone:
- Chrome: Settings > Privacy and security > Site settings > Microphone
- Edge: Settings > Cookies and site permissions > All permissions > Microphone
We also recommend agents to:
- Close Communication Panel at the end of each workday.
- Test audio by placing a test call after a Windows reboot or recovering from sleep mode.
In on-premise environments: check the following in your infrastructure in addition to the workstation settings
NAT binding timeout (UDP media ports)
NAT/firewall closes UDP port bindings during idle periods (for example overnight). In the first call of the day, the RTP stream is sent to a now invalid NAT mapping, resulting in one-way or no audio.
To fix this:
- Enable RTP keep-alive on the AudioCodes SBC and/or SIP endpoints.
- Configure frequent enough NAT binding refreshes (for example, every 15-30 seconds).
- Use symmetric RTP if supported.
Codec mismatch or delayed negotiation
Codec negotiation failure or delay in SDP exchange on the first call may cause missing audio.
To fix this:
- Verify codec priorities and make sure common codecs (for example, G.711 and Opus) are aligned across systems.
- Make sure there's no asymmetric codec handling on the first session.
SBC media session not properly initialized
The first media path may not get properly opened due to the SBC being in a dormant or idle state, or media anchoring not being fully active.
To fix this:
- Check if media-anchoring or early media support is properly configured.
- Enable media timeout settings or pre-establishment of RTP on the SBC.
- Ensure ICE/STUN/TURN is used if endpoints are WebRTC-based or behind NAT.
Ensure that the latest firmware is installed on the SBC
It is always a good practice to keep SBC firmware as up to date as possible.
General diagnostic steps to investigate the issue
- Check SBC syslog and trace files for the first call SIP and RTP behavior.
- Use tools like Wireshark or SBC's built-in trace tools to verify:
- SDP negotiation
- RTP stream establishment
- NAT behavior
