Description
Since the change to the api requiring either password or waiting room authentication described in this article, an anonymous user joining a meeting via the android SDK gets stuck at the “waiting for host” stage when they are the first to join the meeting. This is despite the fact that “allow joining before host” is set to true on both the account and user level.
We have previously seen this behavior reported infrequently, but were never able to reproduce on our end. The more times we see this reported, the closer we will get to identifying a solution. In order to best assist you, can you please provide the following information:
The full URL you used to create the meeting (with any private information redacted)
A code snippet from your app showing how you are interacting with the SDK to join the meeting
Which gives me a meeting id of 94030418784 and a password, presumably which is a hashed version of SOME_PASSWORD in the form of TmRBN0tkWnJOZnJKRTFnWk9lbVNXUT09 ( not the actual password)
So then I would pass in meetingId 94030418784 and password TmRBN0tkWnJOZnJKRTFnWk9lbVNXUT09 into the following function in the snippet below. I get notified that the meeting is in status “connecting” and then “waiting for host”.
Code snippet: Android SDK -
override fun joinMeeting(
meetingNumber: String,
meetingPassword: String?,
displayName: String?
) {
Timber.d("Calling in thread ${Thread.currentThread().name}")
val name = displayName ?: preferences.getString(Constants.KEY_NAME, defaultName)
val opts = JoinMeetingOptions().apply {
no_driving_mode = true
no_invite = true
}
val params = JoinMeetingParams()
params.meetingNo = meetingNumber
params.password = meetingPassword
params.displayName = name
val handler = Handler(context.mainLooper)
handler.post {
meetingService.joinMeetingWithParams(context, params, opts)
}
.... other code
}
I can reproduce this 100% of the time. Last week before the change in the article I posted we did not use password authentication, or waiting room. I used the same android code as I posted above, just passed null in to the password parameter, and it worked fine. I noticed that after the 27th September change, our meetings seemed to have defaulted to waiting room, which does not suit us. So I amended the body content of the api call to ask for password authentication and explicitly set waiting room false and join before host true ( just to be sure, although those are now our account defaults).
Hi @a.diament, thanks for the detailed instructions!
After a half dozen attempts, I still have had no luck in reproducing this. What is especially strange about the behavior you are seeing is that "type": 1 indicates that this is an instant meeting, which should never be impacted by the join before host setting when it is created.
Can you please verify the following fields’ values in your response JSON when creating the meeting?
type = 1
status = waiting
join_before_host (inside “settings” object) true
A couple more things I have noticed:
I get the same behaviour described whether I use the encrypted or unencrypted password from the zoom response as the password in the android sdk. On the other hand if I use a random, wrong password, I do get the expected behaviour i.e. zoom notifies me the password is wrong inside the zoom sdk, so I don’t think it’s a password problem per se.
Although I specify “password” in my body request e.g. 123456, the zoom response contains a different password comprised of 6 numbers e.g 270179 - this isn’t a big problem for me, but is a bit confusing given that the api documentation says you can set a custom password.
Update @jon.zoom! If I change meeting type to 2 i.e. scheduled, I can join successfully! This is an ok workaround for now (much better than not being able to make calls anyway!) Please could you let me know when there is any progress with the instant meeting fix?
Hi @a.diament, glad to hear it works when creating a normal scheduled meeting!
I get the same behaviour described whether I use the encrypted or unencrypted password from the zoom response as the password in the android sdk
This is expected behavior. The SDK accepts the password in both formats. This confirms that something is happening after you have successfully joined the meeting.
Although I specify “password” in my body request e.g. 123456, the zoom response contains a different password comprised of 6 numbers e.g 270179
This is because it is an instant meeting. For instant meetings, the password and meeting number are either going to be server-generated or use the PMI of the authenticated user.
Please could you let me know when there is any progress with the instant meeting fix?
It looks like we actually will be including a fix for something similar to what you’re describing in the our next SDK release. I’m not 100% certain that this will resolve what you’re seeing since I was unable to reproduce, but keep an eye on our release notes in the coming weeks for the new version so that you can test it out. If the new version does not address your issue, let me know so that we can investigate further.
This is expected behavior when you have not enabled the join before host setting for a given meeting. When this is enabled, you must either login through the SDK as the host or provide the ZAK of the host’s account. Alternatively, you may also enable join before host.