This message was deleted.

Thank you for the kind words @able-lunch-10309 There are a couple of ways this can happen. 1. With open source server, client SDKs will auto-reconnect if there is a connection breakage. So, clients could move to a different node. The reconnection could be a few seconds. Could be up to 10 - 15 seconds some times. Could be quicker, but the interruption is noticeable. 2. With LiveKit Cloud offering, a room is mult-homed, i. e. same room can exist on multiple media servers. Every participant connects to the closest region and servers exchange media as needed. With this, two things happen a. Not all users will be affected if a server goes down (of course, if your users are all in one region, they will end up on one node and the multi-homing does not take effect). b. Participants are "migrated" as seamlessly as possible to a different media node. This could be under a second. Again, the worst case could be it requires a full reconnect like the OSS case, but migration works most of the time. Client could take a few seconds to realise that it has to migrate to a new node, but the migration itself is quick.

Thank you for your quick response @fancy-wire-61616 But what happens if the service goes down (for example for maintenance) and up again? Will the room list be empty? This would require our backend to sync with LiveKit to make sure that there are no more rooms and they need to be newly created by an admin.

A qualified yes is the answer. When clients detect that the connection is gone and initiate a resume/reconnect, the room will get created on a new server as needed. To elaborate, in LiveKit cloud case, it is possible that a room is running on two servers. When server 1 goes down, clients connected to Server 1 for that room could end up migrating to Server 2. Server 2 already has that room and does not need to re-created. But, if the migration happens to a new server, the room will get created there. In OSS case, as all participants are on same server and there is no migration, room will get re-created on a new server. Clients behave exactly the same, i. e. they detect a disconnect and issue a resume/reconnect request. In the LiveKit cloud case, we can figure out a server to migrate to. In OSS, that room needs to be allocate on a new server. I said "qualified yes" because it is possible that some client is not able to reconnect for whatever reason. So, if you look at participants list before and after, there may be differences. But, in most cases clients will reconnect (to the same room with the same participant identity) and carry on. LiveKit systems work on

room name

and

participant identity

. These will remain same across a reconnect and webhooks will all have the right data. However, there is also a server generated ID (called SID) per session. So, in OSS case, when a disconnect happens and reconnect happens, room name is the same, but generated room ID wil lbe different. Same with participants. Participant identity will be same, but server generated participant ID will be different. Almost all of our protocol works on identities (there might be some bits which uses server generated IDs which we will address over time). So, using identities and room name should make it work across reconnect. With LiveKit cloud, the server generated room ID will be used and if migration is successful, participant continues to operate using the same server generated ID. Only if the participant migration fails and it has to fall back to a full reconnect, a new server generated participant ID will be used.

Thank your for this very helpful response! So let's stick to the OSS Case. Here is some more information about the backend: The backend provides a UI for elevated users to create rooms and provide participants with URLs so that only participants with that link can join (just like LiveKit Meet Demo). For this our backend has a database which contains all rooms, credentials and so on. But if our streaming server goes down - the simplest case is when a dev shuts down their computer and restarts it the next day - all rooms are lost but are still present in the backend database. So the backend creates existing rooms automatically on the streaming server using a background process. So in case of LiveKit: 1. What do we need to do on our backend if LiveKit goes down? 2. Do we need to re-create each room manually from backend -> to LiveKit to keep them in sync?

Depends on your exact requirements. Thank you for the use case explanation. Like I mentioned, client SDKs will reconnect. That will use the token (which is refreshed automatically when a session is ongoing) which was used for initial connection. So, if you supplied your users with a token/URL to connect to, the clients can reconnect automatically. But, if you are looking some thing just shutting down over night and resume automatically on return, that requires you to create new tokens (unless the original token you created had a very long TTL). It will be the same process you use when you initially created the room/token. • Use the

CreateRoom

API (sorry if I do not have the exact room service API name here) to create the room. • Generate participant tokens using whatever is in our room data base (basically, it will be same room name, participant identity, permissions etc, but it will have new end time validity) • Send to participants and they connect using that.

Thank you so much. Maybe this makes it more clear: I don't care about the clients (room participants) of the rooms, yet. I just want to make sure that our backend and the state of the LiveKit Server are in sync which means that all rooms in the backend database are also available on the LiveKit Server and that all URLs I generated for participants to join a room are still working after the LiveKit Server starts new.

Rooms created are persisted into Redis. So nothing should be lost except for the connected participants.

Alright thank you for clarifying this. But there seems to be an automatic deletion of rooms after the last participant left, right? Or is this only true for ad-hoc rooms that weren't actively created through API? The docs are not completely clear to me on that point

yes, it does get cleaned up after they've been idling for a day.