Users Rejoin Main Session Instead of Previous Subsession After Network Reconnection

We are facing an issue with Zoom subsessions.

Scenario:

  • A user joins a subsession successfully.

  • The subsession is opened using isAutoJoinSubsession: true.

  • If the user experiences network instability/disconnection, they get disconnected from the meeting after a few seconds or minutes.

  • When the user reconnects to the meeting, they are automatically placed into the main session instead of rejoining their previous subsession.

Expected behavior:
The user should automatically return to the same subsession they were in before the disconnection.

Could you please confirm:

  1. Is this the expected behavior in Zoom?

  2. Is there any configuration or SDK option available to automatically restore users to their previous subsession after reconnecting?

  3. Is this a known limitation or issue with subsessions and reconnections?

This is the status while in the sub session

{
“sessionId”: “N0bXFaPYQimQZyA9m4Gc4Q==”,
“isBreakoutActive”: true,
“roomId”: 1,
“status”: “session-joined”,
“subsessionStatus”: 2,
“teacherRoom”: null,
“unassignedUsers”: ,
“userCountInRoom”: 2,
“userId”: “USTUDENT4”,
“userRole”: “student”,
“userStatus”: “in room”,
“usersInRoom”: [
“USTUDENT4”,
“USTUDENT3”
]
}

if the user refresh the screen
{
“isBreakoutActive”: true,
“roomId”: 1,
“sessionId”: “N0bXFaPYQimQZyA9m4Gc4Q==”,
“status”: “session-joined”,
“subsessionStatus”: 1,
“teacherRoom”: null,
“unassignedUsers”: ,
“userCountInRoom”: 2,
“userId”: “USTUDENT4”,
“userRole”: “student”,
“userStatus”: “initial”,
“usersInRoom”: [
“USTUDENT3”,
“USTUDENT4”
]
}

Please let us know if additional logs or SDK details are required.

Thanks

Hey @puvivinocmv

Thanks for your feedback.

N0bXFaPYQimQZyA9m4Gc4Q==

01:06:56.747 GMT: User USTUDENT4 joined the main session.
01:07:23.449 GMT: User USTUDENT4 was assigned to a subsession.
01:09:30.664 GMT: User USTUDENT4 triggered a failover due to a network issue and attempted to reconnect.
01:09:35.148 GMT: User USTUDENT4 failed to reconnect and received a join meeting failed error.
01:10:11.152 GMT: The developer performed a rejoin operation, meaning the join method was called again after the join meeting failed error in order to rejoin the session. Since this was a rejoin after a join failure, the user was treated as a completely new user, so the previous subsession assignment information no longer applied, and the user was not automatically reassigned to the subsession.

In this case, we recommend using the userKey field on the participant, which is specified externally by the developer. If the value does not change during a retry join, the session host can check this field and manually call the assignUserToSubsession method again to reassign the user to the subsession.

Thanks
Vic

Hi @vic.yang, thank you for sharing this.

I have another question. Our Chrome Origin Trial token is going to expire soon. Once it expires, will SharedArrayBuffer stop working?

If yes, could you please let us know what issues or limitations we may face from the Zoom Video SDK side after the token expiration? Also, please share any relevant documentation regarding this behavior and its impact.

Temporary browser feature flags. Nothing says “stable production architecture” quite like a countdown timer attached to core functionality.

Thanks

Hi @puvivinocmv

what issues or limitations we may face from the Zoom Video SDK side after the token expiration?

Starting from Video SDK Web version 2.1, SharedArrayBuffer is no longer an essential requirement because we introduced a WebRTC-based solution.

If SharedArrayBuffer is not enabled, it will automatically switch to WebRTC audio/video. This does not negatively impact the user experience; in fact, it may provide an even better experience on low-performance devices.

Thanks
Vic