This message was deleted.

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

1. server-side 2. classic dispatch using dispatch rules based on phone numbers 3. no load balancers, no extra proxies 4. same room IDs but different sessions 5. room_name =

phone-_7623566401_BJcfEHpDmbBy

first session_id =

RM_UmZSdMrC2GGy

, second session_id =

RM_j4SHzdmETuwx

6. intermittent

Thanks — this is helpful. I’m responding to your report that a single room name (example:

phone-_7623566401_BJcfEHpDmbBy

) sometimes has two different session IDs (e.g.,

RM_UmZSdMrC2GGy

and

RM_j4SHzdmETuwx

) and the agent and caller end up in separate sessions intermittently. Below are the most likely causes and concrete checks/next steps you can take to diagnose and fix this. Likely causes • Race between room delete and recreate: If a room with the same (or similar) name is deleted and recreated quickly, LiveKit can produce nondeterministic session initialization that yields multiple session instances for what looks like the same room name. • Transient reconnects / retries at dispatch time: If the agent or your dispatch service retries or receives duplicate dispatch events (e.g., transient network failures or duplicated job requests), you can get multiple AgentSession attempts joining “the same” room which end up as separate sessions. • Out-of-order lifecycle events: If CreateRoom/DeleteRoom/Join events overlap (for example the server issues a new CreateRoom before the previous room cleanup has fully completed), session IDs can diverge even though the room name is identical. • Job dispatch behavior: If dispatch logic produces multiple job attempts (or if older reject/accept handling is used incorrectly), it can cause a bouncing effect where more than one session is created for a single call. Immediate checks to narrow root cause 1. Correlate timestamps ◦ Compare timestamps for CreateRoom, DeleteRoom (if any), and join events for both session IDs. Look for overlapping or near-simultaneous events. 1. Inspect dispatch logs ◦ Check your agent/server logs for duplicate job dispatch events or retries around the time both sessions were created. 1. Verify room lifecycle sequencing ◦ Confirm you are not issuing a CreateRoom for the same name while a prior room is still being torn down. If you are reusing names, check whether deletion completed before recreation. 1. Confirm token/room values at join time ◦ Log the exact token payload, room name, and room ID each client uses when calling join. Ensure the agent and caller are using identical room names and that no layer is rewriting or regenerating a different session identifier. 1. Check for retries on connection failure ◦ See whether the client or server SDKs are configured to automatically retry joins on transient failures; retries without deduplication can create separate session attempts. Targeted mitigations to prevent recurrence • Ensure highly unique room names (add UUID or monotonic ID) instead of reusing the same human-readable pattern when possible. • Add a short verify/delay before recreating rooms: check room state (participants/list) or wait 30–60s after deletion to allow cleanup. • Make dispatch idempotent: ensure your dispatch system deduplicates job requests and prevents multiple simultaneous dispatch attempts for the same call. • Add server-side join validation: before issuing tokens or accepting joins, verify whether an active session already exists for that call and route the client to the active session instead of creating a new one. • Increase logging around lifecycle events: log CreateRoom/DeleteRoom/Join attempts and the token/room_id used so you can trace which component created each session. If you’d like, I can: • Review a short excerpt of the server-side join/token generation and dispatch logic (paste sanitized snippets). I’ll look for race/retry patterns and suggest concrete changes. • Suggest specific log points and minimal checks to add so you can capture the exact event sequence next time it happens. Which would you prefer — I can review a sanitized code snippet from your join/token-generation flow, or I can give a precise set of logging instrumentation you can add to capture the next occurrence? Sources: Avoiding Room ID Reuse When Re-Creating Rooms With the Same Name | Ensuring Unique Room IDs with Dynamic Room Names | LiveKit | Server lifecycle | LiveKit Documentation | Why do jobs stop after agent rejection? | LiveKit | sip | livekit/livekit_composite | DeepWiki