In the past, it was possible for a participant to be the first person to join a meeting and then the host would join shortly afterwards. This no longer seems to be allowed. Now, error code 2003 (Unable to join the Session) is returned.
This happens when the role_type field in the JWT is set to 0 for the guest.
Has this behavior changed on your backend? If so, this will require adding code to the client to prevent a guest from joining until the host has. This is awkward because a mechanism will need to be provided that detects when the host has joined. One solution is to just keep trying to join every few seconds until it succeeds. This doesn’t seem like a nice way of handling things.
If the host is now required to join the meeting first before guests can, you need to update your documentation to indicate this.
Please indicate what solution Zoom suggests in how a guest can know when to join the meeting.
You are correctly understanding that the host needs to start a session before other users can join. This change applies to all SDK versions from 1.2.0 onward. If you need to be notified of when a session begins, you can use the session started webhook.
The link you have provided is for a webhook. There is no sessionStarted callback for Android. The only thing I can find that might be close is the onSessionJoin callback. Is this what you are referring to?
Also, in your latest SDK (1.2.2), the sample code doesn’t indicate what it might be. And the JWT token doesn’t even use the role_type which is required. Please fix your sample code to be up-to-date.
I also consider what the Zoom developers have done is really bad. Had I published my app, it would have crashed due to what appears a change in your backend. Your developers should never do something on their backend that breaks the client. If you need to change the behavior, provide new APIs and deprecate the older ones. Also, in this particular case, your backend could just as well have cached the user joining and then completed the session startuup for them when the host started the session. It makes no sense to return an error code. Returning an error code however is the least of the issues. The biggest issue is that the onSessionLeave callback is called. That’s really bad, because this callback is designed to clean things up after leaving the session. If the user hasn’t joined the session, then you shouldn’t be calling onSessionLeave .
The link you have provided is for a webhook. There is no sessionStarted callback for Android. The only thing I can find that might be close is the onSessionJoin callback. Is this what you are referring to?
The SDK doesn’t maintain a connection to the session unless you’re in the session already, so using a webhook would be the only approach that could let you know when a session starts ahead of time. There is no exact equivalent callback of this webhook.
Also, in your latest SDK (1.2.2), the sample code doesn’t indicate what it might be. And the JWT token doesn’t even use the role_type which is required. Please fix your sample code to be up-to-date.
We will look into updating this in a future release. Thanks for bringing it up!
I also consider what the Zoom developers have done is really bad. Had I published my app, it would have crashed due to what appears a change in your backend. Your developers should never do something on their backend that breaks the client. If you need to change the behavior, provide new APIs and deprecate the older ones. Also, in this particular case, your backend could just as well have cached the user joining and then completed the session startuup for them when the host started the session. It makes no sense to return an error code. Returning an error code however is the least of the issues. The biggest issue is that the onSessionLeave callback is called. That’s really bad, because this callback is designed to clean things up after leaving the session. If the user hasn’t joined the session, then you shouldn’t be calling onSessionLeave .
Thank you for your feedback. I agree that this isn’t the best experience and will bring this up with our product team to see how we can better guard against this sort of thing in the future.
