alert-notebook-4408
03/02/2026, 11:29 AMtall-airline-16756
03/02/2026, 11:29 AMtall-airline-16756
03/02/2026, 11:29 AMsession.start().
• Preferably create it with a wait option (e.g., wait_until_answered=True) or otherwise wait until the participant has joined before letting the agent begin speaking or running any call-ending logic.
Why blank calls happen
• If the agent session starts before the SIP participant is present, the agent may detect silence or an idle state and trigger tools (like an end_call tool) immediately. That makes the call end before the caller hears anything.
Correct sequence (recommended)
1. Create the SIP participant (start the outbound call).
2. Wait for the SIP participant to answer / join the room (either by using a built-in wait flag or by listening for the participant-joined event).
3. Start the agent session with session.start() and only then let the agent run conversational logic or generate replies.
Practical tips
• Use a “wait until answered” option when creating the SIP participant so the API call returns only after the call is answered.
• If no wait flag is available, add an explicit listener or polling to confirm the participant joined the room before calling session.start() or before the agent runs any automatic tools.
• Avoid invoking any call-ending tool automatically on agent startup — require explicit user input or a clear timeout after the participant has been present for some time.
• As an added safeguard, you can add a short grace period after join detection before running automated actions so transient race conditions don’t trigger end-call logic.
If you’d like, share a short snippet of the relevant code flow (how you call create_sip_participant and session.start()) and I’ll point out exactly where to change it and suggest the safest implementation for your setup.
Sources: Outbound Calling Script | LiveKit Documentation | Agents telephony integration | LiveKit Documentationalert-notebook-4408
03/02/2026, 11:45 AMtall-airline-16756
03/02/2026, 11:46 AM4.
Reason code 4 means: MIGRATION.
What that means
• The participant was disconnected because a node migration completed. In other words, the server/node that was managing the participant’s media connection moved (for scaling or maintenance), and the participant was disconnected from the old node when the migration finished.
What to watch for / next steps
• This is usually transient and happens during normal scaling or maintenance.
• If you see frequent MIGRATION disconnects for many calls, share:
◦ When the disconnects occur (time window)
◦ Any server-side logs around the migration events
◦ Whether the participant reconnects automatically or needs a manual retry
If you want, paste a short snippet of the logs or describe what happens after the migration (automatic reconnect vs. hard disconnect) and I’ll help you pinpoint whether this is expected behavior or something to investigate further.
Sources: Server-side | livekit/livekit_composite | DeepWiki