how to delete room when end call is called?

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

i am using python, if i save data in: context.session.metadata and if i delete the room, will the data persists?

Thanks — I’m responding to your question about whether data saved in

context.session.metadata

will persist after you delete a LiveKit room (Python). Short answer: No — metadata stored on the session/room is ephemeral and will not persist after the room is deleted. Why: • Room and participant metadata are tied to the room’s lifetime. Deleting a room via the

delete_room

API (or via

delete_room_on_close

/ EndCallTool) removes the room and its associated state, which includes session/room/participant metadata and active connections. • That means any data you keep only in

context.session.metadata

will be lost when the room is removed. What you can do instead (recommended): • Save the data to an external persistent store (database, object store, Redis, etc.) before you delete the room. • Hook into your shutdown/end-call flow to persist metadata. For example: a. On end-call event, read

context.session.metadata

. b. Write that data to your database or an external API. c. Then call the room deletion (or allow the automatic delete to proceed). If you want, tell me: • What data you’re storing in

context.session.metadata

and when you want it available after the call. • Which database or storage you prefer (Postgres, Redis, S3, etc.). I’ll provide a short Python snippet showing how to persist the metadata to your chosen store and where to call the room deletion. Sources: Job lifecycle | LiveKit Documentation | Handling asynchronous metadata updates in LiveKit | LiveKit | External data and RAG | LiveKit Documentation

what are all the events that I can listen to?

Thanks — I’m responding to your question about which LiveKit events you can listen to. Since you’re using Python, I’ll focus on the events you’ll commonly use in client sessions and the Agents framework, and note related room/track/participant events you can also observe. If you want the full SDK enum for Python specifically, tell me which SDK you’re using (client SDK vs. Agents SDK) and I’ll show the exact names and a short snippet for registering handlers. Room-level events • Connected — successfully connected to a room. • Disconnected — connection closed or lost. • Reconnecting — connection dropped and reconnection in progress. • Reconnected — reconnected after disruption. • RoomMetadataChanged — room-level metadata updated. • ParticipantConnected — participant joined the room. • ParticipantDisconnected — participant left the room. • ActiveSpeakersChanged — active speakers list updated. • DataReceived — data message received from a participant. • ConnectionQualityChanged — participant/network quality updates. Participant events • Participant metadata/identity changed (MetadataChanged / IdentityChanged). • ParticipantIsSpeakingChanged — speaking state changed. • ParticipantDisconnected — participant left. • TrackPublished / TrackUnpublished — participant published or unpublished a track. Track events • TrackSubscribed / TrackUnsubscribed — local client subscribed/unsubscribed to a remote track. • TrackMuted / TrackUnmuted — track muted or unmuted. • TrackAttached / TrackDetached — track attached/detached to a player/UI element. • LocalTrackPublished / LocalTrackUnpublished — local track publish lifecycle. Data / communication events • DataReceived — inbound data packets (reliable/unreliable). • MediaDevicesError — errors accessing mic/camera. Connection-quality events • ConnectionQualityChanged — notifications of quality tiers (e.g., Poor / Good / Excellent). Agent-session (Agents framework) events — relevant since you use Python agents • user_state_changed — user speaking/listening/idle state updates. • agent_state_changed — agent state updates (listening, thinking, speaking). • user_input_transcribed — user speech transcription completed. • conversation_item_added — new message, tool call result, or LLM output added to conversation history. • speech_created — agent speech was synthesized/queued. • close / session closed — session shutdown. • error — agent/session errors. Server-side webhook events (if you use webhooks) • room_started / room_finished — room lifecycle on the server. • participant_joined / participant_left. • track_published / track_unpublished. • egress_started / egress_ended and ingress_started / ingress_ended — recording/streaming lifecycle. How to proceed (quick examples) • If you want a Python example for the Agents SDK showing how to register handlers for agent events, tell me and I’ll provide a concise snippet. • If you want the concrete enum names used in the Python client (so you can do

room.on(...)

or

session.on(...)

), tell me whether you’re using the low-level client SDK or the Agents framework and I’ll return exact names/snippets. Would you like: • A Python snippet showing how to listen for room and track events in the client SDK, or • A Python example for Agent-session event handlers (e.g.,

user_state_changed

,

conversation_item_added

)? Tell me which one and I’ll provide the exact code you can drop into your project. Sources: Rust SDKs | livekit/livekit_composite | DeepWiki | client-sdk-js | livekit/livekit_composite | DeepWiki | Client SDKs | livekit/livekit_composite | DeepWiki | client-sdk-flutter | livekit/livekit_composite | DeepWiki | client-sdk-unity | livekit/livekit_composite | DeepWiki

what is "reason": "CLIENT_INITIATED"

Thanks — I’m responding to your question about what

"reason": "CLIENT_INITIATED"

means. Short answer: •

"CLIENT_INITIATED"

is a disconnect reason that indicates the client (the user’s app or browser) intentionally initiated leaving the room. It means the participant called a leave/disconnect action (for example,

room.disconnect()

or closing the app/tab), not that the server or network forced the disconnect. When you’ll see it: • In client callbacks or server webhooks for events like participant/room left, you may see a payload that includes

reason: "CLIENT_INITIATED"

. • It’s used to distinguish intentional, user-driven disconnects from other causes such as network timeouts, server-side closes, or state mismatch errors. How it differs from other reasons: • CLIENT_INITIATED: user/app intentionally left. • CONNECTION_TIMEOUT: client lost connectivity and timed out. • STATE_MISMATCH (or server-forced reasons): indicates protocol/state issues or a server-driven disconnect. If you want, tell me where you saw this field (client logs, webhook, or API response) and I can show an example of the payload and recommend any follow-up handling (e.g., whether to attempt automatic reconnect, persist session data, or show a UX message). Sources: Server-side | livekit/livekit_composite | DeepWiki | Understanding the STATE_MISMATCH Disconnect Reason | LiveKit