Computer Audio Connection Issues on Web

[sam9 (Sam)]

Description
Zoom session id: sY1rzUQiTRGgm9VHkllDQA==

Experiencing at least 6 out of 43 participants with being unable to connect to audio.

• Alex Luka
• Angelyn Nguyễn
• Anuja Deodat
• Kathryn Wilson
• Kadia Nelson
• John Vincent Quaicoe

Browser Console Error
The full error message or issue you are running into.

Which Web Video SDK version?
@zoom/videosdk 2.2.0

Device :

• Device: Windows PC’s
• Browser: Chrome and Edge
• Browser Version 137

Additional context

• this has been an ongoing issue for me since I integrated zoom video sdk about a year ago…

[vic.yang (Vic)]

Hey @sam9

Thanks for your feedback.

Sorry for the poor experience.

Around 10 users encountered transmission issues with the WebRTC server due to their network conditions. After a few retries without success, the Video SDK falls back to the WASM audio solution, then starts audio successfully.

We are continuously working to improve the user experience under challenging network conditions.

Thanks
Vic

[sam9 (Sam)]

Thanks for the quick response.

A couple follow up questions:

1. Can you tell what the specfic network condition(s) was that caused the issue so we can potentially reach out to their IT team?
2. When the VideoSdk “falls back to the WASM audio solution, then starts audio successfully.” is there anything I can do to handle that transition? Right now those 10 people just spiral out on a loading indicator and I tell them to dial in…

To help answer my second question below are some snippets from my code:

public async startAudio(
        initalMute: boolean = true,
        speakerOnly: boolean = false
    ): Promise<void> {
        const { videoStream } = this.getStateSnapshot();
        const { currentUser } = this.authFacade.getStateSnapshot();
        const { canToggleMute } = this.sessionMetaFacade.getStateSnapshot();
        try {
            let audioOpts: AudioOption = {
                mute: initalMute,
                speakerOnly: speakerOnly
            };
            let speakerToUpdate = null;
            await videoStream.startAudio(audioOpts);
            setTimeout(() => {
                speakerToUpdate = this.getInitialSpeaker();
                if (speakerToUpdate) {
                    videoStream.switchSpeaker(speakerToUpdate.deviceId);
                }
            }, 2000);

            if (currentUser.acl >= eAcl.SESSION_LEADER || canToggleMute) {
                this.toggleBackgroundNoiseSuppression(true);
            }
        } catch (e) {
            console.log("Error starting audio", e);
            this.handleStartAudioError(e, initalMute);
        }
    }

private handleStartAudioError(e: any, showInstructions: boolean): void {
        if (e) {
            const imgInstructions = this.getMicPermissionInstructions();
            let html = "<div>Microphone access not required please use an option below.</div>";

            if (showInstructions) {
                html += imgInstructions;
            }

            this.appFacade.updateConfirmModalItem({
                title: "No Microphone Access",
                html: "Microphone access not required please use an option below.",
                showCancel: true,
                primaryText: "Join as Listen Only",
                secondaryText: "Join by Phone",
                showTertiaryBtn: true,
                tertiaryBtnText: "Retry Mic",
                closeCallbackFn: (lastAction: tModalLastAction) => {
                    if (!lastAction) {
                        this.startAudio(true, true);
                    }
                },
                tertiaryActionCallbackFn: () => {
                    setTimeout(() => {
                        this.onMicRetry();
                    }, 500);
                },
                secondaryActionCallbackFn: () => {
                    this.showPhoneInstructions();
                },
                confirmCallbackFn: () => {
                    this.startAudio(true, true);
                }
            });
        }
    }

[vic.yang (Vic)]

Hi @sam9

1. Can you tell what the specfic network condition(s) was that caused the issue so we can potentially reach out to their IT team?

We found that the MTU size of DTLS received by the WebRTC server was incorrect, which resulted in issues like handshake failures, decryption errors, or incomplete data.

This typically occurs in specific network environments such as VPNs or campus networks, where there are MTU restrictions or interference. These networks may fragment or drop DTLS packets during transmission, leading to such issues.

is there anything I can do to handle that transition? Right now those 10 people just spiral out on a loading indicator and I tell them to dial in…

Currently, fallback will trigger a session reconnecting process. By listening to the connection-change event, users will be notified that they are reconnecting, which makes the fallback process visible to them. We will optimize this reconnection flow in the next version.

Thanks
Vic

[sam9 (Sam)]

Hi @vic.yang,

Thank you for your help so far. Unfortunately, we’re still experiencing complete audio failure for our KPMG users - they cannot hear anything at all, which suggests the WASM fallback isn’t working as expected.

Could you help us with:

1. Specific network requirements for BOTH WebRTC and WASM? Could you help clarify the requirements for each method? I assume they’re different:

• WebRTC: Usually needs UDP 8801-8810, STUN/TURN servers, etc.
• WASM fallback: Does this use different ports/protocols (TCP only? WebSocket?)

If we could get exact requirements for both, I can work with KPMG IT to ensure everything is properly configured.

2. How to detect when WASM has also failed? Is there an event or error code that would tell us “all audio methods exhausted”? This would help us guide users to phone dial-in faster.

3. Understanding the root cause: What network configurations would block BOTH WebRTC and WASM? This would help us explain the issue to IT more effectively.

[vic.yang (Vic)]

Hi @sam9

Specific network requirements for BOTH WebRTC and WASM?

WebRTC : We first attempt to use RTC datachannels over ports 8801–8810. If those ports are blocked, we fall back to a TURN server, which typically uses the standard port 443. However, in some network environments—especially VPNs—WebRTC transport over DTLS may encounter MTU issues where packets are truncated. This prevents them from being properly parsed, potentially resulting in unavailable WebRTC audio or video.

WASM fallback: No network limitation.

How to detect when WASM has also failed?

You only need to check whether the user’s final audio type is still ‘computer’. Or, more intuitively, listen for the audio-statistic-data-change event to see if there is any send or receive data.

3. Understanding the root cause:

I explained the details in the first question.

Thanks
Vic