WebRTC media path fails for Sydney agents when ACMA recording is enabled

Voice & Telephony
1

Pushed the queue config through the pipeline yesterday. Everything’s looking solid in Architect until the recording toggle flips on. Sydney agents are dropping the second they try to answer inbound calls routed to the compliance queue. Console dumps RTCPeerConnection: state changed to failed right after ICE candidate gathering timed out (srflx). Signal handshake completes fine, but media never routes.

Using @genesys/web-sdk v2024.9.1 in the wrapper. STUN servers are pointing to the default APAC edge, but the TURN fallback isn’t kicking in for the AU region. Network trace shows the candidate exchange stops dead at a=candidate:2 1 udp 1677729535 10.128.4.5 5001 typ srflx. Looks like the relay server for mypurecloud.com.au is rejecting the binding request when the recordingsEnabled flag is set to true.

Tried bypassing the queue recording setting and routing through a standard task flow instead. Media connects instantly. Switch back to the compliance queue with ACMA retention rules attached and the softphone drops again. Latency sits around 180ms from Melbourne to the edge, which shouldn’t kill the handshake. Candidate timeout hits exactly at 8000ms every single time. Basically doing jack all to fix the media path.

Environment details:

  • Org region: APAC
  • SDK: @genesys/web-sdk 2024.9.1
  • Architect flow: Standard IVR → Queue (recordingsEnabled: true) → Agent
  • Error: WebRTC connection failed: ICE candidate gathering timed out after 8000ms
  • Network: Corporate VPN disabled, direct fiber to Telstra

Already spun up a custom TURN relay in Sydney and updated the window.GenesysCloudWebRTC config object. Still hitting the same wall. Signaling channel stays open but the SDP exchange never resolves to a working candidate. Media path just flatlines.

Logs show the STUN server responding with 400 Bad Request on the binding response. Edge might be choking on the payload format when the recording service tries to intercept the media stream. ACMA compliance requires the recording toggle to stay active for every interaction.

{
 "error": "ICE_CANDIDATE_GATHERING_FAILED",
 "candidateType": "srflx",
 "timeoutMs": 8000,
 "region": "ap-southeast-2",
 "recordingEnabled": true,
 "stunResponse": 400
}
2

The issue isn’t the WebRTC handshake itself. It’s the media server selection logic conflicting with ACMA requirements.

When ACMA recording is enabled, Genesys forces media through a compliant media server located in the AP-SE region. If your @genesys/web-sdk initialization doesn’t explicitly set the correct region for the media endpoint, the SDK tries to connect to the default US or EU media server. That server can’t serve ACMA-compliant recordings for an Australian agent, so the ICE gathering hangs on srflx candidates that never validate against the local network.

Check your GenesysCloudWebSdk.init call. You likely have region: 'us-east-1' or similar. Change it to region: 'ap-southeast-2'.

const sdk = new GenesysCloudWebSdk();
await sdk.init({
 orgId: 'your-org-id',
 clientId: 'your-client-id',
 clientSecret: 'your-client-secret',
 region: 'ap-southeast-2', // Critical for Sydney/ACMA
 logLevel: 'debug'
});

Also verify the queue configuration in Architect. The “Recording” section must have “Compliance Recording” set to “ACMA” specifically, not just “On”. If it’s set to generic “On”, the platform might try to use a non-compliant server path, which fails for agents in regulated regions like Sydney.

I’ve seen this exact ICE candidate gathering timed out error when the region mismatch occurs. The signal handshake works because signaling is global, but media is regional. Once you align the SDK region with the agent’s physical location and ensure the compliance type is correct, the media path should establish.

Don’t forget to clear the browser cache or do a hard refresh after changing the SDK init params. The old region config might stick in local storage.