I'm troubleshooting a cloud contact-center softphone running in Chrome on Windows laptops used from home. Traffic passes through a cloud security proxy/SSE service and a corporate VPN configured for split tunneling. Calls may connect successfully but then lose audio or drop entirely, especially when the VPN is active. Wired users seem stable, while remote Wi-Fi users are affected more often. I'm trying to determine whether the proxy, VPN, or their interaction is responsible. For people who have fixed similar issues: what proxy exclusions or VPN split-tunnel routes are normally needed for WebRTC signaling, media, STUN, and TURN traffic? Are SSL inspection, Chrome WebRTC behavior, UDP handling, or VPN MTU common problems? What diagnostics—such as chrome://webrtc-internals, packet captures, or vendor path metrics—best prove the root cause?
3 Answers
Check DNS policy as well as routing. With split tunneling, an NRPT or equivalent endpoint policy can ensure the softphone names resolve through the intended DNS servers and that the resulting addresses use the correct route. If possible, keep the voice media path off the VPN instead of sending it through the corporate tunnel, while still allowing any required signaling or security-service traffic through the approved path.
Start by looking at the UDP media path rather than just the application domains. Exclude the softphone’s signaling domains from SSL inspection, then route the vendor’s documented media, STUN, and TURN hosts and UDP port ranges appropriately. It’s possible for signaling to remain healthy while the audio path fails. In Chrome’s WebRTC diagnostics, check the selected candidate pair, whether the call falls back from server-reflexive or relay UDP to TCP, and watch packet loss, jitter, and round-trip time when the call degrades. MTU is worth testing, but SSL inspection and forced TCP relay are frequent causes.
Look at firewall protections that may allow a call to start but terminate or degrade later. UDP flood prevention, connection-aging rules, and stateful inspection can interfere with long-lived WebRTC media flows without producing an obvious block at call setup. Compare a failing Wi-Fi/VPN session with a stable wired session and capture both sides if possible. That can reveal whether packets stop leaving the client, are dropped by the firewall, or disappear farther upstream.
Thanks—our next checks will include UDP flood-prevention settings and other firewall policies that could affect an established call.