Thanks — I’m responding to your question about whether a LiveKit browser JS client can open multiple connections to the same room and why you see "WARN could not createOffer with closed peer connection." Short answer: No — you cannot have multiple active Room connections from the same browser context to the same LiveKit room using the JS SDK. That warning is expected when a second connection conflicts with the existing one. Why this happens (brief): • LiveKit expects a single participant identity per room. If you connect twice with the same identity, the server disconnects the earlier session (DUPLICATE_IDENTITY), which closes its underlying RTCPeerConnection. Calling createOffer() on that closed PeerConnection produces the warning you saw. • The SDK and WebRTC PeerConnection state are tied to a single session flow; opening another session in the same context causes signaling/track/ICE conflicts. What you can do instead: • Use one

Room

instance per browser client and reuse it. • If you need multiple participants for testing or multi-view, create separate browser contexts (different tabs/windows or iframes) and give each a unique participant identity/token. • Or run additional participants from server-side/agent SDKs to simulate extra clients. If you want, tell me which of the workarounds you’re trying (multiple tabs, iframes, or agent participants) and I’ll give the specific steps or code hints. Sources: Rooms, participants, and tracks | LiveKit docs | client-sdk-js | livekit/livekit_composite | DeepWiki | Connecting to LiveKit | LiveKit docs