import asyncio
import os
import logging
from doten...
# ask-ain
numerous-lighter-25835
04/27/2026, 7:06 PMimport asyncio
import os
import logging
from dotenv import load_dotenv
from livekit import api
load_dotenv()
logger = logging.getLogger("make-call")
logger.setLevel(logging.INFO)
room_name = "my-room"
agent_name = "test-agent"
outbound_trunk_id = os.getenv("SIP_OUTBOUND_TRUNK_ID")
async def make_call(phone_number):
"""Create a dispatch and add a SIP participant to call the phone number"""
lkapi = api.LiveKitAPI()
logger.info(f"Creating dispatch for agent {agent_name} in room {room_name}")
dispatch = await lkapi.agent_dispatch.create_dispatch(
api.CreateAgentDispatchRequest(
agent_name=agent_name, room=room_name, metadata=phone_number
)
)
logger.info(f"Created dispatch: {dispatch}")
if not outbound_trunk_id or not outbound_trunk_id.startswith("ST_"):
logger.error("SIP_OUTBOUND_TRUNK_ID is not set or invalid")
return
logger.info(f"Dialing {phone_number} to room {room_name}")
try:
sip_participant = await lkapi.sip.create_sip_participant(
api.CreateSIPParticipantRequest(
room_name=room_name,
sip_trunk_id=outbound_trunk_id,
sip_call_to=phone_number,
participant_identity="phone_user",
)
)
logger.info(f"Created SIP participant: {sip_participant}")
except Exception as e:
logger.error(f"Error creating SIP participant: {e}")
await lkapi.aclose()
async def main():
phone_number = "+1231231231"
await make_call(phone_number)
if name == "__main__":
asyncio.run(main())
when user makes a call does it joins entry point like in inbound call
✅ 1
t
tall-airline-16756
04/27/2026, 7:06 PMThanks for reaching out, Sajjad. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
tall-airline-16756
04/27/2026, 7:07 PMThanks — I’m responding to your question about whether an outbound call created with your script will “join the entry point” the same way an inbound call does.
Short answer: yes. When you create an outbound SIP participant with
create_sip_participant()@server.rtc_sessioncreate_dispatch()create_sip_participant()ctx.wait_for_participant()n
numerous-lighter-25835
04/27/2026, 7:08 PMcan you explain end to end the inbound and out callflow
t
tall-airline-16756
04/27/2026, 7:08 PMThanks — I’ll explain end-to-end inbound and outbound call flows in LiveKit, step-by-step, and highlight where they converge and differ.
Inbound call flow (SIP -> LiveKit):
1. SIP INVITE arrives at LiveKit’s SIP gateway.
2. SIP gateway matches the call to a dispatch rule (based on trunk, DID, or routing).
3. LiveKit creates or selects a room for the call (a room can be auto-created for the inbound call).
4. A SIP participant is created and joined to the room representing the phone endpoint. This triggers the normal participant lifecycle events (participant joined).
5. A dispatch may be created or looked up to assign an agent to the room according to your dispatch rules.
6. An agent is dispatched and connects to the room, which triggers the agent entry point (your server-side handler such as
@server.rtc_sessionctx.wait_for_participant()create_dispatch()create_sip_participant()create_sip_participant()n
numerous-lighter-25835
04/27/2026, 7:14 PMcan you make it with more clarity
t
tall-airline-16756
04/27/2026, 7:14 PMThanks — I’ll make the end-to-end inbound and outbound call flows clearer and more concise, with step-by-step bullets and a simple ASCII sequence for each. I’ll highlight where they match and differ.
Inbound call flow (SIP -> LiveKit)
1. SIP INVITE arrives at LiveKit’s SIP gateway (from PSTN/trunk).
2. SIP gateway matches routing to a dispatch rule or DID.
3. LiveKit creates or selects a room for the call.
4. A SIP participant is created and joins the room (represents the phone endpoint).
5. Dispatch logic assigns or creates a dispatch that targets an agent and the room.
6. The agent connects to the room — this triggers your agent entry point (server-side handler).
7. Agent entry point either:
◦ Immediately processes audio, or
◦ Waits for the SIP participant (e.g.,
ctx.wait_for_participant()create_dispatch()create_sip_participant()n
numerous-lighter-25835
04/27/2026, 7:17 PMin case of inbound call why
Waits for the SIP participant (e.g., ctx.wait_for_participant()), or
Runs IVR/routing before bridging.
t
tall-airline-16756
04/27/2026, 7:18 PMGood question — I’ll explain clearly why an agent entry point often waits for the SIP participant or runs IVR/routing before bridging in an inbound call.
Why the agent may wait for the SIP participant
• Timing: the agent is dispatched and its entry point can start before the caller’s SIP participant has fully joined the room. Using
ctx.wait_for_participant()wait_for_participant()n
numerous-lighter-25835
04/27/2026, 7:30 PMhow livekit handles multi agent orchestration
t
tall-airline-16756
04/27/2026, 7:30 PMThanks — I’ll explain how LiveKit handles multi‑agent orchestration, clearly and concisely, with patterns, mechanics, and a short flow for each.
Supervisor pattern (preferred when one agent must maintain session context)
• One supervisor agent stays in control of the call and delegates focused work to short-lived Tasks.
• Tasks run inside the same session and return typed results to the supervisor so conversation history and turn detection remain intact.
• Use when you need a single point of awareness, safety checks, or continuous context without re-summarizing.
Handoff pattern (full transfer of control)
• Control is transferred completely from one agent to another (or to a human).
• The original agent stops participating; context must be explicitly passed if needed.
• Use for escalation, specialist handoffs, or isolated agent responsibilities to save tokens.
Task-based delegation & Tooling
• Define reusable Tasks (AgentTask[ResultType]) and call them from the supervisor via function-like tools.
• Use TaskGroup to sequence multiple tasks with shared context.
•
function_toolfunction_toolfunction_toolUserDatan
numerous-lighter-25835
04/27/2026, 7:35 PMno i am asking about the AI agen (brain)
t
tall-airline-16756
04/27/2026, 7:36 PMThanks — I’ll explain how the AI agent (the “brain”) works end‑to‑end and how it orchestrates multi‑agent behavior in LiveKit, clearly and concisely.
Core concepts (what the brain is)
• AgentSession: the runtime that manages the real‑time voice pipeline (STT → LLM → TTS), turn detection, interruptions, and session state. It is the session-level “brain manager.”
• Agent: the agent’s logic and instructions (LLM prompts, tools, decision rules) that run inside an AgentSession.
• Tasks: short-lived, typed units of work executed inside the same AgentSession; they perform focused actions (lookup, payment, escalate) and return structured results to the Agent.
How the brain processes a call (simple flow)
1. AgentSession starts and is attached to the room.
2. Incoming audio → STT produces transcript chunks.
3. Transcript chunks → LLM processes context + tools as configured.
4. LLM output → Agent decides next action (speak via TTS, call a Task, or transfer).
5. TTS renders audio back into the room; state and conversation history persist in the session.
Orchestration patterns (how multiple AI roles are coordinated)
• Supervisor pattern (recommended when one central brain must keep full context):
◦ One supervisor AgentSession stays active, delegates work to Tasks (e.g., “handle_billing”), collects typed results, and continues orchestration without leaving the session.
• Handoff pattern (full transfer of control):
◦ One agent exits and another agent takes over. Context must be explicitly passed to the new agent (used for escalation or isolated domains).
• Observer/guardrail pattern (parallel monitoring):
◦ A background observer listens to transcripts, evaluates safety/compliance, and injects updates into the session context (does not interrupt main flow).
Inter-agent communication & tools
• Use function-like tools (
function_toolfunction_toolfunction_tooln
numerous-lighter-25835
04/27/2026, 7:39 PMlike this
@function_tool()
async def markspain_protocol_agent(context: RunContext_T):
"""
After caller have replied to the greeting, immediately call the xyz_protocol_agent to collect or confirm their information.
You must only call this tool once per call
"""
logger.info("Transferring to xyz_protocol_agent agent")
return await context.session.current_agent._transfer_to("xyz_protocol_agent", context)
t
tall-airline-16756
04/27/2026, 7:39 PMThanks — I’ll show a clear, practical example that matches your snippet: a
@function_tool Copy code
@function_tool()
async def markspain_protocol_agent(context: RunContext_T):
"""
After caller replies to the greeting, immediately transfer to the
'xyz_protocol_agent' to collect/confirm info. Call this once per call.
"""
logger.info("Transferring to xyz_protocol_agent agent")
# Ensure we only transfer once per call
if context.session.user_data.get("transferred_to_xyz"):
logger.info("Already transferred to xyz_protocol_agent; skipping")
return {"status": "skipped", "reason": "already_transferred"}
# Mark transferred (persist minimal state)
context.session.user_data["transferred_to_xyz"] = True
# Perform the transfer via the current agent session API
# (uses the agent runtime's transfer method; your SDK method may differ)
result = await context.session.current_agent._transfer_to("xyz_protocol_agent", context)
return {"status": "transferred", "result": result}context.session.user_data_transfer_to(...)contextfunction_tooln
numerous-lighter-25835
04/27/2026, 7:40 PMi am asking like langgraph ochestration framework
does livekit provide any such
t
tall-airline-16756
04/27/2026, 7:41 PMShort answer: LiveKit does not provide a visual graph/orchestration UI exactly like LangGraph out‑of‑the‑box.
What LiveKit does provide that covers the same orchestration needs:
• AgentSession + Agent + Tasks: a runtime “brain” that manages STT → LLM → TTS and lets an agent delegate focused work as typed Tasks inside the same session (supervisor pattern).
•
function_toolfunction_toolfunction_tool2 Views