WebRTC SDP negotiation failure with custom ServiceNow screen pop integration

Struggling to figure out why the WebRTC handshake consistently fails when triggering a screen pop via a custom Data Action in our Genesys Cloud Architect flow. The integration works fine for standard CTI, but as soon as we inject the ServiceNow REST API call to fetch the incident payload, the softphone client throws a 408 Request Timeout followed by a WebRTC connection failed error in the browser console.

We are using the latest Genesys Cloud SDK (v2.14.0) and the ServiceNow integration is configured with a dedicated service account. The Architect flow uses a ‘Set Variable’ block to capture the conversation UUID, then triggers a Data Action to POST to https://instance.service-now.com/api/now/table/incident. The response time is under 200ms, so latency shouldn’t be the issue. However, the SDP offer seems to be dropped or malformed immediately after the Data Action completes.

Here is the JSON payload we are sending to ServiceNow:

{
 "number": "INC${GENESYS_CONVERSATION_ID}",
 "caller_id": {
 "link": "/api/now/table/sys_user/${CALLER_ID}"
 },
 "short_description": "Voice interaction from Genesys Cloud",
 "state": 1
}

The error logs show ICE candidate gathering failed. Is there a known conflict between the WebRTC signaling thread and synchronous Data Action execution in Architect? We have tried adding a delay block, but the issue persists. Any insights on how to decouple these processes would be appreciated.

The simplest way to resolve this is to decouple the ServiceNow API call from the WebRTC media path. The 408 Request Timeout suggests the Architect flow is stalling on the REST response before signaling completes. WebRTC negotiation is sensitive to latency spikes.

Try moving the ServiceNow fetch to a background thread or using a Data Action that returns immediately while fetching data asynchronously. In JMeter load tests, we see similar SDP failures when external API calls block the main execution thread.

Check if the REST action is configured with a timeout. If it hangs, the WebSocket session might drop. Also, verify that the ServiceNow integration isn’t triggering multiple concurrent requests per call. High concurrency can exhaust the API rate limits, causing the SDP exchange to fail. Consider caching incident data to reduce latency.