We are integrating Cekura with our own voice AI platform and need help confirming the correct LiveKit architecture. Current product flow: - Our system launches outbound calls. - Our system is the real caller. - Our orchestrator handles call creation, queueing, slot allocation, LiveKit room setup, and agent dispatch. - We want to stress test our real outbound path, not bypass it. Goal: - Use Cekura as the automated answering side / simulated patient / evaluator - Keep our platform as the system initiating the outbound calls - Preserve load on our orchestrator, queue workers, slot manager, and agent infrastructure - Later scale to 15 and then 30 concurrent test calls Question: Does LiveKit support a pattern where: 1. Our platform initiates the outbound call 2. The destination is a LiveKit/Cekura-controlled answering endpoint 3. The simulated callee answers automatically 4. LiveKit still preserves call/session metadata so we can correlate external run IDs 5. This works without switching the caller role to Cekura We specifically want to understand whether LiveKit can support the “our platform calls out, automated test counterpart answers” model, rather than the more common “external system creates the room and our agent joins” model. We also want to know: - whether SIP or telephony routing can support this cleanly - whether inbound SIP headers / participant attributes can preserve custom correlation fields like run_id, scenario_id, result_id - whether there is a recommended architecture for load-testing an outbound calling platform where the platform under test remains the caller If possible, please explain: - the recommended LiveKit architecture for this setup - what is and is not supported - whether LiveKit alone is sufficient, or whether we need another provider/component to create the automated answering side

Hi — thanks for the clear description. I’ll respond to each part of your question and then give a compact recommended architecture and what’s supported vs. not supported. Acknowledging what you asked: you want to keep your platform as the real caller (preserve load on your orchestrator/queue/slot manager), have Cekura act as the automated answering side, and ensure call/session metadata (e.g., run_id, scenario_id, result_id) is preserved and accessible. You also want to know whether SIP/telephony can support this cleanly and whether LiveKit alone is sufficient or if another component is required. Short answer • Yes — LiveKit supports the model where your platform initiates outbound calls and a Cekura-controlled endpoint answers automatically. • SIP/telephony routing can support this and custom correlation fields can be preserved via job metadata, participant attributes, or SIP headers. • LiveKit alone is sufficient for this pattern when paired with an inbound trunk or LiveKit phone number on Cekura’s side to auto-dispatch the answering agent. How this can be implemented (high level) 1. Your orchestrator initiates the outbound call: ◦ Use LiveKit’s SIP outbound API to create a SIP participant (e.g.,

CreateSIPParticipantRequest

) pointing to Cekura’s phone number or SIP URI. ◦ Include your correlation data in the request (metadata field or custom SIP headers / participant attributes). 1. LiveKit forwards the INVITE to the configured SIP trunk / phone number for Cekura: ◦ The call is routed to Cekura’s inbound trunk or LiveKit phone number. ◦ Cekura’s dispatch rules can automatically dispatch an answering agent into the room when the call arrives. 1. Cekura’s automated answerer joins the LiveKit room: ◦ The Cekura agent answers and joins the same LiveKit room as your caller. ◦ Audio is bridged in the room; both sides interact as if a normal call connected. 1. Correlation and metadata: ◦ Pass

run_id

,

scenario_id

,

result_id

in job metadata or participant attributes when creating the SIP participant or dispatching an agent. ◦ The Cekura agent reads metadata via

ctx.job.metadata

or participant attributes on join. ◦ SIP participant fields (e.g.,

sip.phoneNumber

,

sip.trunkID

) and any custom SIP headers are available for inspection as needed. Why this preserves your outbound load and roles • Your orchestrator is still the caller (you create the outbound SIP invite). • Cekura only answers; they do not need to initiate calls. • All orchestration, queueing, slot allocation and other upstream systems remain exercised as in normal operation. SIP / telephony specifics • Use either LiveKit phone numbers or a BYO SIP provider/trunk (Twilio, Telnyx, etc.) for inbound answering on Cekura’s side. • You can include correlation fields in: ◦ Job metadata fields passed to the agent, ◦ Participant metadata/attributes, ◦ Custom SIP headers (depending on your trunk/provider and how you forward headers). • Confirm with the SIP trunk provider whether they preserve and forward custom SIP headers end-to-end if you rely on headers specifically. If you want absolute control, put the correlation data in LiveKit job/participant metadata (guaranteed accessible to the agent). Recommended architecture (concise) 1. Your Platform (caller) ◦ Create room / create SIP participant → target Cekura number ◦ Include

metadata

payload: {run_id, scenario_id, result_id, ...} ◦ Continue to use your orchestrator/queue/slot manager unchanged 1. LiveKit ◦ Outbound SIP forwarding to Cekura’s inbound trunk / phone number ◦ Bridge audio into the LiveKit room ◦ Expose participant/sip attributes and job metadata 1. Cekura (answering side) ◦ Own inbound trunk or LiveKit phone number and inbound dispatch rule ◦ Auto-launch answering agent that reads

ctx.job.metadata

or participant attributes to get correlation fields ◦ Simulated patient logic runs inside the agent (TTS/ASR/AI) and interacts in the room Scaling / load testing guidance • LiveKit supports many concurrent rooms/participants; scaling to 15 then 30 concurrent test calls is achievable. • Keep your orchestration path and queue workers as the test target—don’t bypass them. Have your orchestrator create the SIP participant for each test run. • Monitor resource usage on: ◦ Your orchestrator/queue workers ◦ Agent instances on Cekura (ensure the answering agent can scale to simulate N calls concurrently) ◦ LiveKit server/region/ingress throughput (if self-hosted) or plan for concurrency with LiveKit managed service • If you need to simulate very large scale beyond voice agent compute or SIP trunk limits, consider horizontally scaling the answering agents and ensuring trunk/provider capacity for concurrent inbound calls. What is supported vs. not supported (quick table) • Your platform initiates calls and remains caller: Supported. • Cekura automatically answers inbound calls and runs simulated agents: Supported. • Preserving

run_id

,

scenario_id

via LiveKit job metadata / participant attributes: Supported. • Preserving arbitrary custom SIP headers end-to-end: Usually supported but depends on SIP trunk/provider; prefer job/participant metadata for reliability. • Need for an additional provider to “automate answering”: Not required if Cekura runs the answering agent and has a LiveKit inbound trunk/phone number; otherwise you may need a SIP provider to supply phone numbers/trunking. Next steps / clarifying questions for you • Do you plan to use LiveKit-managed phone numbers or a third‑party SIP trunk for Cekura’s inbound calls? • Will you pass correlation fields in SIP headers specifically, or do you prefer embedding them in LiveKit job/participant metadata? • What target concurrency (15, 30, or higher) and call duration do you expect so I can suggest scaling knobs (agent instances, trunk capacity, LiveKit region/instances)? If you want, I can provide a small example request snippet showing how to create the SIP participant with metadata and a short checklist for the Cekura inbound dispatch rule and agent entrypoint to read metadata. Sources: Outbound Calling Script | LiveKit Documentation | Agents telephony integration | LiveKit Documentation | Making calls overview | LiveKit Documentation | SIP Lifecycle Management Agent | LiveKit Documentation | examples/voice_agents | livekit/livekit_composite | DeepWiki, with interactive elements