Inbound BYOT SIP (Twilio): matches trunk (100 Processing) but no room/dispatch ever created — newly-created project

Telephony
1

Environment
Deployment LiveKit Cloud (not self-hosted)
Project WS subdomain atks-977p5cni (wss://atks-977p5cni.livekit.cloud)
SIP subdomain 977p5cni.sip.livekit.cloud
Region US Central
SIP provider Twilio Elastic SIP Trunk (BYOT)
livekit-agents 1.5.17 (Python)

Symptom

Every inbound PSTN call (Twilio → our LiveKit inbound trunk) receives SIP/2.0 100 Processing from the SIP frontend, then nothing — no 180/200/4xx — until the caller times out.

  • Twilio side: logs No Answer, duration=0, trunking-originating, To: sip:+18312739889@977p5cni.sip.livekit.cloud;transport=tcp
  • LiveKit side: Telephony → Calls shows “No results” — no call or room is ever created
  • Agent worker: registered, agent_name=mary-inbound, available — never receives a job
  • Outbound and console mode work fine; the agent runs end-to-end locally

Note: We already corrected the SIP host from the WS subdomain (atks-977p5cni.sip..., which returned 404 No trunk found) to the project-ID subdomain (977p5cni.sip...), per issues #583/#663. That changed the failure from 404 to this 100 Processing → hang.

Config (verified via API)

Inbound trunk ST_TVycxQihAMki

  • numbers=["+18312739889"]
  • allowed_addresses=[Twilio signaling ranges]
  • No auth
  • krisp_enabled=true

Dispatch rule

  • Type: Individual (per-caller room, prefix mary-call-)
  • room_config.agents=[{agent_name:"mary-inbound"}]
  • No inbound_numbers filter
  • Also tried a catch-all rule with empty trunk_ids — same result

Controlled proof that no room is created

Test 1 — raw SIP INVITE. Sent a single INVITE to 977p5cni.sip.livekit.cloud with To matching the trunk number, then polled ListRooms every second for 12 seconds:

INVITE sip:+18312739889@977p5cni.sip.livekit.cloud
  -> SIP/2.0 100 Processing
     Record-Route: sip:10.244.197.133:40004;sipfe;transport=tcp;lr
     Record-Route: sip:161.115.180.162:5060;sipfe;transport=tcp;lr
  (no further response for 12s)

ListRooms during those 12s: EMPTY at every poll — no room ever created

Test 2 — real Twilio call. With the worker running and ListRooms polled live every second throughout the call: the call landed (No Answer, dur=0, correct SIP subdomain) and zero rooms were created at any point. Single call, single worker — this is not a capacity or agent-join-latency situation.

What we’ve tried (all hang after 100 Processing)

  • Trunk variations: numbers-only; IP-only; numbers + IP; broad AWS /16 IP ranges
  • Dispatch variations: Individual vs Direct; explicit (room_config.agents + named worker) vs automatic; catch-all (empty trunk_ids)
  • Recreated trunk + rule many times; waited for propagation; worker kept available (load_threshold=1.0)

Ask

  1. Is SIP inbound dispatch fully enabled in the control plane for project atks-977p5cni?
  2. Is there a staged-rollout or feature-flag gate for inbound BYOT trunks on newly created projects?
  3. This looks like the DispatchNoRuleDrop silent-drop path (cf. livekit/sip #696) and the control-plane gap in #663/#592 — do server-side logs show why room creation doesn’t fire after 100 Processing?

Happy to share a PCAP or hop on a call.

2

Can you let us know a call ID (or IDs) for a failed call(s) please? It starts with SCL_, then we can look at why the call wasn’t answered.

Looking at your dashboard, I see some successful sessions, so I want to make sure I’m looking at the right thing

Also, your message was flagged and held for review because you ‘typed too fast’. Did you copy / paste your message from elsewhere? I’m just asking because I’d like to avoid false-positives on our community portal, clearly your question is not spam :slight_smile:

3

Thanks Darryn! And yes, I drafted the post offline and pasted it, that’s the “typed too fast” flag. So I guess it worked as intended.

Important clarification first: the successful sessions you see are from a LiveKit native number I provisioned as a workaround. +1 831 859 8007 (dispatch rule mary-native → agent mary-inbound). Those work perfectly. So the SIP infra is healthy on this project.

The failing calls are the Twilio BYOT trunk number +1 831 273 9889, inbound trunk ST_3QdKgrUWb3ky, dispatch rule SDR_gVk8snGAYpmz (Individual → mary-inbound).

Fresh SCL_ call IDs (just reproduced, both failed identically):

  • SCL_wyFNiAkrvQBC- 2026-06-11 10:25:15 UTC
  • SCL_Dm5RHtcNqU2A -2026-06-11 10:25:22 UTC

Both were raw INVITEs to 977p5cni.sip.livekit.cloud for +18312739889. Each returns SIP/2.0 100 Processing (so the trunk matches not a 404) and then nothing. no 180/200/4xx. Real carrier calls from Twilio behave identically: No Answer, duration=0, To sip:+18312739889@977p5cni.sip.livekit.cloud;transport=tcp.

Key signal: I polled ListRooms every second through the whole call. No room is ever created, and Telephony → Calls stays empty. Since the room never exists, no dispatch/agent can fire. This is a single-call / single-worker setup, so it’s not capacity or agent-join latency.

Tried on the BYOT trunk: numbers-only, IP-allowlist (Twilio ranges), numbers+IP, and a catch-all rule (empty trunk_ids), all hang at 100 Processing with no room. The same agent + same project answers fine on the native number, which is what points me at inbound BYOT dispatch specifically.

4

Unless I’m missing something obvious (which is possible), it looks like the calls should have matched your trunk ST_3QdKgrUWb3ky. Do you have any logs from the Twilio side for this? The last thing I see from our side is an attempt to authenticate the trunk but I don’t see a response. This would explain why you’re not seeing any rooms, because it’s not getting as far as the dispatch rules.

5

I responded via email, but do not see the answer where, so I am also copying here, apologies if it is a duplicate:

hanks Darryn, that’s a really helpful clue, and it lines up exactly with issue #592’s second root cause: Twilio Elastic SIP Trunking (like Telnyx) doesn’t respond to SIP digest auth challenges (407), so if LiveKit is challenging the call, it stalls before ever reaching the dispatch rules, which matches the “auth attempt, no response, no rooms” you’re seeing.

For context, our inbound trunk ST_3QdKgrUWb3ky is currently numbers-only, with no auth_username/auth_password and no allowed_addresses. So we’re not setting any credentials. My guess is that with neither an IP allowlist nor auth configured, LiveKit falls back to challenging the source to establish identity, and Twilio never answers it.

Twilio-side logs: I’m attaching our full Twilio voice logs (CSV). The SIP Call-ID column should let you correlate directly to your side. These are real carrier-originated failed calls, all From +17734191341, To sip:+18312739889@977p5cni.sip.livekit.cloud;transport=tcp, No Answer, duration=0. A few to start with:

Twilio Call SID | SIP Call-ID (correlate on this) | Start (UTC)

CA17ce2e2a5f865bb44cac589f031cd753 | deb950b6b7ea6ad8e8074f6249de94a6 | 2026-06-10 16:07:27

CA17aad9d2b424fac15d0c4e688084bf95 | 79a9a72cb3ce80664e2a4421915c4914 | 2026-06-10 15:43:00

CAd7daa4a29f8814c6878c41a063d5fe35 | ad3d55dfad72993eb62d55dab84b529d | 2026-06-10 15:41:52

CAf18949038abb261649cab177aa6bb5b1 | 6be6ed532c4f8004a311e4e2d3da30da | 2026-06-10 15:40:31

CA1901ebe4f67afef123e516e00f928563 | eb26f26b6b4baca13644dff74cf62578 | 2026-06-10 15:23:42

A couple of things visible in the logs: earlier calls to atks-977p5cni… show Failed (the 404 before we corrected the SIP subdomain to 977p5cni…), and the ones to 977p5cni… show No Answer (the 100-Processing hang). There’s also one Incoming / Completed / 6s row, which is a TwiML test confirming the number itself answers fine. (Twilio’s SIP Call-ID host shows as @0.0.0.0 on their side.)

The one thing that would unblock this: what source IP do you see for the INVITE on these calls? We genuinely struggled to pin Twilio’s exact egress IP from our side (their API doesn’t surface the SIP response or source on our tier, since Voice Insights returns 404 without the Advanced add-on). If you give me the IP, I’ll add it to ST_3QdKgrUWb3ky’s allowed_addresses right away so LiveKit authenticates by source IP and skips the 407 challenge, the #592 resolution.

Happy to place a fresh live call at a time you specify if that’s easier to trace.

Thanks again for digging in

6

Looks like you are using the wrong SIP URI. What you have there appears to be the Project URL rather than the SIP URI.

7

That was the solve. Thank you!