When should we create the sip participant ? i am e...
# ask-ai
a
When should we create the sip participant ? i am experiencing some blank calls, the agent is calling a tool to end the call without saying anything, how can i prevent that ? should i call the sip create participant just before i do session.start ?
t
Thanks for reaching out, Ayush. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — that’s a great question, and I understand the frustration with blank calls. I’m responding to your question about when to create the SIP participant and how to avoid the agent immediately ending the call. Short answer • Create the SIP participant before calling
session.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 Documentation
a
Call terminated with reason 4, whats 4 here ?
t
Thanks — I’m responding to your question about the call termination reason code
4
. 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