Need Backend help for AI Agent Launch

Client SDKs
1

Hi, I’m hitting a persistent SIP 404 on every inbound call through my Twilio Elastic SIP Trunk into LiveKit Cloud, and I’ve ruled out everything on the Twilio/config side. Would appreciate help looking at the backend.

Project SIP host: aisec-retaryan-kknfy9fa.sip.livekit.cloud

Current inbound trunk: ST_yxfanM4UaHkF (numbers: +14249556304) Dispatch rule: SDR_hQJZXSM3W6eK (automatic dispatch, roomPrefix “call-”, no agent restriction)

Symptom: Every SIP INVITE from Twilio to this trunk gets an immediate 404. I pulled the actual SIP PCAP (not just Twilio’s paraphrased Insights text) and the literal reason phrase is:

SIP/2.0 404 No trunk found

which per your own reason-phrase conventions means trunk-matching failed specifically (as opposed to “Does not match Trunks or Dispatch Rules”, which would point at the dispatch rule instead). Twilio’s side confirms this is a real SIP-level response from your infrastructure, not a timeout — signaling IPs show a clean connection to 161.115.181.152, with a 0-second post-dial delay before the 404 comes back.

I’ve ruled out a formatting mismatch: the INVITE’s Request-URI/To number is +14249556304; lk sip inbound list --json shows the trunk’s configured number as the exact same string at the byte level (b'+14249556304', no hidden whitespace/encoding difference). So the control plane has the trunk registered correctly, but the SIP edge that answered this call doesn’t see it.

What I’ve already tried, all producing the identical 404 No trunk found:

  1. Default global SIP endpoint (sip:aisec-retaryan-kknfy9fa.sip.livekit.cloud)
  2. Same endpoint with ;transport=tcp appended (per your Twilio integration guide)
  3. Region-pinned endpoint (sip:aisec-retaryan-kknfy9fa.us.sip.livekit.cloud;transport=tcp)
  4. Deleting and fully recreating both the inbound trunk and dispatch rule from scratch (new IDs above) — identical failure on the very next call
  5. Creating a second, completely separate LiveKit Cloud project (aigent-hvacson-d94y0mb8.sip.livekit.cloud, trunk ST_vm6f9wj99tR6, dispatch rule SDR_CbjF9FKhrETG) and pointing the same Twilio trunk’s origination at it — identical 404 on the very first call (Call SID CA9c3a5cf8c745e9733b25155a98662973)
  6. Setting the trunk’s numbers to digits-only with no + (14249556304 instead of +14249556304), on the theory that the edge parser byte-matches raw digit strings — tested live on trunk ST_vm6f9wj99tR6, identical 404 No trunk found, then reverted back to +14249556304 (the format used in your own published example configs)

That last one rules out per-project corruption: two independently-created, freshly-provisioned projects under the same account both fail identically. Since project-level state is now ruled out, the one constant is the account itself. Is there an account-level SIP/telephony activation, billing verification, or approval step that hasn’t completed? That would explain why trunk objects create successfully via API/dashboard (control plane) on both projects, while the SIP edge never actually routes to either of them.

I found a community thread describing a similar-looking symptom, but that one turned out to be the Server URI being used instead of the SIP URI — not my case, since mine already targets .sip.livekit.cloud: SIP 404 "No trunk found" — DNS routing mismatch on LiveKit Cloud

Evidence available:

  • Twilio Call SIDs reproducing this: CA21e3080b6eb8168bf3b3ba479a89a944, CA91cbec5558b1b809abff221377d6202b, CA8a42a365f041e5a7b752331a2dcc822e (the one the PCAP above is from)
  • Full SIP PCAP for CA8a42a365f041e5a7b752331a2dcc822e available from Twilio’s Call Details page — can send directly if useful.

Twilio account SID: AC810fc26b89c708ed0a4139120692bf22 / Trunk SID: TK6c266eb0924dfeaa9dabbdd8ed5226f1

Happy to provide anything else needed to debug this. Thanks!

2

Your account-level theory is consistent with the protocol, and one part of it can be excluded outright.

GetSIPTrunkAuthenticationResponse.error_code is a SIPTrunkAuthenticationError, and that enum has exactly three values:


  enum SIPTrunkAuthenticationError {
    SIP_TRUNK_AUTH_ERROR_NONE = 0;
    SIP_TRUNK_AUTH_ERROR_QUOTA_EXCEEDED = 1;
    SIP_TRUNK_AUTH_ERROR_NO_TRUNK_FOUND = 2;
  }

There’s no distinct code for “SIP not enabled on this account”, “provisioning incomplete” or similar. So if such a state exists, it has nowhere to go except NO_TRUNK_FOUND meaning the 404 you’re getting genuinely cannot distinguish “this trunk doesn’t exist” from “this account can’t route SIP yet”. Two freshly-provisioned projects failing identically fits that reading.

The billing branch of your hypothesis is ruled out though: AuthQuotaExceeded maps to 503 Service temporarily unavailable, not 404


  case AuthQuotaExceeded:
      cc.RespondAndDrop(sip.StatusServiceUnavailable, "Service temporarily unavailable")

so a quota or spend limit would look different from what you’re seeing.

One concrete thing for whoever picks this up: the same auth response carries a per-project feature_flags map alongside error_code. Between that and the NO_TRUNK_FOUND returned for a ToHost/To pair that demonstrably exists in the control plane on two separate projects, that’s a fairly narrow place to look.

3

Is this the same as: