https://livekit.io logo
Join Slack
Powered by
i use sip request for initialing conversation ```p...
# ask-ai
b
i use sip request for initialing conversation
Copy code
participant_identity = f"{phone_number}_{uuid4().hex[:8]}"
await ctx.api.sip.create_sip_participant(
    api.CreateSIPParticipantRequest(
        room_name=ctx.room.name,
        sip_trunk_id=self.outbound_trunk_id,
        sip_number=self.sip_number,
        sip_call_to=phone_number,
        participant_identity=participant_identity,
        wait_until_answered=True,
    )
)
and have issue To reproduce: 1. Sent request for Immediate call 2. Wait for call, answer it 3. Sent request for Immediate call Problems: 1. Bot drops the first call to make another one. Call can be interrupted at any moment of conversation. 2. When answer the second call I hear 2 voices, sometimes in different languages. Check file attached. Expected: 1. Don't drop the current call to make another call. 2. Need to fix 2nd call voices.
t
Thanks for reaching out, Aleh. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I see you’re creating SIP participants with 
wait_until_answered=True
and experiencing two problems: the first call drops when you start a second, and the second call has overlapping/duplicate voices. I can help—a few likely causes and targeted fixes below, plus two quick questions so I can narrow this down. Likely causes and fixes • Calls sharing the same room: a room broadcasts audio to all participants. If you add multiple SIP participants to the same room, they’ll hear each other (explains the “two voices”). ◦ Fix: create a unique room per outbound call and call 
create_sip_participant
for that room. • Agent/session reuse across calls: reusing one AgentSession or audio tracks across multiple calls can route TTS/agent audio into multiple calls. ◦ Fix: spawn an independent AgentSession / job context per call (one agent dispatch per room) so media and state are isolated. • Blocking during call creation: 
wait_until_answered=True
blocks until answered; doing this sequentially can prevent the agent from handling the first call while initiating the second. ◦ Fix: use 
wait_until_answered=False
and start call creation asynchronously (e.g., 
asyncio.create_task
) or dispatch calls from a control plane so initiation is non-blocking. • Agent processing multiple participants in the same room: the agent may be listening to multiple participant streams. ◦ Fix: bind the agent to a single participant using fixed-participant RoomIO so it only processes audio from the intended caller. Small checklist to apply now • Use unique room names per call (e.g., 
outbound-call-{uuid}
). • Ensure participant_identity remains unique (your current phone+uuid is good). • Use separate AgentSession / dispatch per room. • Start calls non-blocking (
wait_until_answered=False
) or offload to background tasks. • Configure RoomIO / session to only process the target participant. Two quick questions to help me pinpoint the issue 1. Are you creating SIP participants in the same room name each time, or already using unique rooms per call? 2. Are you running a single agent process/session that handles all calls, or do you dispatch a new agent instance per call? If you confirm those two points, I’ll give the exact code changes to make (small snippets for: room creation + non-blocking call start, and binding RoomIO to the SIP participant). Sources: How to set a fixed participant for agent audio processing | sip | livekit/livekit_composite | DeepWiki
b
i dispatch one agent each time
Copy code
cli.run_app(WorkerOptions(entrypoint_fnc=entry_fn, agent_name=settings.name))
t
Thanks — helpful that you dispatch one agent per call. I have a few focused follow-ups and one concise checklist to get this fixed. Quick clarifying questions 1. When you dispatch each agent, do you create a new room name for that dispatch (e.g., 
outbound-call-<uuid>
), or do you reuse the same room name for multiple dispatches? 2. In the agent entrypoint (
entry_fn
), do you call 
ctx.api.sip.create_sip_participant(...)
using 
ctx.room.name
, or do you pass a specific room name? 3. Are you using 
wait_until_answered=True
in production for these calls right now? Immediate checklist (apply in this order) • Ensure each call uses a unique room name (create room per call). • In each agent’s entrypoint, call 
create_sip_participant
for that agent’s room (use 
ctx.room.name
if rooms are unique). • Set 
wait_until_answered=False
and start the call asynchronously (or offload call creation to a control plane) so the agent can continue handling the active call. • Confirm each agent instance has its own session and audio tracks (no shared global audio objects). • Bind the agent’s audio input to the specific SIP participant (RoomIO or equivalent) so the agent only processes that participant’s audio. If you confirm answers to the three questions, I’ll provide the exact minimal code snippets for: • generating unique room names and dispatching, • non‑blocking SIP participant creation, and • binding RoomIO to the SIP participant.
b
i use oom_name=ctx.room.name
t
Thanks — using 
room_name = ctx.room.name
is fine only if each dispatch creates a unique room. Two quick confirmations and one small change to try: Questions 1. Does each agent dispatch pass a unique room name (e.g., 
outbound-call-{uuid}
) to the worker, or are you dispatching multiple agents into the same room name? 2. Do you currently call 
create_sip_participant(..., wait_until_answered=True)
inside 
entry_fn
? If the answer is that you reuse the same room name or you use 
wait_until_answered=True
, try this minimal change: • Ensure the dispatch creates a unique room per call (generate a uuid and use that as 
room_name
when dispatching). • In 
entry_fn
, call 
create_sip_participant
with 
wait_until_answered=False
and start it asynchronously (so the agent keeps running for the active call). If you confirm your answers, I’ll provide the exact minimal code snippets to generate unique room names, dispatch, and start the SIP call non-blocking.
Open in Slack
PreviousNext
Powered by