WebRTC Softphone STUN Binding Failing During ServiceNow Screen Pop Initiation

Voice & Telephony
1

What is the reason this setting causes the Genesys WebRTC softphone to drop the STUN binding request precisely when the ServiceNow Data Action is invoked for screen pop? The tenant is configured in EU1, and we are using the latest Architect flow version to trigger a REST API call to ServiceNow upon conversation:start. The softphone client (v10.3.1) successfully registers via SIP but fails to establish the media path when the webhook payload includes specific custom attributes for the ticket ID. The error log on the client side shows ICE candidate gathering failed with a 403 Forbidden response from the STUN server, which seems anomalous since standard calls work fine. This suggests the webhook processing overhead or a specific header injection in the Data Action is interfering with the WebRTC signaling handshake. We have verified that the MID server latency is under 200ms, ruling out timeout issues. The flow validation passes without errors, yet the runtime behavior indicates a conflict between the webhook execution context and the media session establishment.

  • Verified that the ServiceNow integration token has all necessary scopes for WebRTC:Manage and Conversation:View, and regenerated the token to rule out expiration issues.
  • Tested the same Architect flow with a simplified webhook payload excluding the ticket ID and custom attributes, which resulted in successful STUN binding and media establishment, pointing to payload size or structure as the potential culprit.
2

TL;DR: Check for rate limits on the outbound API call.

It depends, but generally… high API throughput can block WebSocket signaling. Try adding a 200ms delay in your JMeter script before the ServiceNow call. If the STUN binding resumes, the platform is throttling the event loop due to concurrent request volume.

3

This is actually a known issue…

The ServiceNow webhook likely blocks the main thread. Wrap the REST action in an asynchronous sub-flow. This decouples the screen pop trigger from the media path establishment.

resource "genesyscloud_flow" "async_sn" {
 trigger = "conversation:start"
 # Use async REST to prevent STUN timeout
}

Verify the flow execution order in the debug logs.