Overview

The first WebRTC call in Sprinklr might fail when using Google Chrome or Microsoft Edge on Windows 11. This failure occurs only on the first call after the machine is rebooted. The behavior has also been observed on other WebRTC‑based applications (such as Google Meet), which confirms that this is not specific to Sprinklr.

​

After the initial failure, all subsequent calls typically succeed without any issues.

​

This issue does not occur in Firefox on the same machine.

​

This article is intended for contact center supervisors, IT administrators, and troubleshooting teams who need to diagnose or validate the problem.

​

To track the ongoing updates in the Chromium, refer to this Chromium issue page.

​

Why This Happens

When a WebRTC call starts, both endpoints must perform connectivity checks using STUN (Session Traversal Utilities for NAT). Chrome and Edge complete this step by creating UDP sockets and exchanging STUN packets.

​

On some Windows 11 systems, after a reboot:

• Chrome/Edge attempts to create the necessary UDP sockets

• These attempts fail at the browser–operating system interface

• The browser eventually closes the socket

• As a result, the first STUN response is never received

• The first call fails

• Later call attempts succeed because the UDP socket creation works correctly

This indicates that the issue is rooted in how Chromium handles specific network‑layer errors returned by Windows.

​

How to Confirm the Issue

Follow these steps to validate whether your environment is affected:

1. Reboot the machine and launch Chrome.

2. Capture browser NetLogs. Refer to the steps outlined in Capturing Net-Internals Network Logs in Chrome or Edge.

3. Capture network traffic using Wireshark. Refer to the steps outlined in Capture and Analyse Voice Network Traffic Using Wireshark.

4. Initiate a WebRTC call in Sprinklr.

5. Stop both captures (NetLog and PCAP).

​

What to Look For

1. Check the PCAP File

Filter for outbound STUN packets sent to your provider’s servers. Identify the timestamp of the first STUN request.

​

​

2. Check the NetLog

Look for UDP_SOCKET events around the same time.

​

​

Based on observed behavior, you may see:

• Repeated attempts by Chrome to send STUN requests over the created ephemeral UDP socket

• Chrome runs into errors repeatedly and eventually closing the port.

• The STUN response may arrive after the socket has been closed, for which there is no listener now

​

This alignment of events confirms the issue.

​

Possible Causes and Recommended Fixes

​

1. Recommended Fix

This issue is resolved in Chrome and Edge latest releases. Upgrade to::

• Microsoft Edge 147.0.3912.72 or higher

• Google Chrome 147.0.7727.102 or higher

​

2. Local Antivirus or Intrusion Prevention System (IPS)

Some antivirus or IPS products may interfere with early UDP socket creation immediately after a system reboot.

To validate this:

1. Temporarily disable:

   • Firewall

   • Antivirus

   • IPS

2. Reproduce the call flow after restarting the machine.

​

If the issue no longer occurs - Your security software is likely inspecting or blocking initial UDP traffic.

​

Recommended action: Configure the security software to exclude Sprinklr traffic from real‑time inspection.

​

Summary

​