Webrtc softphone fails to connect on ios 17

Voice & Telephony
1

How come this setting causes the webrtc softphone to drop the connection immediately on ios 17? using the latest sdk version 1.2.4. no errors in the console but the call never rings. checked the firewall and ports are open. any ideas?

2

The problem is likely that related to how the iOS 17 network stack handles STUN/TURN candidates during the initial handshake, especially if the deployment relies on default Genesys Cloud media settings. The SDK 1.2.4 might be timing out while waiting for ICE candidates if the firewall is strictly filtering UDP traffic or if the TURN server configuration in the Terraform state is not explicitly allowing fallback to TCP. Check the genesyscloud_routing_edge_group configuration to ensure the correct media region is assigned. Also, verify that the genesyscloud_user_settings for the specific user has webrtc_enabled set to true and that no custom media_settings are overriding the default codec preferences. A quick fix is to force the SDK to use TCP-only for media transport by updating the client configuration in the app wrapper. This bypasses the UDP timeout issue common in newer iOS versions behind strict NATs. Review the genesyscloud_edge_group logs for any rejected candidate attempts.

3

The problem is likely that a mismatch in how iOS 17 handles WebRTC permissions compared to older ticketing systems. Coming from Zendesk, we are used to simple ticket status updates, but Genesys Cloud’s media engine requires explicit browser permissions for microphone and camera access. If these are not granted or if the app is backgrounded, the connection drops silently.

Try checking the genesyscloud_telephony_providers_edges configuration in the admin console. Ensure that the web_rtc_enabled flag is set to true and that the turn_server is correctly configured for mobile devices. Also, verify that the iOS app has the necessary permissions in Settings > Privacy > Microphone.

Here is a snippet of the relevant configuration:

{
 "web_rtc_enabled": true,
 "turn_server": {
 "host": "turn.genesyscloud.com",
 "port": 443
 }
}

Check the official API docs for more details on WebRTC settings.

4

This is caused by…

  • iOS 17 tightening WebRTC background audio permissions, which interrupts the SIP signaling handshake before ringback.
  • Forcing TCP fallback in the genesyscloud_telephony_providers_edges config often bypasses strict UDP filtering on mobile networks.
  • Verify the TURN server allows TCP port 443 to ensure stable media paths during carrier failover.
5

This seems like a classic WebSocket throughput bottleneck masquerading as a media issue. When running JMeter simulations against the Genesys Cloud API, we often see that iOS 17’s stricter background audio policies cause the client to drop the signaling connection before the media path is even established if the initial handshake takes too long. The issue isn’t necessarily the STUN/TURN config, but rather the time it takes for the WebSocket to negotiate the session under load. If your JMeter test is hitting the platform with high concurrency, the API rate limits might be delaying the initial token exchange, causing the iOS client to timeout. Try adding a custom header to your JMeter HTTP Request sampler to simulate a lower priority client, or increase the timeout property in your WebSocket connection setup. Specifically, in your JMeter thread group, set the Connect Timeout to 15000ms and the Response Timeout to 30000ms. This gives the iOS 17 client enough breathing room to complete the permission checks and establish the data channel. Also, check if your genesyscloud_routing_edge_group is configured to prefer TCP for WebSocket connections. iOS 17 often blocks UDP for non-active apps, so forcing TCP can prevent these silent drops. You can verify this by looking at the network trace in Safari’s developer tools on macOS, filtering for WebSocket frames. If you see a 1006 close code, it’s almost certainly a network timeout rather than a permission error. Adjusting the JMeter pacing timer to 500ms between requests might also help reduce the load on the edge servers, allowing faster response times for the signaling messages.