It can’t be something related to Pro accounts, many of our clients have very large Enterprise level accounts with Zoom, maxing out all limits as far as we know. Yet they still experience this error message and it has been damaging their attendee experience significantly.
@xinxin @ryan-sey - The WebSDK can hold up to 1000 attendees if you have the right plan, if you have a Pro account it holds up to 100 participants by default unless you buy a Meeting 500 add-on. Business accounts can hold up to 300 participants by default.
Can you provide the meeting IDs? Also, are the participant count going over the attendee limit?
I think there is a misunderstanding here.
So the use case:
Client A have an enterprise level account ( 1000 attendees / meeting ) and has a meeting let say X
We are using WebSDK JWT App created by our own account ( PRO )
If there are 1000 chrome browser accessing meeting X through our WebSDK JWT app, will the PRO account rate limit apply instead of the client enterprise limit?
@Michael_Purnell Right, but that’s not the case here. Accounts we manage have limits of 500 and 1,000 and still get cut off around the 300 mark. Even more so when they have multiple webinars running under the same account at the same time, but they have multiple host licenses so each one should be able to hold 500 or 1,000. However, the whole system collapses around the 300 mark (in total, across all concurrent webinars) every single time.
Further to that @developer-whova asked an important question. Is the limit enforced based on who owns the webinar, or the JWT credentials? Because we have experienced the same issue in both cases.
Further to this, is it not possible to put a descriptive error message so that we don’t have to guess and go back and forth like this for weeks? The error message does not tell us anything about what the issue is. Thanks.
It depends on the host of the Meeting / Webinar.
Are you using the Web SDK to join the meeting / webinar or host it?
First off, we are releasing better error messages in version 1.7.9, so stay tuned.
It seems like this could be an issue with the Web SDK. I will share this with our Web SDK engineers and get back to you all. (CS-1944)
Then this seems to be an issue on Zoom’s end: the limit does not seem to match the host’s plan, but the Web SDK plan. We do not use the Web SDK to host meetings, but to join the meeting.
From our observations, Zoom is enforcing some limit on the number of concurrent users of the Web SDK, even if those users are attending different meetings, and that the limit seems to sit around 300 users. For example, if 100 users attend meeting A, 100 users attend meeting B and 100 users attend meeting C, this limit will be reached.
It also seems that the limit applies based on the developer’s account plan, not based on the meeting host plan.
For example, the host plan can support 1,000+ attendees per meeting, but the Zoom Web SDK will only allow up to 300 attendees at a time across all meetings. Additionally, once the limit is reached, no meeting can be accessed, even if those hosted by different customers.
One final observation confirming this is that the meetings that could not be joined using the Web SDK while the limit was reached, could be joined using other means (e.g.: App SDK, Zoom Desktop Client, …).
Thanks for the additional info @simon.ninon!
We are looking into the issue and will provide you with updates.
Just to let you know, it seems it happened again today and affected multiple customers (at least 3) between 12:00 PM and 12:15 PM. For this one, I am not 100% sure it is the same issue because by the time our customer support caught it, it was resolved, but the symptoms are all the same (increase of number of users / load of the Web SDK causing join failure on all meetings across different customers).
We were able to reproduce the issue and are working to find the root cause.
Thanks for your patience,
Great, thanks for the update!
You are welcome!
We noticed that the upcoming SDK, 1.7.9, will implement “new rate limit”: https://marketplace.zoom.us/docs/guides/stay-up-to-date/upcoming-changes/web-sdk
Will this address our issue, or is it unrelated? If it does, is it possible to get more information regarding these new limits so that we can better understand what to expect?
The rate limit update is different from your issue. It is related to in meeting functions to prevent users from spam pressing buttons. For example, if someone calls the mute button over 10 time per second. The current rate limit is 5 p/s so we will disable the action.
Hey @tommy , we seem to be experiencing a similar behavior to this as well, so I have been following this thread with curiosity, can you expand upon what the actual issue is that @simon.ninon and his team are facing?
I will update you once we know the root cause and are working on a solution.
We are very near to running an event with 300+ participants through the WebSDK. I’ve just come across this thread and would like to confirm whether this is ongoing or resolved?
If it is ongoing, are there measures we can take to reduce the risk of this issue such as spreading our users across multiple JWT Apps, or using a different version of the SDK?
We have not received any new reports about this issue. I am confirming with engineering to see if this is resolved. In the meantime please let me know if you run into this issue.