Feature Request: Persistent Rooms

[nilskretschmer]

Short description

Add the ability to persist rooms - even after the last participant left. This includes one or both of the following features:

1. Add a config value to rooms that a room should persistent (not be destroyed after last participant left)
2. Persist rooms to some kind of storage (database, file) so that rooms are actually persistent and only destroyed on demand (e.g API Call)

Background

The LiveKit Docs say:

A Room is a container object representing a LiveKit session.

Each participant in a room receives updates about changes to other participants in the same room. For example, when a participant adds, removes, or modifies the state (e.g. mute) of a track, other participants will be notified of this change. This is a powerful mechanism for synchronizing state, and fundamental to building any real-time experience.

A room can be created manually via server API, or automatically, when the first participant joins it. Once the last participant leaves a room, it will be closed after a short delay.

This means that any room will be destroy after the last participant left. This is fine for ad-hoc conferences where a room gets created just before the meeting and destroyed afterwards. But planning a meeting beforehand (maybe days before) is not possible with this behaviour.

Use Cases

1. Planning a Meeting beforehand.
2. Test if a room works - this would require the "creator" of the room to join the room and leave the room (which would cause the room to be destroyed currently)
3. Better syncing possibilites with custom Backends (if rooms are persistent they could easily be synced with a custom backend's database)
4. Enable issuing some kind of join-URLs before the meeting actually starts.

Typical Problems with the current implementation

1. Planning a meeting beforehand difficult
2. Participant Access Tokens (and maybe generated join-URLs containing that participant token for a meeting room) are no more valid if a room got destroyed automatically
3. If LiveKit restarts for any reason all rooms are lost and all participant tokens become invalid.

[davidzhao]

This is a good point.. I think we should have an IdleTimeout in addition to EmptyTimeout. would that work for your use case?`

[giovankabisano]

I want to request the same thing. Actually my company wants to try LiveKit services for our needs. But there is a use case that needs this kind of feature or it will be a deal breaker :(

Anyway, can you please explain more about 'IdleTimeout' idea? @davidzhao

And, currently how do you create a persistent room? @nilskretschmer

[davidzhao]

@giovankabisano what are you building with it? Just to understand if the same parameter could help.

How long do you need to keep the room open for?

[giovankabisano]

@davidzhao We'd like to be able to plan a meeting beforehand (like a regular series meeting) which we can use the same URL for that regular series meeting.

How long do you need to keep the room open for?

I'm not really sure what you mean by "keep the room open". But I think if we able to create and use a meeting room with that same URL for the next 1 year, it will be enough.

Maybe a follow up question towards your earlier question, if I "keep the room open" for until 1 year, does it mean that the server cost gonna be so high? And I assume if LiveKit restarted for any reason, the room will be destroyed and we need to create a new room, isn't it?

[davidzhao]

@giovankabisano I think you can already accomplish what you are looking for. There are two paths forward:

1. with room auto creation enabled (default), and each time issue the token to participants for the consistent room name. When they connect to the server, the room would be created on the fly.
2. with auto creation disabled, your application could call RoomService.CreateRoom when participants would like to connect to the room.

Do you see a reason why either of the options above wouldn't work?

[nilskretschmer]

Maybe the docs are not clear enough (for me): Does Livekit allow two rooms to have the same name or is the room name unique? If I understand @davidzhao correctly it seems like Livekit handles room names in a unique way. And one of the required parameters to create a room token is the room's name, not an ID?

So it should be no problem to save created rooms in a backend database and also access tokens should be valid even if the room gets destroyed? So if I join the room again after it got closed (destroyed) it should just work?