Hi Vinicius,
For WebRTC issues, I normally troubleshoot by layers rather than starting with SIP traces or assuming a platform problem.
My usual sequence is:
1. First isolate the scope
Before looking at logs, determine whether the issue follows:
- the user
- the workstation
- the network/location
- the browser
- or the interaction itself
A very effective test is:
Same user → different workstation
and:
Different user → same workstation
Genesys also recommends this approach for WebRTC troubleshooting because it quickly separates user/configuration issues from workstation/network issues.
2. Run the Genesys Cloud WebRTC Diagnostics
This is usually my first technical test.
From the WebRTC phone settings, use Run Diagnostics.
It validates:
- Streaming connection
- WebRTC station
- Call connection
- Call quality
- DNS/connectivity to Genesys media services
The results also expose useful media metrics such as:
- MOS
- Packet loss
- RTT/latency
- Jitter
If packet loss or jitter is already poor here, I normally investigate the local/network path before looking at Architect, queues, or routing.
3. Check the actual interaction in Genesys
For a real affected call, capture the Conversation ID and review the interaction details.
I normally check:
- MOS
- call timeline
- disconnect behavior
- participant legs
- SIP diagnostics where relevant
- whether the problem affected only the agent leg or the complete call
Genesys exposes MOS in the Interactions views, which is useful for distinguishing media-quality problems from signaling or application problems.
4. Validate browser and workstation
For browser-side issues, check:
- Supported/current browser version
- Microphone permission
- Correct input/output device
- Headset recognized by the operating system
- Another application holding the microphone
- Browser cache/session
- Whether the problem follows the headset or workstation
Genesys specifically recommends testing another microphone/speaker, restarting the browser/client, changing browsers, and validating microphone permissions.
5. Validate the network path
If WebRTC Diagnostics shows connectivity or media issues, I move to the network.
For a typical WebRTC deployment, verify the required Genesys connectivity, including signaling and media paths such as:
- TCP 443
- STUN connectivity
- UDP media/SRTP ranges required for the deployment
The exact ports and destinations depend on whether the environment uses Genesys Cloud Voice, BYOC Cloud, or BYOC Premises, so I always compare the firewall configuration against the Genesys Ports and Services for WebRTC documentation rather than using a generic firewall rule set.
VPN is another useful isolation test. Genesys explicitly recommends testing without the VPN when investigating WebRTC connectivity.
I would also review NAT behavior and any proxy/security inspection in the media path. Genesys does not support using private STUN/TURN proxy servers, and SSL inspection support is limited to HTTPS/443 traffic rather than the complete WebRTC media path.
6. Capture browser logs while reproducing the issue
If the problem is intermittent or not obvious from WebRTC Diagnostics, capture:
- Browser Console logs
- Network/HAR logs
with Preserve log enabled, reproduce the problem, and record the exact timestamp.
Genesys Product Support specifically uses console and network logs for WebRTC and call-control troubleshooting because they can correlate browser-side events with Genesys Cloud-side logging.
7. Use SIP traces only when the evidence points to the telephony leg
SIP traces are extremely useful, but I would not make them the first troubleshooting tool for a browser-side WebRTC problem.
If the WebRTC station is established correctly but the PSTN/carrier side has issues such as:
- call setup failure
- unexpected disconnect
- one-way audio associated with the external leg
- transfer failure
- codec/signaling problems
then SIP diagnostics, SBC/carrier traces, and packet captures become much more relevant.
My practical order is therefore:
Reproduce
→ Isolate user/workstation/network
→ WebRTC Diagnostics
→ Interaction/MOS
→ Browser/device
→ Firewall/network
→ Console + HAR
→ SIP/carrier traces if required
The biggest troubleshooting improvement for me is always correlation.
A support case with only "audio was bad" is difficult to investigate.
A case with:
Conversation ID + exact timestamp + affected agent + WebRTC Diagnostic results + MOS + Console/HAR logs + network information
usually makes it much easier to determine whether the problem is browser, workstation, network, WebRTC media, Genesys configuration, or the external telephony path.
------------------------------
Gabriel
NA
------------------------------