after end call new room is getting spinned why?

Thanks for reaching out, Sandeep. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

I am calling end call api

Thank you for reaching out! When you use the end call API, like

deleteRoom

, it deletes the specified room, which disconnects everyone and stops new participants from joining. However, LiveKit is designed to automatically create a new room if someone tries to join a room that doesn’t exist anymore. So, if you notice a new room popping up after ending the call, it might be because there’s a join attempt happening right after the room was deleted. If that’s not what you intended, it might help to double-check your application logic to make sure no one is trying to join after the room has been deleted. Please feel free to reach out if you want to dive deeper into this—I’m here to help! Sources: Rooms, participants, and tracks | LiveKit Docs | src/main/kotlin/io/livekit/server/RoomServiceClient.kt | CreateRoom() is Taking Too Long | complex-agents/ivr-agent/ivr-agent-frontend/src/App.tsx | packages/livekit-server-sdk/README.md

egress is trying to join again after room delete

I’m happy to help you with this! To make sure egress doesn’t rejoin a room after it’s been deleted, the best approach is to use the

DeleteRoom

API. This will disconnect everyone, including egress, and stop any recordings or streams in progress. Once the room is deleted, no one—including egress—should be able to get back in. If you’re still seeing egress trying to join, it might be worth double-checking your application logic to make sure no new join attempts are happening after the room is deleted. Also, managing token validity can help—issuing short-lived tokens or stopping new tokens from being created for that deleted room can prevent unwanted access. Please feel free to reach out if you’d like me to walk you through any of this or if you have more questions—I’m here to help! Sources: livekit/livekit_room.pb.go | Managing participants | LiveKit Docs | Docs::Home | Inside a session | LiveKit Docs | Inside a session | LiveKit Docs

| Time (UTC) | Event Type | | ------------------------ | ------------------- | | 2025-09-11T054645.018Z | room\_started | | 2025-09-11T054645.140Z | participant\_joined | | 2025-09-11T054647.318Z | participant\_joined | | 2025-09-11T054647.348Z | track\_published | | 2025-09-11T054647.587Z | track\_published | | 2025-09-11T054648.653Z | participant\_joined | | 2025-09-11T054651.802Z | track\_published | | 2025-09-11T054823.317Z | track\_unpublished | | 2025-09-11T054823.347Z | participant\_left | | 2025-09-11T054823.373Z | track\_unpublished | | 2025-09-11T054823.439Z | track\_unpublished | | 2025-09-11T054823.465Z | participant\_left | | 2025-09-11T054823.537Z | participant\_left | | 2025-09-11T054824.951Z | participant\_joined | | 2025-09-11T054825.116Z | room\_finished | | 2025-09-11T055030.086Z | participant\_left |

Thank you for sharing the event log! It shows the lifecycle of the room and participant actions quite clearly. Here’s a friendly breakdown of the key moments: • Room Started: The room was created at

2025-09-11T05:46:45.018Z

. • Participants Joined: Several participants joined the room at different times, such as

2025-09-11T05:46:45.140Z

,

2025-09-11T05:46:47.318Z

, and

2025-09-11T05:48:24.951Z

. • Tracks Published: Participants published media tracks at various points, including

2025-09-11T05:46:47.348Z

and

2025-09-11T05:46:51.802Z

. • Participants Left: Some participants left the room at

2025-09-11T05:48:23.347Z

and

2025-09-11T05:50:30.086Z

. • Room Finished: The room was terminated at

2025-09-11T05:48:25.116Z

. It looks like after the room was finished, a participant—likely the egress—tried to rejoin at

2025-09-11T05:48:24.951Z

. This might happen if the egress process wasn’t fully stopped before the room was deleted, or if your application logic attempted a reconnect. To help avoid this, I recommend using the

DeleteRoom

API to delete the room. This API ensures all participants, including egress, are disconnected properly. Also, it’s a good idea to double-check that your application isn’t triggering any new join attempts after the room has been deleted. If you’d like, I’m here to guide you through these steps or answer any other questions you might have! Sources: protobufs/livekit_analytics.proto | Handling events | LiveKit Docs | pkg/telemetry/events.go | Docs::Home | README.md