Join & Rejoin¶
Purpose¶
Join/Rejoin lets a user return to an existing call without exposing the active call session key to the backend. An active participant must approve and encrypt the current key for the returning device.
Manual Rejoin Flow¶
User taps Join/Rejoin from call history
-> app asks backend to request rejoin
-> backend notifies active participants
-> an active participant verifies the requester
-> active participant encrypts the current session key for the requester
-> requester receives encrypted key
-> requester decrypts locally
-> requester rejoins the room
LiveKit Reconnect Flow¶
LiveKit reconnect is different from manual rejoin. It happens when the media room connection drops and recovers while the call is still active.
Media reconnect completes
-> app refreshes participant state
-> if user is still joined: sync UI
-> if user was kicked/out-of-sync: try media recovery with stored room token and current session key
Key Rules¶
- The active session key is only shared after requester verification.
- The backend relays rejoin messages but should not receive the raw key.
- Manual rejoin requires another active participant to respond.
- Media reconnect can recover locally when enough session state is still available.
User Experience¶
| Situation | Expected behavior |
|---|---|
| Rejoin request accepted | User reconnects to the existing encrypted room. |
| No active participant responds | Rejoin remains pending or fails gracefully. |
| Requester key cannot be verified | Rejoin key sharing is blocked. |
| Media reconnect succeeds | UI refreshes without requiring a manual rejoin. |
| Media reconnect detects invalid local state | App attempts controlled recovery or ends the call. |