Hello Masahiro,
Based on what you've described, I'd focus on isolating whether the issue is related to the user, the device, the browser, or the network. Since only 3 out of 21 outbound calls were affected, gathering as much information as possible from those specific interactions will be key.
1. Start with the Affected Calls
I'd begin by reviewing the three affected interactions in Analytics Workspace.
From the interaction details, take a look at the media statistics, including:
Packet loss, jitter, and latency
Codec information
MOS and R-Factor values
Received, discarded, and invalid packet counts
I'd also recommend downloading the SIP diagnostics and PCAP files for those interactions. Comparing a working call to one of the affected calls can sometimes reveal differences in SIP signaling or media negotiation.
If the calls are recent enough (within about 45 minutes), I'd also flag them as a Voice Quality Issue. That preserves additional diagnostic information if further investigation is needed.
2. Isolate the User vs. the Device
The next step I'd take is some basic isolation testing:
Have the affected user place outbound calls from a different computer.
Have another user log into the affected computer and place outbound calls.
Try a different supported browser (Chrome, Edge, Firefox).
This will help determine whether the issue follows the user, the device, or the browser.
If the user is using the embedded WebRTC phone, I'd also try changing the WebRTC phone behavior to Pop WebRTC Phone Window under:
Menu > More > Settings > WebRTC
I've seen this resolve microphone-related issues in some browser environments.
3. Run WebRTC Diagnostics
I'd also have the affected user run the built-in WebRTC diagnostics.
From the Calls panel:
Open Phone Settings
Select Run Diagnostics
I'd try running the diagnostics during a normal session and again as close as possible to when the issue occurs.
While you're there, I'd also verify:
The correct microphone is selected.
Browser microphone permissions are still granted.
No other applications are actively using the microphone.
Audio settings such as gain, echo cancellation, and noise suppression look normal.
4. Review Network Conditions
Because the issue is intermittent and seems limited to outbound calls, I'd also review the network.
Running the Genesys Cloud Network Readiness Assessment is a good place to start. If possible, compare the results from a time when calls work normally versus when the issue occurs.
I'd also compare the SIP diagnostics for inbound versus outbound calls to see if there are any differences in media routing, codec negotiation, or RTP establishment.
5. Verify Browser and System Configuration
I'd also confirm a few basics:
Browser microphone permissions are permanently allowed.
Browser cache has been cleared.
No browser extensions are interfering with WebRTC.
The headset and microphone are functioning normally at the operating system level.
No endpoint security software is interfering with media streams.
6. Look for a Pattern
Since only a small percentage of calls are affected, I'd also look for anything those calls have in common.
For example:
Do they occur at a particular time of day?
Are they only happening with Click-to-Dial?
Does the same issue occur if the user places an outbound call directly from Genesys Cloud instead of through Salesforce?
That last test can help determine whether the behavior is specific to the Salesforce integration or the WebRTC client itself.
7. If the Issue Persists
If the isolation testing doesn't identify the cause, I'd collect the following before opening a Support Case:
The affected interaction IDs
Results from the isolation testing
WebRTC diagnostics
Network Readiness Assessment results
SIP traces and PCAP files
Browser version, operating system, and WebRTC configuration
One thing that stood out from your description is the fact that callers hear white noise instead of complete silence.
To me, that suggests the media path is likely being established successfully, and the microphone is being accessed, but the voice audio itself isn't being transmitted correctly. That could point to something like microphone initialization, codec negotiation, or browser/media stream timing rather than a complete connectivity issue.
The intermittent nature of the problem also makes me lean toward a timing or initialization issue instead of a hardware failure, especially since the calls either work normally or fail completely with no gradual degradation in between.
Hope this helps!
------------------------------
Cameron
Online Community Manager/Moderator
------------------------------