We use a Cisco Web Security Appliance as an internal web proxy, and a new call-center service needs to make VoIP calls directly in the browser. The signaling and call setup appear to work, but users often connect without hearing any audio. The service documentation says it requires UDP access for STUN and RTP/RTCP. I had assumed this might work like Teams or other meeting platforms, but it seems the proxy may not support the UDP traffic required for the media stream. Should this traffic bypass the proxy, use a different type of gateway, or be configured another way?
5 Answers
A SOCKS5 setup may be able to carry UDP, depending on the appliance and client support, but it is generally an awkward architecture for corporate browser VoIP. This is better handled with firewall rules, NAT, and vendor-supported WebRTC infrastructure than by forcing media through a traditional HTTP web proxy.
The usual solution is not to proxy real-time voice traffic. Create a controlled firewall or proxy bypass for the provider’s documented IP ranges and UDP port ranges, allowing the media stream to go directly out without HTTP proxying or inspection. Get the ranges from the vendor and confirm how they handle future changes.
Also check whether TLS inspection is interfering with the signaling connection. Even after the UDP issue is fixed, inspecting or altering the WebSocket path can cause calls to drop or behave inconsistently. The service provider should document the required bypasses and any domains, ports, and address ranges that need to be excluded from inspection.
If direct UDP access is not permitted, ask the service provider whether they support WebRTC TURN relays over TCP 443. That can provide a fallback through restrictive networks, although voice quality may suffer because real-time audio performs poorly when it has to traverse a reliable, retransmitting transport. It should be treated as a fallback rather than the preferred design.
The browser’s HTTPS or WebSocket signaling can pass through the web proxy, which is why calls may ring and connect. The actual audio is usually RTP over UDP on a separate path, and that traffic may be blocked by the proxy. That produces the classic symptom of a connected call with no sound.
That makes sense—the signaling path is working, but the media path is probably being blocked separately.