We are facing an issue with LiveKit room lifecycle management
A participant joins the room, followed by the AI agent and egress service.
If the participant disconnects due to CONNECTION_TIMEOUT and since no “standard” participant is left, LiveKit triggers “session.close” event causing the agent to leave as well which in turn triggers room tear down manually overriding the default empty timeout.
After approximately 1 or 2 mins, the participant reconnects, and we observe a different room ID with same room name and only same participant that joins the room due to reconnect. In this new room the agent and egress never joins.
Room ids with same room name:
RM_ZABB75iE5zKc
RM_bkcnLNWWXDXR
RM_PgoNRr7xUTJQ
For context:
We generate participant access tokens with a TTL of 10 minutes.
Hi, you can’t specify the room ID as part of the token, you need to specify the room name.
You really want the user joining the same room, rather than create a new one, since then you retain the conversation context with the agent.
If this happens regularly, that a participant reconnects after 1 or 2 minutes, then I think you want to keep the room alive by specifying a departure_timeout on the RoomConfiguration of the token (it defaults to 20 seconds), Room service API | LiveKit Documentation. To prevent the agent from leaving you would also need to specify close_on_disconnect as false: Agent session | LiveKit Documentation.
Another option, if you don’t want the participant to be able to reconnect is to listen for a participant_disconnected webhook, and when the participant disconnects, revoke their token, Access tokens & grants | LiveKit Documentation, which would prevent the room being re-created when they reconnect.
We haven’t observed the default 20-second departure_timeout behaviour when all participants leave the room.
Could this be because we don’t explicitly create rooms using the LiveKit Room Service API? Currently, the room is created automatically when we dispatch the agent with the room name specified.
Am I correct in understanding that we should explicitly create the room using the Room Service API, configure departure_timeout in the room configuration, and then dispatch the agent using the same room name?
Would this ensure the room remains available for participant reconnection, even if all participants temporarily disconnect?
I wasn’t suggesting that - that would give you more control but it would be a large change on your part.
I was referring to the room configuration on the token, Access tokens & grants | LiveKit Documentation , but that docs page doesn’t list every parameter, it directs you to Room service API | LiveKit Documentation. I only provided the second link in my response above, which in retrospect was confusing - sorry about that. You should be able to define departure_timeout as part of the token room_config, based on those docs. I haven’t tested it to be 100% sure, so let me know if you see any issues - If you specify a high value, say 3 minutes, I wouldn’t expect the room to end for 3 minutes after the participant leaves.
Thank you, Darryn. We tested departure_timeout: 60 in the token’s room_config, but the room still closed about 22 seconds after the participant left. We dispatch the agent with createDispatch before the participant joins, so the room already exists when the token is used. Is there a way to pass departure_timeout through createDispatch or agent side, so the room it creates uses it?
No, you can’t control the departure timeout if you are creating the room automatically via createDispatch. You would need to create the room first, through the createRoom API, then dispatch the agent to that created room.
So, a corrected answer to this question, “yes”. Sorry for all the confusion
