how can i merge rooms or move participant from one...
# ask-ai
a
how can i merge rooms or move participant from one room to another on self hosted livekit?
t
Thanks for reaching out, Aditya. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’m responding to your question about merging rooms or moving a participant between rooms on self-hosted LiveKit. Short answer: LiveKit does not support merging rooms or moving a participant directly from one room to another. What you can do instead: • Client-side reconnect: Have the participant disconnect from Room A and join Room B. Use your app logic or backend (Server SDK) to issue new join tokens and coordinate the switch. • Single-room with selective subscriptions: Use one larger room and control which tracks each participant subscribes to so different groups see different sets of participants — this can mimic multiple rooms without moving users. • Backend-coordinated migration flow: Your server can orchestrate the move by notifying clients when to leave/join, preparing tokens for the target room, and restoring any needed state (e.g., published tracks, metadata). Questions to help me give exact steps: • Do you want the switch to be seamless (preserve published tracks/identities) or is a simple disconnect/reconnect acceptable? • Are you using a LiveKit Server SDK (which language) and client SDK (web, iOS, Android)? • Do you need code examples for issuing join tokens and orchestrating the client reconnect? Tell me which approach you prefer and what platform/language you use, and I’ll provide a concise implementation plan or code snippet. Sources: Livestream Mode | Use Case: Video Conferencing | LiveKit
a
I want the switch to be seamless , i did it using simple disconnect/reconnect but want it to be smooth, and i am using livekit server SDK in python.
t
Thanks — I’m responding to your request for a seamless room switch using the LiveKit Python Server SDK. You can’t move a participant server-side without the client re-joining, but you can make the transition appear seamless by minimizing disconnect time and restoring state quickly. Below is a concise approach and code-focused plan you can implement. High-level approach • Prepare the target room and a short-lived join token on the server before switching. • On the client, publish any outgoing tracks to a local buffer (or keep them un unpublished) and start establishing a connection to the target room before fully tearing down UI/state for the old room. • Use a two-connection handoff or fast reconnect pattern so the client maintains media continuity as much as possible: ◦ Option A (preferred): Create a second peer connection to the new room in parallel, publish tracks to the new room, then unsubscribe/close the old connection. ◦ Option B: Quickly unpublish/pause tracks, disconnect, then immediately reconnect to the new room and republish — keep downtime minimal by prefetching join token and endpoints. • Restore participant metadata and subscriptions immediately after join so UI and identities appear unchanged. Server-side (Python) — token generation 1. Create a short-lived join token for the target room with the same identity and necessary grants. 2. Return that token to the client when you signal the planned move. Example (LiveKit Python Server SDK — token creation):
Copy code
from livekit import AccessToken, RoomGrant
from datetime import timedelta

# make a token that joins `target_room` as `identity`
def create_join_token(api_key, api_secret, identity, target_room, ttl_seconds=30):
    at = AccessToken(api_key, api_secret, identity=identity)
    room_grant = RoomGrant(room=target_room)
    at.add_grant(room_grant)
    at.set_ttl(timedelta(seconds=ttl_seconds))
    return at.to_jwt()
Client-side patterns (choose one based on client SDK capabilities) • Parallel connection (smoothest): a. Request the token for Room B from your server. b. Create a new connection/Room instance to Room B while keeping Room A active. c. Once Room B connection is established and tracks are published there, stop/unpublish tracks from Room A and close it. d. Swap UI to Room B. • Fast reconnect (when parallel connections are not possible): a. Request token for Room B and prepare local track capture (mic/camera). b. Pause UI updates, quickly disconnect from Room A. c. Immediately connect to Room B and republish tracks. d. Restore UI once Room B is ready. State to preserve and restore • Participant identity and metadata • Published track settings (muted state, simulcast layers) • Subscriptions or published track IDs you want visible on the new room • Any application-level data (chat, participant roles) — re-sync via your app server Practical tips to reduce perceived disruption • Use very short token TTL and pre-generate tokens right before switching. • Pre-create and warm up local tracks before connecting to the new room to avoid device re-acquisition delay. • If using simulcast, ensure your client publishes the same encodings to maintain continuity. • Show a smooth UI transition (e.g., crossfade video placeholders) while the second connection is negotiated. • Reuse the same identity so participant appears as the same user in Room B. Next step for me to provide code you can drop in: • Tell me which client SDK you use (Web, iOS, Android) and whether you can open two simultaneous room connections from the client. I’ll provide a small client-side example for the selected SDK showing the parallel-connection handoff.
a
I want to do it for teliphone using SIP
t
Thanks — I’m responding to your request about doing a seamless room switch for a telephone (SIP) participant. Short answer: you cannot move a SIP participant server-side between LiveKit rooms without a disconnect. SIP calls in LiveKit are treated as room participants; transferring between rooms requires ending the LiveKit SIP participant in Room A and creating a new SIP participant in Room B, which causes an audio interruption. What you can do instead: • Use SIP-level REFER transfer: If your SIP provider and trunk support REFER, use LiveKit’s TransferSIPParticipant API to redirect the call to another phone/SIP destination. This performs a SIP transfer at the telephony layer (cold transfer) but does not keep the participant in a continuous LiveKit session across rooms. • Orchestrate a quick disconnect/reconnect: Pre-generate the join token for Room B, notify your application, create the new SIP leg quickly, and remove the old participant — minimize downtime by warming devices and automating token creation. • If you control both endpoints, consider routing logic outside LiveKit (conference bridge or SBC) to bridge calls across rooms, then connect bridged audio into LiveKit rooms — this is a custom architecture outside LiveKit core. Quick questions to give precise code and steps: • Do you use LiveKit’s telephony gateway or a custom SIP gateway/SBC? • Does your SIP trunk/provider support REFER? • Do you want a cold transfer (agent leaves) or a supervised/attended transfer (agent stays on the line while bridging)? Tell me those details and I’ll provide the exact Python Server SDK sequence or TransferSIPParticipant usage example tailored to your setup. Sources: Agents telephony integration | LiveKit docs