MacOS client fails to join after "waiting for host to start the meeting"

Hello

using the current version of the SDK (including in the demo app) I have noticed that if the SDK user joins a call before the host then they get the “waiting for host to start the meeting” message as expected, however they are not automatically let into the meeting when the host starts it, instead the user has to cancel and re-attempt joining.

I assume that we should be re-trying or similar, can you confirm whether there is any kind of notification that the user can join, or should we just be re-attempting to join every few seconds?

Thanks

Richard

Hi @richard1, thanks for the post.

I have also noticed some unexpected behavior related to waiting rooms with this release, including the one you have noted here. Rest assured, we will investigate and fix this in a future release. In the meantime, please don’t hesitate to reach out if you find any other unexpected behavior. :slightly_smiling_face:

Thanks!

Thanks - although this isn’t a waiting room issue, I haven’t done much testing with waiting rooms

Hi @richard1,

I’m inclined to agree that this isn’t an issue with the waiting room. I am able to observe this behavior when joining a meeting that has waiting room disabled and allows joining before the host. There is probably an issue with the underlying logic responsible for the decision of whether or not to show the waiting room when joining a meeting. Regardless, I’ll definitely let you know as soon as we have identified a fix for this!

Thanks!

Hi @richard1,

I was checking this behavior on the latest release of the SDK and noticed that the settings for the meeting I was trying to join had apparently changed. After enabling the Allow participants to join anytime setting, it is working as expected. Can you please verify whether or not you are still experiencing this behavior after enabling that setting?

Thanks!

Thanks Jon - I will have a look however that won’t solve the main issue as we can’t insist on our users having a setting such as that set, I believe that the issue is that we need to be refreshing the request, so possibly we need to add a timer to do this although for other cases this isn’t necessary.

Hi @richard1,

That sounds like a viable workaround!

In the meantime, we will continue to investigate this. I absolutely agree that requiring users to update their meeting settings is not going to be a great solution. As always, I will be sure to let you know when we have any updates.

Thanks!