Attendee cannot unmute


I wanted to get some clarity about some of the API on the MobileRTCMeetingService class when using custom UI.

As a host, I disable all user audio and prevent users from starting audio (muteAllUserAudio:NO). I then enable all user audio using unmuteAllUserAudio. At this point, should a participant be able to enable audio from their app? Currently an alert displays with the message: You cannot unmute yourself because the host muted all attendees.

Which version?

Smartphone (please complete the following information):

  • Device: iPad Pro
  • OS: iOS 12.4.1

Hi Xiao,

Thanks for the post. I will verify this behavior and get back to you as soon as possible.


Hi Carson,

Were you able to verify this behavior?


Hi Xiao,

Thanks for the reply. When the host unmutes all participants, any participant should be able to mute/unmute themselves. I tried the scenario you described with our demo app but I am not able to reproduce this behavior. The demo app(in Custom UI mode) is using the Zoom’s default participant UI so I will need to further verify this behavior with the non-default participant UI. Could you have a try with our demo app and see if the problem occurs as well?


Hi Carson -

I was not able to start a meeting using the demo application, but I did use the Zoom application. This does not occur. Please do let me know if there is a specific implementation detail for the non-default participant UI that needs to happen.


Hi Xiao,

Thanks for the reply. We are using a similar implementation like the following in our demo:

[meetingService muteAlluserAudio:NO]
[meetingService unmuteAllUserAudio]

This implementation is not done explicitly in our demo app, but the methods that have been called to mute/unmute in the default participant UI is exactly the same as the above methods. I tried to implement the above 2 method in our demo app and try to reproduce this issue, but I am not able to reproduce this.

The message “You cannot unmute yourself because the host muted all attendees” is not implemented in our demo app under Custom UI mode( And it is not handled by SDK as well. (In Zoom default UI, we do handle this message in SDK)

Thus please have a look at our Custom UI implementation in our demo app and hope that can be helpful. If you find out anyway to reproduce the issue you are facing with our demo app, please let me know.


Hi Carson,

Thanks for the information. I did find something interesting in two scenarios:

Scenario 1:

Mute all attendee audio with [meetingService muteAllUserAudio:YES]
Unmute all attendee audio with [meetingService unmuteAllUserAudio]

However in this scenario the attendee can unmute him / herself after the host has muted all attendee audio.

Scenario 2:
Mute all attendee audio with [meetingService muteAllUserAudio:NO]
Unmute all attendee audio with [meetingService muteAllUserAudio:YES] and then [meetingService unmuteAllUserAudio]

In this scenario, the attendee cannot unmute after the host has muted audio. The attendee can mute / unmute after the host has unmuted audio (desired behavior).

It seems like the difference is passing a YES or NO to the muteAllUserAudio method.

Hi Xiao,

Thanks for the reply. Here is the definition of the method muteAllUserAudio(

 @brief Set to mute audio of all attendees.
 @param allowSelfUnmute YES means that attendee can unmute the audio himself, otherwise not.
 @return YES means that the method is called successfully, otherwise not.
 @warning Only meeting host can run the function.
- (BOOL)muteAllUserAudio:(BOOL)allowSelfUnmute;

So the boolean value passes is for allowing the attendee to unmute themselves.

For Scenario 1, since allowSelfUnmute = YES, then the attendee would be allowed to unmute themselves, what you observed is the expected result.
For Scenario 2, since allowSelfUnmute = NO, then the attendee would not be allowed to unmute themselves, when you unmute the attendees, you don’t need to call [meetingService muteAllUserAudio:YES], you can just call the [meetingService unmuteAllUserAudio] method.

Seems like what you have observed for both scenarios are working as expected. Pardon the misleading interface name for the muteAllUserAudio, I think the original confusion was because of the name comes with a boolean name, and it could be misleading to be treated as turning mute all audio on/off.

Hope this helps. Thanks!

Hi Carson,

My apologies for the confusion. For scenario 2, if [meetingService muteAllUserAudio:YES] is not called, the attendee is not able to unmute him or herself. This is the original situation.


Hi Xiao,

Thanks for the info. Mmmm…it is very strange that: without calling the [meetingService muteAllUserAudio:YES] before calling [meetingService unmuteAllUserAudio] in our demo app, the attendee will still be able to mute/unmute themselves afterward. Glad to hear that this workaround works, I have compared the way you are implementing with the way in our demo app and I found no difference. Still not sure why you are facing that issue. We will continue to investigate this issue.