https://livekit.io logo
Join Slack
Powered by
Subject: Twilio outbound SIP → LiveKit — PSTN ring...
# ask-ai
a
Subject: Twilio outbound SIP → LiveKit — PSTN rings / silence; SIP seems to join wrong room vs 
call-{uuid}
from our app Setup • Backend (FastAPI) on dispatch creates LiveKit room 
call-{call_id}
(
call_id
= UUID), then 
CreateAgentDispatch
for agent 
vacancy-caller
with JSON metadata (same payload as 
/dispatch
). • Twilio outbound call uses TwiML: 
<Dial answerOnBridge="true"><Sip>sip:call-{same-uuid}@{OUR_LIVEKIT_SIP_DOMAIN}</Sip></Dial>
(
TWILIO_SIP_DOMAIN
= 
*.sip.livekit.cloud
). Symptom • Outbound PSTN leg rings; when we answer, we getcontinued ring / dead air, not the agent. • In agent logs we seetwojobs sometimes: ◦ `call-{uuid}`— has metadata, agent starts, Gemini connects. ◦ `call-_+1…`(caller-ID style) —empty metadata, we skip (no`/dispatch`payload). Dispatch rule (dashboard) • Was`Individual`with destination pattern`call-<caller-number>`; we experimented with`call`prefix / templates — still unclear how to force inbound SIP into`call-{uuid}`matching theSIP URI user partTwilio dials. Ask 1. For Twilio → LiveKit SIP bridging an outbound 
<Sip>
to 
sip:call-{uuid}@project.sip.livekit.cloud
, what dispatch rule (type + fields) should we use so the SIP participant lands in 
call-{uuid}
(same room our backend created), not 
call-{caller}
? 2. Anything Twilio-side we must verify (INVITE 
To
/ trunk / origination) per community troubleshooting (
To
must be full SIP URI host, not 
@IP
, duplicate E.164 variants, etc.)? 3. If Individual rules only key rooms off caller, is there a supported pattern today for callee / Request-URI username routing for this Twilio bridge? Project • LiveKit Cloud project SIP URI:`sip:{PROJECT}.sip.livekit.cloud`(fill in your actual subdomain).
✅ 1
t
Thanks for reaching out, Mark. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’m replying about your three asks: (1) which dispatch rule to use so Twilio’s outbound SIP to sip:call-{uuid}@project.sip.livekit.cloud lands in the pre-created room, (2) what to verify on Twilio side, and (3) whether callee / Request-URI username routing is supported. Short answers • Use a callee-based dispatch rule (SIPDispatchRuleCallee with room_prefix "call-") so the Request-URI user part (
call-{uuid}
) maps to the same room your backend created. • Verify Twilio sends the full SIP Request-URI/To header (sip:call-{uuid}@{PROJECT}.sip.livekit.cloud) and consistent E.164 formats; confirm trunk auth succeeds. • Yes — callee/Request-URI username routing is supported today and is the correct pattern for your use case. What to change (recommended) 1. Replace your Individual rule with a callee dispatch rule that matches the dialed user part: ◦ Create a SIPDispatchRuleCallee with 
room_prefix: "call-"
. ◦ This will use the user portion of the Request-URI (what Twilio dials) as the room name, so 
sip:call-{uuid}@...
→ joins 
call-{uuid}
. 1. Ensure the LiveKit room exists before Twilio dials (your backend already creates 
call-{uuid}
— keep that). Twilio-side checks to run • Confirm the INVITE’s Request-URI and To header use the full SIP URI host, not an IP: To: sip:call-{uuid}@{PROJECT}.sip.livekit.cloud • Ensure Twilio’s Sip noun is using the full domain (you showed 
@{OUR_LIVEKIT_SIP_DOMAIN}
— that’s correct). • Confirm the From and any caller-ID values are consistent (E.164 formatting) and avoid duplicate variants (+1 vs 1). • Check trunk authentication/credentials and that Twilio’s INVITE reaches the LiveKit SIP domain without header rewrites. • Use Twilio debug/SIP logs to inspect the actual INVITE headers (Request-URI, To, From). Why you saw call-{caller} rooms and empty metadata • 
SIPDispatchRuleIndividual
keys rooms off the caller number; that’s why you saw 
call-_+1…
rooms with no metadata. Individual rules do not route from the Request-URI username. Switching to callee-based routing fixes that. If you want, I can: • Show the exact API payload / sample code to create a SIPDispatchRuleCallee for your project, or • Review a captured Twilio INVITE (headers) if you paste it here to confirm what’s being sent. Sources: Agents telephony integration | LiveKit Documentation | Layered Caller Verification for LiveKit SIP Calls | LiveKit | Making calls overview | LiveKit Documentation, with interactive elements
3 Views
Open in Slack
PreviousNext
Powered by