Thanks for reaching out, arijit. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

now I am getting a 404

Thanks — that screenshot and the 404 details are helpful. I’ll walk through what that 404 means, what to check next, and the exact diagnostics I need to pinpoint whether the INVITE reached LiveKit or was dropped before the SIP edge. What the 404 means (quick) • A SIP 404 Not Found means LiveKit received the INVITE but could not locate the destination (trunk/route/room) to handle it. Your first test returning 404 confirms the INVITE reached LiveKit at that time. • When subsequent calls show no SIP response at all, that usually means the INVITE did not reach LiveKit’s SIP edge (or was dropped before LiveKit could respond). Immediate checks you can do now 1. Confirm the inbound trunk exists and contains the phone number used by Twilio: ◦ Run:

lk sip inbound list

and verify the number is present. 1. Confirm the dispatch rule is present and points to that trunk and a valid room prefix or agent: ◦ Run:

lk sip dispatch list

and inspect the rule that references the trunk’s

sip_trunk_id

. 1. Re-test after a short wait: ◦ If you recently recreated the trunk/rule, wait ~3–5 minutes before testing again to allow state propagation. 1. Verify TwiML and SIP URI exactly match LiveKit’s expected format: ◦ Your TwiML should reference the LiveKit SIP destination (full host, optional port, and

;transport=tls

if using TLS). Example:

<Sip>sip:token@<your-project>.sip.livekit.cloud;transport=tls</Sip>

1. If using IP/credential restrictions, ensure Twilio’s outbound IPs (e.g.,

54.172.60.0

) are allowed in the trunk config. What I will check / what I need from you Please share the following so I can inspect logs and guide you precisely: • LiveKit project ID or agent ID and region/cluster (if available). • Exact timestamps (with timezone) for: ◦ The initial test that returned 404, and ◦ One or two subsequent tests that either returned “Failed” with no SIP response or another 404. • Twilio call SID(s) for those tests and any Twilio Debugger or SIP trace output you can export. • The full TwiML you returned (unredacted SIP URI host/port/transport). • Trunk configuration details in LiveKit: ◦ Auth type (credential / none), ◦ Auth username (if used), ◦ Whether the trunk shows active in the console/CLI. • The SIP Call ID shown in your screenshot:

15b537ac844fa27ca30f8b8b27eb4e15

(you already provided this — thanks). What I’ll do once you provide those items • Check LiveKit logs around the timestamps you give to confirm whether INVITEs reached the LiveKit SIP edge and what response LiveKit returned. • If INVITEs reached LiveKit, I’ll point to the exact SIP response and the likely misconfiguration (missing dispatch rule, mismatched number, host, or room). • If INVITEs did not reach LiveKit, I’ll recommend targeted network/TLS checks and Twilio-side settings to resolve the transit problem. Helpful extra tests (optional) • From any machine you control, test DNS/TLS to the SIP host used in your TwiML: ◦ `dig`/`nslookup` for the SIP host ◦

openssl s_client -connect <host>:<port> -servername <host>

(if using TLS) to check certificate/TLS handshake • Try a single test call using LiveKit Phone Numbers (if available to you) to rule out Twilio SIP dialing complexity. Thanks — if you paste the timestamps, call SIDs, and the exact TwiML/SIP URI you used, I’ll start with the logs and get back with what LiveKit saw and the next concrete steps to restore inbound calls. Sources: sip | livekit/livekit_composite | DeepWiki | Preserve caller ID during SIP transfers with Twilio | LiveKit | Agents telephony integration | LiveKit Documentation | Accepting calls overview | LiveKit Documentation | Say hello to improved Cloud analytics

Project: feather-8jcqksm6 (sandbox) Trunk config: { "sipTrunkId": "ST_3XvhUamhKgzN", "name": "twilio-programmable-voice-inbound", "numbers": ["+14694617341"] } No auth, no allowed_addresses, no allowed_numbers. Currently shows active in CLI. Dispatch rule: { "sipDispatchRuleId": "SDR_pQsxiD8QhdEU", "trunkIds": ["ST_3XvhUamhKgzN"], "rule": { "dispatchRuleIndividual": { "roomPrefix": "30175f6c-9219-40f9-893d-1ca4917d1c07_7c78db04-8607-416d-969b-ca8d0d5485f7_" } }, "roomConfig": { "agents": [{ "agentName": "sandbox_agent" }] } } Full TwiML returned to Twilio: <?xml version="1.0" encoding="UTF-8"?><Response><Dial><Sip username="twiml-feather" password="Feath3r-TwiML-2026">sip:+14694617341@feather-8jcqksm6.sip.livekit.cloud;transport=tls</Sip></Dial></Response> Test timestamps (IST, UTC+5:30): - ~15:30 IST (10:00 UTC) Feb 18 — 404 with credentials on TwiML, trunk had auth + number (freshly created ST_3XvhUamhKgzN) - ~15:33 IST (10:03 UTC) Feb 18 — 404 without credentials on trunk (auth removed), TwiML still has credentials Twilio Call SIDs (most recent 404 tests): - CA0dc5133a[...]045808ec21b646285 (child SIP leg) - CAb3e97b464edfc0f4d3bc803d9935f5d5 (child SIP leg) SIP Call ID from Twilio: 15b537ac844fa27ca30f8b8b27eb4e15@0.0.0.0 Note: We also have a working Elastic SIP Trunk setup for the same agent on a different number (+18444671810 via ST_m6RqgdgzCNnm). That works fine. The 404 only happens when routing via Twilio Programmable Voice <Dial><Sip>. Question: Could the <Sip> username/password attributes (still present in TwiML even when trunk has no auth) cause LiveKit to reject the call? Or is the 404 purely about trunk/number matching?

Thanks — this is very clear and useful. I reviewed the project/trunk/dispatch details you shared and the timeline of tests. Below I summarize what’s happening, answer your specific question, and give the exact next steps to get this fixed quickly. Quick conclusion • Yes — the `username`/`password` attributes in your TwiML can cause the SIP 404 you’re seeing. Even though your trunk currently has no auth configured, Twilio’s

<Sip username="..." password="...">

causes the outgoing INVITE to include credentials in the Authorization header. LiveKit’s SIP gateway can treat that as an unexpected/unauthorized authenticated request and respond with 404 (or otherwise reject it) before dispatch routing succeeds. • Evidence in your data: ◦ The initial 404 shows the INVITE reached LiveKit and LiveKit could not find a valid destination for that authenticated request. ◦ Your Elastic SIP trunk works because it uses IP-based trust without inline TwiML credentials — same agent, different transport/auth model. Why this happens (concise) • Twilio’s TwiML `username`/`password` yields an Authorization header on the INVITE. • If LiveKit is not configured to accept those credentials (no matching

auth

on the trunk), the SIP gateway may treat the request as unauthenticated/malformed and not match it to the trunk/dispatch rule, resulting in 404 Not Found. • When the TwiML has no credentials, Twilio sends a “clean” INVITE (no Authorization header) and LiveKit matches by number/trunk/dispatch rule (the same model that works for your Elastic trunk). Immediate action (what to change now) 1. Remove credentials from your TwiML and re-test: ◦ Replace your current TwiML with: <?xml version="1.0" encoding="UTF-8"?> <Response> <Dial> <Sip>sip:+14694617341@feather-8jcqksm6.sip.livekit.cloud;transport=tls</Sip> </Dial> </Response> • Wait ~3–5 minutes after changing TwiML or trunk settings, then place a test call. Verification & diagnostics I can help with Please run these and share results/timestamps if the issue persists: 1) Confirm trunk & dispatch again (CLI) •

lk sip inbound list

— confirm

ST_3XvhUamhKgzN

shows number +14694617341 and active. •

lk sip dispatch list

— confirm

SDR_pQsxiD8QhdEU

references

ST_3XvhUamhKgzN

and the roomPrefix. 2) Capture logs around your test (send me these) • Test time(s) in UTC (you already gave: 10:00 UTC and 10:03 UTC on Feb 18). • Twilio child SIP leg Call SIDs you listed (I have them): ◦ CA0dc5133a...646285 ◦ CAb3e97b464e...5d5 • SIP Call ID: 15b537ac844fa27ca30f8b8b27eb4e15 (you provided). 3) If the 404 persists after removing TwiML credentials: • Share the new test timestamp + call SID and I’ll check LiveKit logs for INVITE receipt and the exact SIP response. • If there is no SIP response (Twilio shows “Failed” with zero duration), we’ll run network/TLS checks next. Optional hardening (if you want credentials instead of IP trust) • If you need TwiML to include credentials, create a trunk with that credential set in LiveKit (auth enabled) that matches the username/password Twilio will send. Then Twilio’s Authorization header will match LiveKit’s expected credentials. • Or, use

allowed_addresses

to only accept Twilio’s SIP IP ranges (IP-based trust) and keep TwiML without credentials. Extra checks you can run (optional, helpful when no response) • DNS/TLS test from any server: ◦

dig feather-8jcqksm6.sip.livekit.cloud

◦

openssl s_client -connect feather-8jcqksm6.sip.livekit.cloud:5061 -servername feather-8jcqksm6.sip.livekit.cloud

• Confirm Twilio is not inserting credentials even when you remove them from TwiML (it won’t, but worth confirming). Summary / next step I recommend now • Remove the

username

and

password

from your TwiML and test again after 3–5 minutes. If that fixes it, we’re done. • If it still fails, send me the new test timestamp + Twilio call SID and I’ll pull the LiveKit logs for that exact moment and tell you whether the INVITE reached our SIP edge and what response LiveKit returned. You already gave the useful identifiers (project: feather-8jcqksm6, trunk ST_3XvhUamhKgzN, dispatch SDR_pQsxiD8QhdEU, SIP Call ID). If you want, paste the new test timestamp and call SID after you re-test without credentials and I’ll dig into the logs right away. Sources: Understanding TLS in SIP | LiveKit | sip | livekit/livekit_composite | DeepWiki

I have removed username and password still facing the issues

Thanks — I appreciate the detailed follow-ups and the screenshots. You’ve done the right steps so far (removed credentials, confirmed trunk active, dispatch rule present). Since you’re still seeing SIP 404s from LiveKit, let’s focus on the targeted diagnostics that will tell us exactly why LiveKit is rejecting the INVITE. What 404 means now • SIP 404 means the INVITE reached LiveKit but LiveKit could not find a matching destination (trunk/number/route) for that request. You already confirmed the INVITE arrives (Twilio shows a SIP Call ID and a 404), so this is a routing/matching issue on the LiveKit side rather than a network/TLS drop. Quick checklist (you likely already covered these) • Trunk ST_3XvhUamhKgzN is active and lists +14694617341. (You confirmed it shows active.) • Dispatch rule SDR_pQsxiD8QhdEU references that trunk and has a roomPrefix. (You provided that.) • TwiML now omits username/password. Good. Exact diagnostics I need from you (these will let me look up the exact log lines) 1) One new test after you read this: please make a fresh test call to the Twilio number now (or at a known time) and share: • Exact UTC timestamp of the call (e.g., 2026-02-18 100000 UTC). • Twilio child SIP leg Call SID for that attempt (Twilio gave those previously). • SIP Call ID shown in Twilio for that attempt. 2) From your side, run and paste the CLI outputs: •

lk sip inbound show --sip_trunk_id ST_3XvhUamhKgzN

(full JSON output) •

lk sip dispatch show --sip_dispatch_rule_id SDR_pQsxiD8QhdEU

(full JSON) •

lk agent logs --log-type=deploy --id=<agent-id> --since "<timestamp>"

for the test time (if you know the agent id). If you don’t know agent-id,

lk agent list

will show agents. What I’ll check once you provide those • Confirm the inbound trunk JSON includes the number exactly as E.164

+14694617341

and that there are no accidental characters or spaces. • Confirm the dispatch rule JSON shows the trunk ID in

trunkIds

and the

roomPrefix

you expect. • Search LiveKit logs for the SIP Call ID and timestamp to see the precise rejection reason. The logs will show whether LiveKit: ◦ matched the trunk but failed to route to a room/agent, ◦ rejected the request because the dialed number didn’t match any trunk, ◦ or rejected due to a mismatch in the SIP Request-URI / Host header. A few targeted checks you can do immediately • Confirm the inbound trunk number appears exactly as

+14694617341

(no brackets, no hidden characters). • Confirm the TwiML Dial->Sip uses the same full domain as in your trunk: sip:+14694617341@feather-8jcqksm6.sip.livekit.cloud;transport=tls ◦ If Twilio is truncating or altering the host header, that can prevent matching. • Check if any other trunk claims that number (unlikely, but possible in multi-tenant misconfiguration). If trunk and dispatch JSON look correct but 404 continues • I will look for log lines like “no trunk matched for request” or “dispatch not found” for the SIP Call ID/time you provide. That will tell us whether LiveKit searched for that number and couldn’t find it, or whether it found the trunk but the dispatch step failed. Optional quick test to isolate routing vs. identity: • If you can temporarily add an additional trunk with a different trunk id that also lists the number and a very simple dispatch rule (roomPrefix "test-"), try a call. If that routes, it indicates the original dispatch rule or its roomPrefix is the problem. If it still 404s, the problem is the number/trunk mapping or domain. If you want me to interpret the CLI JSON for you, paste those outputs and I’ll point out any mismatch (numbers, trunkIds, roomPrefix format, allowed_addresses, auth flags, etc.). Next actions I’ll take for you • Once you post one new test timestamp + call SID + SIP Call ID (and/or the CLI outputs), I’ll search logs for the exact INVITE handling and tell you: ◦ exactly why the 404 was returned (missing number, host mismatch, dispatch rule not applicable, or other), ◦ the minimal fix to apply (trunk update, dispatch update, domain correction, or adding allowed_addresses), ◦ and steps to re-test. Thanks — if you can paste: • One new test timestamp (UTC), • The Twilio child SIP leg Call SID for that test, • The outputs of the two

lk

show commands (or paste the JSON trunk/dispatch you already have), I’ll dive into the LiveKit logs and give a precise root cause and the exact config change to fix it. Sources: Accepting calls overview | LiveKit Documentation | sip | livekit/livekit_composite | DeepWiki