WebRTC Softphone Disconnects with 408 Request Timeout in Multi-Org App

Quick question about WebRTC connectivity within a multi-org AppFoundry application.

We are deploying a premium app that manages simultaneous sessions across three distinct Genesys Cloud organizations. The primary tenant initiates the WebSocket handshake successfully, but when the application attempts to establish a secondary softphone connection for a secondary org using a distinct OAuth token, the media stream fails immediately.

The browser console logs a 408 Request Timeout on the signaling channel, specifically during the SDP exchange phase. This occurs even though the secondary org has WebRTC enabled and the user possesses the correct ‘Softphone’ user capability. The primary org connection remains stable throughout the test.

We have verified that the client-side SDK is using the latest version compatible with the current API release. Rate limiting does not appear to be the culprit, as the request volume is well below the 100 req/min burst threshold per tenant. The issue persists across Chrome and Firefox, ruling out browser-specific codec issues.

Is there a known limitation regarding concurrent WebRTC sessions from a single client IP or application context across multiple tenants? We are seeing this behavior consistently in the us-east-1 region.

Make sure you verify that the WebRTC handshake timeout aligns with your recording export latency requirements. High-concurrency sessions often trigger 408 errors if the media stream initialization exceeds the default 15-second window. Adjust the iceTimeout in your client configuration.

Have you tried increasing the iceTimeout parameter as suggested above? The default 15-second window is frequently insufficient for multi-tenant initialization, so extending this value often resolves the 408 timeout without requiring deeper architectural changes.