Genesys Cloud - Main

Hi Folks,

In many instances we have observed one way audio issue where no audio comes from agent end and in logs we see bellow:

directory/:270 [streaming-client] IceCandidateError {errorCode: 701, errorText: 'STUN host lookup received error.', url: 'stun:turn.euc1.pure.cloud:3478', conversationId: '******************', sessionId: '*****************', …}

Do you know how to fix this ? Our setup as below

All HTTPS traffic goes via proxy..no issues there, all web functionalities works fine.

All UDP/Media goes though firewall, we have all the necessary rules in firewall , from user network to Genesys CIDR on port 3478,and the UDP range for media and to google stun as well in port 19302.

For VPN , traffic goes via split tunnel  directly to internet.

Could you please suggest how to fix the issue or is there any setting can be enabled as a workaround in genesys ?

Support always says you have network issue but in vast network they don't say probable pin points to be checked .

Thanks in Advance,

Rajdeep

HI Rajdeep, 

As per your description, it seems some firewall rules are not good from source to destination. I am guessing, issue will be with handful of users with given error. 

You can utilize WebRTC tool along with "Network Assessment Tool" while checking the network. WireShark logs can help you to dig further where packet is dropping. ICEerror are always related to connection break of WebRTC phone. 

Hi Prakash,

Can you please elaborate what you mean by bad firewall rules ?

Thanks,

Rajdeep

Hi Andreas,

Yes my PC is able to resolve resolve external FQDN and STUN traffics are going trough firewall in our case.

Could you please share your thoughts here ?

Thanks,

Rajdeep

Also, in our Firewall rule the inspection is enabled (on the rule), on the Firewall it self the SIP ALG inspection is also enabled, do you have any suggestion here ?

Thanks,

Rajdeep 

Hello Datta,

In recent migration I experienced same issue with one of our clients, is is 100% a VPN/Firewall/Security issue, make sure all ports are enabled for STUN/TURN

https://help.genesys.cloud/articles/ports-and-services-for-genesys-cloud-clients/

Regards

Hi Danail,

I have checked the ports and found all the ports are open. The issue is very intermittent . In our Firewall rule the inspections are enabled, does it causing the issue?

Thanks,

Rajdeep

Hi,

Could be, unfortunately I cannot help here, since the issue we experienced in the migration was solved by Client´s Comms team, and the only feedback they gave us was that it was a Netscope issue from their Fortinet VPN..

Regards

Hello,

You're dealing with a classic and frustrating issue. The IceCandidateError with error code 701, particularly the STUN host lookup received error text, is a clear signal that the WebRTC connection between the agent's browser and the Genesys Cloud media services is failing during the initial negotiation phase . In simple terms, the agent's machine is trying to find a viable path to send and receive audio, but the network is preventing it from discovering its own public IP address or from communicating with the necessary STUN/TURN servers . This is why, even though your web functionalities work, the audio path can't be established.

The support team's network diagnosis is very likely correct. The problem almost always lies in how network traffic is being handled, even when firewalls rules seem correct . While you've opened the primary UDP ports, the issue often comes down to deeper inspection or connectivity to specific endpoints. For instance, port 19302 to Google's STUN servers is a common requirement that might be blocked, and the error log explicitly mentions it's looking for stun:turn.euc1.pure.cloud . Other frequent culprits include proxy servers interfering with the media path, or VPNs and firewalls with aggressive NAT timeouts that drop the UDP media sessions . Disabling features like SIP ALG on your firewalls is also highly recommended, as it often causes more harm than good with WebRTC .

Here is a practical, step-by-step troubleshooting path to pinpoint the issue:

Re-validate Firewall and Proxy Rules: Double-check that all the required IP addresses and ports are explicitly allowed and, crucially, that no deep packet inspection (DPI) or SSL decryption is being applied to this traffic . Your firewall rule for UDP ports 16384-65535 is correct, but ensure the source and destination are correctly specified . Also, explicitly allow connectivity to stun:turn.euc1.pure.cloud on port 3478 and to Google's STUN service on port 19302 . If you haven't already, consider adding the full set of Genesys Cloud CIDR IP address ranges to your allowlist .

Test with the WebRTC Troubleshooter: Have the affected agent use the built-in Genesys Cloud WebRTC Diagnostics app . This tool runs a series of connectivity tests directly from their browser and will often highlight the specific point of failure, providing more concrete evidence of the network issue .

Check for VPN and Split Tunneling Issues: Since you're using split tunneling, confirm that the UDP media traffic is actually going out through the tunnel to the internet and not being forced through the corporate network where it might be blocked. You can test this by having an agent connect from a network that is not behind the corporate VPN/firewall (e.g., a personal hotspot) as a comparison .

Force Relay/TURN Behavior (As a Workaround): As a last resort to test, you can try forcing the WebRTC connection to always use the TURN relay server. This can bypass some complex NAT and firewall issues but will route all media through an additional relay, which may increase latency and is not an ideal long-term solution .

I hope these targeted steps help you and your network team zero in on the root cause. Let me know if you need any more details on these steps.