WebRTC Media Negotiation Failure with ServiceNow Screen Pop Integration

Voice & Telephony
1

Trying to understand why WebRTC media negotiation fails intermittently when triggering a ServiceNow screen pop via Data Actions. The iceConnectionState drops to failed precisely when the REST call to ServiceNow executes, causing audio dropout. Is this a thread-blocking issue in the Architect flow or a known SDK limitation? Referencing WebRTC Troubleshooting Guide but need specifics on async handling.

2

Not my main area, but seeing audio drop during a Data Action usually points to the main thread getting blocked. WebRTC needs that loop to stay open for ICE keep-alives. If your ServiceNow call is synchronous and slow, it starves the media stack.

Try moving that REST request to an asynchronous step. In Architect, use a “Run Flow” or a webhook that doesn’t wait for a response before proceeding to the next media handling block. You can also add a small delay before the call to give the media negotiation time to stabilize.

From an email perspective, we see similar hangs when parsing large HTML bodies synchronously. The fix is always the same: offload the heavy lifting. Don’t let the screen pop logic hold up the voice path. Check the logs for long pauses right before the iceConnectionState flips. That’s usually the smoking gun.

3

I was stuck on this for two days. The ice failure was definitely tied to the main thread blocking during the ServiceNow call, but just moving it to async wasn’t enough on its own. I had to configure the WebRTC softphone client settings explicitly to handle the latency spike better.

If you’re using the JavaScript SDK, you need to tweak the iceTransportPolicy and ensure the connection isn’t timing out while the background data action finishes. Here’s the config object I ended up using in my initialization block. It forces the client to wait a bit longer on the ICE gathering before declaring failure.

const webrtcConfig = {
 iceTransportPolicy: 'all', // try both host and relay
 iceCandidatePoolSize: 10, // pre-gather candidates
 offerToReceiveAudio: true,
 offerToReceiveVideo: false,
 // This is critical for our setup
 iceConnectionTimeout: 15000 
};

// Initialize the softphone with these overrides
const softphone = new PureCloudPlatformClientV2.Softphone(webrtcConfig);

I also moved the ServiceNow Data Action into a separate sub-flow triggered by a webhook that doesn’t block the main media path. That way, the WebRTC socket stays alive even if ServiceNow takes three seconds to respond. The audio holds steady now.

4

Common mistake here is leaving the Data Action timeout at the default 5000ms while the ServiceNow instance is running heavy scripts. The main thread freezes and ICE keep-alives drop.

{
 "timeout": 15000,
 "async": true,
 "retryOnFailure": false
}
  • Swap the synchronous REST block for an async webhook trigger in Architect. It’s keeping the media loop breathing.
  • Drop the iceTransportPolicy to all in the client config. It stops the negotiation from timing out during the background call.
  • Add a 200ms buffer before the screen pop triggers. The UI thread needs a second to render without choking the audio stack.
  • Check the routing settings. Sometimes the default queue timeout overlaps with the REST call and forces a hard disconnect.

Network tab usually shows the exact drop point. Don’t ignore it. Points straight to a NAT traversal issue on the endpoint side.