Inbound Twilio SIP reaches LiveKit edge but never creates a room — auth and allowlists ruled out

Telephony
, ,
1

I’m debugging an inbound Twilio Programmable Voice → LiveKit Cloud SIP → LiveKit Agents path for a canary-only project.

Project dashboard: https://cloud.livekit.io/projects/p_48jyzhypsa7/overview

The intended inbound destination is the… 0405. The internal canary caller is …6807. No credentials are included here.

What works independently:

  • Direct LiveKit agent dispatch creates a room and an agent participant successfully; the observed test room remained active for approximately 49 seconds.
  • Hume works independently through its API and returns audio.
  • The production worker and LiveKit agent worker are both active.
  • The tenant is explicitly configured for canary-only LiveKit mode, with Hume primary and Retell fallback.

What fails:

Twilio calls to …0405 receive initial SIP progress and then time out without a connected call. In earlier attempts, the Twilio trace showed 100 Processing followed by silence and no final SIP response.

For the latest unrestricted test on 2026-07-20:

  • UTC window: 13:54:14–13:54:52.
  • Twilio parent CallSid: CA078c…a9c824
  • Twilio SIP-leg CallSid: CA5a2…479cb7
  • Twilio SIP-leg status: no-answer, duration 0, dial_bridged=false.
  • Twilio sent the INVITE to the exact full destination:
    sip:+…5@5z…8.sip.livekit.cloud;transport=tcp
  • Twilio returned no SIP final response code and generated no call notification.
  • LiveKit created no room, no SIP participant, and no agent job.
  • The fixed canary dispatch rule was not exercised.

Bisection tests:

  1. Auth enabled, dedicated trunk, no IP or caller allowlist: failed.
  2. Auth disabled, dedicated trunk, caller restricted to…6807: failed identically.
  3. Auth disabled, dedicated trunk, no IP or caller allowlists: failed identically.

The active inbound trunk is:

  • Trunk ID: ST_…XFDk
  • Numbers: […0405]
  • allowed_addresses: empty
  • allowed_numbers: empty during the unrestricted test
  • Authentication has now been restored from the canonical production configuration.

The only dispatch rule is:

  • Dispatch rule ID: SDR…Hwe89i
  • Trunk: ST_zw…XFDk
  • Direct room: …-canary-room

The previous restricted auth-off test ran at 13:52:07–13:52:46 UTC and also produced no room. Its Twilio outbound CallSid was CAc1…ef69c8dd.

Could someone inspect the LiveKit Cloud SIP edge trace for these UTC windows and confirm:

  1. Whether the INVITEs reached the inbound trunk matcher.
  2. Which To, From, source, and transport fields LiveKit observed.
  3. Why LiveKit sends 100 Processing but no final response.
  4. Whether flood protection, edge filtering, project-region routing, or an internal trunk/dispatch association issue is involved.
  5. Whether a PCAP is available for either failed call.

The configuration is currently restored to authenticated canary mode.

2

You did not inlucde the full SIP URI you are using for your LiveKit account but that does not look right to me. You can find it here https://cloud.livekit.io/projects/p_/settings

3

@Neil_Stewart, Agreeing with the SIP-URI direction: the host is the deciding piece. Twilio’s Origination URI has to point at your project’s exact SIP host from Settings, as

sip:<your-project-host>.sip.livekit.cloud;transport=tcp

(Twilio trunk setup). If the host in the INVITE (5z…8.sip.livekit.cloud) is not your project’s current host, the call reaches a LiveKit SIP edge (the 100 Trying) but not your project’s trunk matcher, so no trunk matches and no room is created. That fits “100 then silence, no room, no participant” and is why toggling auth and allowlists changed nothing.

Worth checking the host character-for-character against Settings. Also allowed_numbers filters the caller number and allowed_addresses is a source-address allowlist (inbound trunk), so neither would explain a total no-final.

4

Thanks for the quick reply haven’t gotten a chance to test it but thank you