Hi @codemanas17
Thanks for sharing more details with me.
I was able to run our sample app and reproduce this. behavior.
This is expected. Registered users can not join the practice session, and this is by design. They will only be able to join once the practice session is over
To clarify, we don’t expect registered users to join during the practice session. Instead, our desired behavior is:
When a practice session is in progress, registered users should be placed in the waiting room—not simply blocked by a timeout or given an “unable to join” error.
They should enter the meeting only after the practice session has ended.
Currently, the issue we’re seeing is that as soon as the practice session starts, the meeting “times out,” producing a 3008 “meeting not started” error. That’s acceptable if it happens—but only if the user is queued in the waiting room, rather than flat-out blocked.
What’s interesting is that joining via the Zoom link (e.g., in browser instead of the app) does place users in the waiting room, which is exactly the behavior we’d like to replicate via the Web SDK.
So, to summarize:
Scenario A (via join link or browser): registered user → waiting room → allowed to join after practice session.
Scenario B (via Web SDK): practice session starts → error 3008 → user blocked entirely.
We’d like Scenario B to behave like Scenario A: have users held in the waiting room and only admitted once the practice session ends.
Let me know if there’s any more information that would help clarify this behavior or assist development.
