The mic still shows as on even though the device has been blocked

Video SDK Web
1

Description

If I join a room with the microphone blocked at the browser permission level, other participants still see my mic as On.

Environment

  • Browser: Chrome (e.g., 139.0.0.0)

  • OS: Windows 10/11 (confirm)

  • SDK/App: (fill in your meeting SDK/app version)

Expected Result

When a user has blocked microphone permission in the browser, their mic status should appear Off (or “Permission blocked”) to everyone, and no audio track should be published.

Actual Result

Other users see the participant’s mic as On even though microphone permission is blocked.

Steps to Reproduce

  1. User A opens a meeting room.

  2. User B opens the invite link.

  3. In the browser, User B sets site permissions to Block for Microphone (or denies the mic prompt).

  4. User B joins the room.

  5. Observe from User A’s view: User B appears with mic On.

  6. audioStatus of User B from zoom sdk: audioStatus : true

Video SDK Version 2.2.5

2

Hey @tungnguyen020394

Thanks for your feedback.

Could you share some problematic session IDs with us for troubleshooting?

Thanks
Vic

3

@vic.yang

Please help me check with the session IDs: g8J9eeS1SgWzfBn9r0YkBg==

Thanks

Phuong

4

Hi @phuongnv1

g8J9eeS1SgWzfBn9r0YkBg==

We found that Windows Edge (UserID 16778240) passed speakerOnly: true when calling stream.startAudio method. This allows the user to hear other participants’ audio in the session, but the user payload shows that this user has already joined audio—the audio property is set to ‘computer’.

However, we also have another property, isSpeakerOnly, to indicate whether this user is connected only as an audio speaker.

Thanks
Vic

5

I tested this on Zoom as well and saw the same behavior when audioStatus: true. The mic still shows as ON.

URL of meeting: https://us05web.zoom.us/j/88695141296?pwd=xQKYKlugXMLOnk7abbeUq0s88g9USB.1SbL8S4

image
image1920×969 22.9 KB

image
image1919×955 60.1 KB

6

I’ll add more details:

User A (Camera & Mic enabled)
User B (Camera & Mic blocked)
User C (Camera & Mic enabled)

Step 1: A creates the room.

Step 2: B blocks the camera and microphone, then joins the room.

Step 3: B’s audioStatus:

  • On A’s screen: audioStatus: false

Step 4: C joins the room and enables camera and microphone normally.

Step 5: B’s audioStatus:

  • On A’s screen: audioStatus: false

  • On C’s screen: audioStatus: true

session ID: haXdeOIGTWmCeANxn4cFGw==

7

Hi @tungnguyen020394 @phuongnv1

Sorry, I’m not sure what audioStatus refers to, since we don’t provide that property.

From the logs, I can see you used the speakerOnly option, so could you check whether on the other users’ side the value of isSpeakerOnly matches the mic status?

Thanks
Vic

8

@vic.yang

Thank you for your response. After reviewing the logic and the data from your side, I noticed inconsistencies between users who joined before and after the mic permission was disabled.

I’ll provide a clear description of the flow and the data I observed.

Step 1: User 1 joins first.

Step 2: User 2 joins with the mic permission disabled. At this point, User 1 receives User 2’s data as:

{
    audio: "computer",
    isSpeakerOnly: true,
    muted: undefined
}

Step 3: User 3 joins. At this point, User 3 receives User 2’s data as:

{
    audio: "computer",
    isSpeakerOnly: undefined,
    muted: false
}

Could you please help me understand why there’s a difference in the data for the user who disabled the mic permission between users who joined before and after? Because of this, I ended up displaying the wrong mic status for User 2. (session IDs: izNFtPVDTR6BBI+DltYwpQ==)

I look forward to your response.

Thanks

Phuong

9

Hi @phuongnv1

Thank you for sharing the detailed information.

This is indeed an issue, and we will fix it in the upcoming release (2.2.10 - scheduled for the end of August).

Thanks
Vic

1 Like