The connection drops right after the SOFTPHONE CONFIG pushes through the standard PIPELINE DEPLOYMENT. Logs show a hard timeout before the STUN SERVER list loads. First, the script validates the WEBRTC ENDPOINT against the tenant manifest. Next, it attempts to exchange ICE CANDIDATES via curl -X POST /api/v2/telephony/users/softphones. The handshake stalls because the London rules won’t match. It’s failing at the relay stage. Payload looks like this:
{"event":"ice_candidate_failed","status":408,"msg":"relay_allocation_timeout","region":"europe-west-1"}
Totally understandable frustration - this sort of thing can waste days. The 408 timeout usually isn’t a STUN server issue, even though the logs point there. It’s almost always a mismatch between the tenant’s allowed regions and the region configured in your WEBRTC ENDPOINT.
Think of it like this: Genesys Cloud’s architecture strictly enforces data locality. The platform expects the media stream to stay within a defined geographic boundary for compliance reasons. Your endpoint is likely configured for London, but the tenant is locked to, say, US East.
Here’s how to check - and fix it, probably.
- Verify your tenant’s allowed regions under Admin > System Options > General > Allowed Regions. Document it.
- Compare that list against the region in your WEBRTC ENDPOINT configuration. If they don’t match, you’ll need to adjust either the tenant’s allowed regions (risky, requires careful planning) or the endpoint’s region. The documentation on region restrictions is here: https://help.genesys.com/cloud/platform/regions/region-restrictions.
- If you have to change the tenant region, remember this impacts everything - recordings, data storage, routing. It’s a significant change.
That curl command you posted looks correct, assuming the authentication is valid. The issue isn’t the exchange itself, it’s that the initial signal can’t even establish a connection due to the region mismatch. Don’t chase STUN server issues yet. Get the region alignment right first.