MeetingService.handZoomWebUrl() does not work unless user is logged in

On version v4.6.15801.0403 of the SDK and using a custom UI.

Users can join meetings using a meeting number and that works fine regardless if they are logged in or not.

However, if the user joins via a meeting URL, MeetingService.handZoomWebUrl(), the behavior is different depending on if they are logged in. If logged in, everything works fine. If they are not logged in, the MeetingService will transition from IDLE to CONNECTING and then just stay in that state. If the host has not started the meeting, the MeetingService will transition to WAITINGFORHOST. When the host finally starts the meeting, the MeetingService just stays in WAITINGFORHOST.

I tried a meeting with no password, a meeting with a password and a meeting with an embedded password in the URL. Same result. Although, when you try to join via a URL and the password is not embedded in the URL, the SDK is properly notifying that a password is required. But after entering the password, the MeetingService remains in a CONNECTING state.

For now I’ve worked around this by requiring users to be logged in before they can use this feature. But it is not ideal and this seems like a bug with the SDK.

Hi vuzix_greg,

Thanks for the post. If you are getting WAITINGFORHOST then it means the interface is working, there is around 1 min wait for the status WAITINGFORHOST. If a user is not logged-in so it is not authenticated, it will enter the waiting room and wait for the host to start. You could try the same process with a meeting that has enabled “Join before host”.

Hope this helps. Thanks!

@Carson_Chen, thanks for the reply.

I ran some more tests today.

With a meeting already started and host present, I attempted to join the meeting using MeetingService.handZoomWebUrl() from an app that is not logged in. The MeetingService transitioned from IDLE to CONNECTING. I waiting for 5 minutes and the SDK stayed in a CONNECTING state. There was no indication on the host side that anyone else had joined the meeting.

With a meeting that was not started, I attempted to join the meeting using MeetingService.handZoomWebUrl() from an app that is not logged in. The MeetingService transitioned from IDLE to CONNECTING to WAITINGFORHOST. At that point the host started the meeting. I waited for 5 minutes and the SDK stayed in a WAITINGFORHOST state. There was no indication on the host side that anyone was attempting the join the meeting.

I ran both of the above tests again while being logged in and in both cases the MeetingService transitioned to INMEETING within seconds.

I ran both tests from the desktop Zoom app to check if a non-logged in user can still join meetings and the desktop app did not have a problem with either case.

Based on my latest tests, I still feel like there is an issue with the Android SDK and the handZoomWebUrl() method when not logged in.

Hi @vuzix_greg,

Thanks for the reply and for sharing your findings. Does the meeting you are trying to join have a password? If you are trying to join a meeting that requires a password or if you did not setup the display name, the join meeting request will be detoured to the callback onMeetingNeedPasswordOrDisplayName . Could you have a try using the handZoomWebUrl() interface with Zoom default UI and see if you are experiencing the same?

We have tried to reproduce this on our end but no luck. Or would you mind providing a sample URL that has this issue so that we could reproduce it and investigate further? If it is possible, you could send a private message to me.

Thanks!

1 Like

@Carson_Chen, thank you very much for the reply, it really helped me figure out what was going on and it was all related to a missing display name.

Normally when I join a meeting I specify the display name via JoinMeetingParams. However handZoomWebUrl() does not allow JoinMeetingParams. When onMeetingNeedPasswordOrDisplayName() was getting called, I was only reacting to it if needPassword was true. In the case of a meeting URL with an embedded pwd parameter, onMeetingNeedPasswordOrDisplayName() was getting called with needPassword=false and needDisplayName=true and I was ignoring it. I fixed this and now the MeetingService is transitioning to INMEETING.

However, there is one small problem I’m still seeing. If the meeting is not started, the MeetingService transitions to WAITINGFORHOST, as it should. When the host starts the meeting, the MeetingService won’t always transition to INMEETING. It depends on the format of the URL. Here were my test cases:

These are all with non-login users and a custom UI.

Meeting already started, handZoomWebUrl() works perfectly every time regardless of URL format or password protection.

Password protected meeting not started, handZoomWebUrl(“https://zoom.us/j/XXXXXXXXXX”) will call back to onMeetingNeedPasswordOrDisplayName() and after user enters a correct password MeetingService goes to WAITINGFORHOST. Host starts meeting, MeetingServcie goes to INMEETING every time.

Password protected meeting not started, handZoomWebUrl(“https://zoom.us/j/XXXXXXXXXX?pwd=ZZZZZZZZZZZZ”), MeetingService goes to WAITINGFORHOST. Host starts meeting, MeetingService usually stays in WAITINGFORHOST forever but I have seen it go to INMEETING occasionally. Rough testing shows a 1 in 5 chance that it works correctly. I wait for several minutes each time I test. When it does work, the transition to INMEETING is usually with seconds.

Non-password protected meeting not started, handZoomWebUrl(“https://zoom.us/j/XXXXXXXXXX”), MeetingService goes to WAITINGFORHOST. Host starts meeting, MeetingService remains stuck in WAITINGFORHOST. Just like above, will occasionally work correctly about 1 in 5 tries.

Hi vuzix_greg,

Thanks for the detailed reply and sharing the info. Yes, the interface handZoomWebUrl() only handles web URL and it does not accept or work with other objects.

For the small problem you are mentioning, let me forward it to the engineering team to verify and to do investigation and get back to you.

Thanks! :slight_smile: