Description
We’re experiencing an issue where some users (specifically when using VPN’s or from clients on university campus, but also occasionally elsewhere) intermittently see only a white screen for the video feeds when joining sessions using the Zoom Video SDK in our web application. When this happens, neither video nor audio connects for those users, while others in the same session have no issues.
This problem seems to occur more frequently specific networks, and sometimes when users are on VPNs. We’ve checked browser console and network logs, and often see repeated fetch errors or aborted requests to Zoom media endpoints (e.g., rwcam.am.zoom.us). There are no obvious JavaScript errors or failed API calls otherwise.
A few details:
The same users and devices have previously connected successfully from the same location when we were using Zoom sdk v1.x, since updating to v2.x we now see this issue.
The issue is intermittent: sometimes the connection works, sometimes it does not.
We have not changed our implementation logic, but are using a recent version of the Zoom Video SDK.
The problem seems more likely on restrictive networks/firewall (university, VPN, etc.).
Could this be related to firewall or network restrictions? Are there known issues or best practices for ensuring reliable audio/video connections with the Zoom Video SDK in environments with strict network controls? Are there additional diagnostics or configuration steps we should try to help users avoid the white screen issue?
Any insight or documentation links would be greatly appreciated!
Browser Console Error
Fetch error GET https://rwcam.am.zoom.us/wc/ping/92276084402?ts=1747937462787&auth=MxNsrh_U9JE-N4on5CsPWbkhBbjpkA1wlBv0AivdFrU&rwcToken=uQOiCcEO8GKzSxcP7itJ0EyGm3hRJohUH7ExLLWvO5c&dmz=1&option=1
AbortError: signal is aborted without reason
https://app.kiratalent.com/n/static/js/9742.e3dbf88f.chunk.js at line 1:284858
https://app.kiratalent.com/n/static/js/9742.e3dbf88f.chunk.js at line 1:287043
<anonymous>
Fetch error GET https://rwcsjc2.sjc.zoom.us/wc/ping/98012756417?ts=1747852425531&auth=VSF_K5JinlEB7oGyq5iMxhlZqSxh-BBHqn21MrXc6bw&rwcToken=IKwiFoOXqZjcrVaeMR0P1465jeS1DSquryNSW3VwBzw&dmz=1&option=1
AbortError: signal is aborted without reason
https://app.kiratalent.com/n/static/js/9742.e3dbf88f.chunk.js at line 1:284858
https://app.kiratalent.com/n/static/js/9742.e3dbf88f.chunk.js at line 1:287043
<anonymous>
hi @declan1
do these people have access to the standard zoom app?
there is good data in the statistics tabon settings and at the bottom you can run a test meeting. there is a tab there to see the video perfoirmanec,
if there is a network restiction/bottleneck, i would expect the zoom app to see the same issues.
all the best
Thanks for getting back to me and for the suggestion! Just to clarify—our participants were actually using Zoom in between testing our app, and they didn’t have any issues with their devices when using the native app.
Sorry to hear you’re facing this issue. Can you please DM me some sessionIDs where you have noticed this issue? It’ll help us check our logs and find out what the error could’ve been.
This is indeed related to network conditions. In the user’s network environment, we are unable to connect to the WebRTC server. In such cases, we will fall back to the WASM video solution, but this currently takes 2–3 minutes to complete. We will optimize this process in the next release.
For now, a workaround is not setting the video_webrtc_mode field in the JWT, and letting Zoom determine whether to use WebRTC video or not.
Thanks for the response. I’ll proceed without setting video_web_rtc in the JWT for now.
Given that this issue only appears on certain campus networks, could this be related to firewall restrictions preventing WebRTC connections? In those cases, it seems like the Zoom SDK defaults to the WASM fallback.
Is there a recommended way to ensure that clients can establish WebRTC connections in these restricted environments, so we can avoid falling back to WASM? Also, is there any handling we can implement on the client side to detect or work around this?
Is there a recommended way to ensure that clients can establish WebRTC connections in these restricted environments, so we can avoid falling back to WASM?
Your previous approach of setting video_webrtc_mode: 1 in the JWT is correct. We’re still working on improving the connectivity with the WebRTC server under such network conditions.
is there any handling we can implement on the client side to detect or work around this?
We have a library called @zoom/probesdk that can help you diagnose hardware and network issues before joining a session.
One thing I noticed while implementing your suggestion to leave audio_webrtc_mode and video_webrtc_mode unset in the JWT. When rendering the video-player components, it seems that—even when WebRTC is available and detected by Zoom—the shadow DOM consistently creates a <canvas> element in the shadow-root rather than a native <video> element within the video-player.
The issue with this approach is that styling becomes quite limited. Since it’s a canvas, we can’t apply standard CSS properties like border-radius, filters, or overlays that would otherwise work on a video element.
Is this the expected behavior? Does the Zoom SDK always render video via <canvas>, regardless of WebRTC availability? Just trying to understand if this is a fixed rendering strategy or if there’s a way to opt into the video rendering without explicitly setting the default video_webrtc_mode to 1.
Is this the expected behavior? Does the Zoom SDK always render video via <canvas> , regardless of WebRTC availability?
It’s an expected behavior. In WebRTC mode, the canvas inside the shadow DOM is not used for video rendering. It is created merely as a placeholder for compatibility with the WASM video implementation.
By the way, we now support adding border-radius to the video-player element in the latest Video SDK Web. It works for both WASM and WebRTC video.
@vic.yang Thanks for the reply, which version would this be? We are currently using v2.1.10 and it is not the case. We have the border-radius set on the video-player and still getting squared corners.
