for inbound calls, lets say i want to have somethi...
# ask-aii
important-judge-78504
03/30/2026, 3:17 PMfor inbound calls, lets say i want to have something in between twilio and my livekit worker, that gets the inbound call request, and runs some custom code to determine if it should be routed to my livekit worker or somewhere else, whats the best way to do that
✅ 1
t
tall-airline-16756
03/30/2026, 3:18 PMThanks for reaching out, Ed. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
tall-airline-16756
03/30/2026, 3:19 PMThanks — that’s a great question. You want a layer between Twilio and your LiveKit worker that receives Twilio’s inbound call, runs custom logic, and then either routes the call to LiveKit or somewhere else. Here are practical approaches, the trade-offs, and a recommended path.
Quick answer (recommended)
• Use a TwiML webhook middleware: point your Twilio phone number to a webhook you control, run your routing logic there, and return TwiML that either dials your LiveKit SIP endpoint or sends the call elsewhere. This is the simplest, most flexible approach and keeps Twilio as the telephony entry point.
Why this is usually best
• Full control: you receive the call metadata (caller, called number, headers) and can run DB lookups, feature flags, fraud checks, business rules, scheduling, etc., before deciding.
• Simple to implement and maintain.
• No call touches your LiveKit worker unless you decide to route it there.
Other options (when to consider them)
• SIP proxy/middleware
◦ Use if you need SIP-level control (header manipulation, advanced SIP routing) or must support multiple SIP providers.
◦ More complex to build and operate than a webhook.
• LiveKit-centric dispatch with external logic
◦ Route calls into LiveKit first, then use LiveKit webhooks to run logic and transfer/disconnect calls.
◦ Simpler if LiveKit must always receive the call, but inefficient when most calls should be handled elsewhere because the call briefly connects to LiveKit.
Implementation outline (TwiML webhook approach)
1. Configure your Twilio number’s Voice webhook to point to your server endpoint (e.g., /voice).
2. When Twilio posts an inbound call, your endpoint:
◦ Extracts relevant fields (From, To, SIP headers if available).
◦ Runs your custom logic (DB checks, routing rules, ML model, etc.).
◦ Returns TwiML that either:
▪︎ Dials a LiveKit SIP endpoint: DialSipsip:your-livekit-sip-endpoint/Sip/Dial
▪︎ Or routes to another SIP endpoint, voicemail, IVR, or returns a message.
1. Optionally log the decision and call metadata for auditing and retries.
Minimal example (concept)
1. Twilio → POST /voice on your service
2. Your service:
◦ shouldRouteToLiveKit = yourRoutingLogic(request)
◦ If true: return TwiML to Dial to LiveKit SIP
◦ Else: return TwiML to Dial elsewhere or voice response
Things to confirm / suggested follow-ups
• Do you plan to connect to LiveKit via SIP (LiveKit’s SIP gateway) or through another LiveKit integration? If SIP, I can show TwiML examples that dial directly to the LiveKit SIP URI.
• Do you need SIP header manipulation, custom codecs, or low-level SIP features? If yes, a SIP proxy might be needed.
• Do you want the middleware to be synchronous (return TwiML immediately) or to make async decisions (e.g., call screening that requires human review)? If async, we can discuss hold music / voicemail strategies and how to bridge once decision completes.
If you confirm how you plan to connect to LiveKit (SIP endpoint vs other), I’ll provide a short TwiML example and a starter code snippet for your webhook.
Sources: Accepting calls overview | LiveKit Documentation | Agents telephony integration | LiveKit Documentation | Best practices for managing webhook event streams | LiveKit, with interactive elements
i
important-judge-78504
03/30/2026, 3:28 PMso instead of pointing the phone number to livekit sip URI i point it to a webhook? if the request to livekit comes from the twiml, will the dispatch rule still fire?
t
tall-airline-16756
03/30/2026, 3:29 PMGood question — I’m responding to your two points: (1) whether you can point the phone number to a webhook instead of LiveKit’s SIP URI, and (2) whether LiveKit’s dispatch rules still fire when the webhook returns TwiML that then calls LiveKit.
Short answer
• Yes — you can point the Twilio phone number to your webhook instead of directly to the LiveKit SIP URI.
• No — dispatch rules will not automatically fire just because TwiML later dials LiveKit’s SIP URI. Dispatch rules only run when LiveKit receives or initiates a SIP call via its trunks. To have dispatch rules applied after your webhook decision, you must explicitly create the SIP participant through LiveKit’s API (e.g., CreateSIPParticipant) or initiate the call from LiveKit so the LiveKit-side trunk and dispatch logic run.
Why this matters
• Pointing the number to a webhook gives you full control (screening, DB checks, ML, routing rules) before any LiveKit involvement.
• If you simply have TwiML perform a SIP Dial to a LiveKit SIP URI, that incoming SIP INVITE arrives as a regular inbound SIP call — but LiveKit’s dispatch system won’t necessarily match the same flow that would run when LiveKit itself created the participant via its trunks. The dispatch rules are tied to how calls are created/received on the LiveKit trunk.
How to get the dispatch behavior you want
• Option A — Use your webhook to call LiveKit’s API to create a SIP participant (recommended if you want dispatch rules to run):
a. Twilio → webhook receives inbound call.
b. Your webhook runs custom logic and decides to route to LiveKit.
c. Your webhook calls LiveKit’s CreateSIPParticipant (or the equivalent outbound initiation) — when LiveKit creates/initiates the SIP leg, dispatch rules associated with that trunk will apply and agents/rooms will be matched.
d. LiveKit connects the call according to the dispatch rule.
• Option B — TwiML Dial to LiveKit SIP URI directly:
◦ Simpler, but dispatch rules will not automatically run in the same way. Useful if you only need a plain SIP bridge into LiveKit without dispatch-driven agent/room assignment.
• Option C — Use LiveKit dispatch-first:
◦ If you want LiveKit to always control routing, point Twilio directly to LiveKit’s SIP URI and let LiveKit’s inbound dispatch rules handle everything. You lose your webhook pre-checks in that case.
Questions to help me give exact steps
• Do you want dispatch rules (agent/room routing) to run when the call is accepted? If yes, I’ll show the CreateSIPParticipant flow.
• Are you planning to connect via LiveKit’s SIP gateway/trunk (SIP URI) or another integration?
• Do you want the decision logic synchronous (immediate) or could it be async (hold music while human review happens)?
If you confirm how you plan to connect (SIP trunk vs other) and whether you need dispatch rules to run, I’ll provide a short example: either a TwiML + LiveKit API flow (CreateSIPParticipant) or a TwiML Dial example.
Sources: Accepting calls overview | LiveKit Documentation | Agents telephony integration | LiveKit Documentation | sip | livekit/livekit_composite | DeepWiki | examples/voice_agents | livekit/livekit_composite | DeepWiki, with interactive elements
3 Views