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.
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 Not Found (“The provided number does not appear to be a valid destination” per Twilio’s Insights). 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.
What I’ve already tried, all producing the identical 404:
Default global SIP endpoint (sip:aisec-retaryan-kknfy9fa.sip.livekit.cloud)
Same endpoint with ;transport=tcp appended (per your Twilio integration guide)
Deleting and fully recreating both the inbound trunk and dispatch rule from scratch (new IDs above) — identical failure on the very next call
The trunk and number are confirmed present and correctly configured via lk sip inbound list (numbers: [“+14249556304”], no restrictive allowed_addresses/allowed_numbers set).
@Haig_Khodiguian Your PCAP already narrows this. livekit/sip sends three different 404 reason phrases depending on where it fails: Does not match any SIP Trunks and No trunk found both mean trunk matching failed, while Does not match Trunks or Dispatch Rules means the trunk did match and it was the dispatch rule that didn’t. Twilio’s “not a valid destination” is their own wording, so the actual phrase in the 404 is the thing to read it tells you which half of the config to look at.
Two things you can already rule out: 161.115.181.152 sits inside 161.115.160.0/19, LiveKit’s published SIP range, so you’re reaching real SIP infrastructure rather than being misrouted. And the thread you linked turned out to be the Server URI being used instead of the SIP URI, which isn’t your case yours has .sip. in it.
If the phrase points at trunk matching, worth checking the exact To/request-URI number format Twilio sends against the +14249556304 on your trunk. Beyond that this needs someone with account access.
Confirmed via PCAP: the exact reason phrase is 404 No trunk found (trunk-matching failure). I also verified byte-for-byte that our trunk’s configured number (+14249556304) matches the INVITE’s Request-URI/To number exactly — no formatting mismatch. Trunk ID ST_yxfanM4UaHkF, freshly created, lk sip inbound list confirms it’s registered with that number. So the control plane has it right, but the SIP edge handling this call (161.115.181.152) isn’t finding it. That does look like it needs someone with backend/account access to check trunk propagation for this project.
Thanks for pointing me in the right direction…
@Haig_Khodiguian
That phrase narrows it more than it looks. No trunk found is AuthNoTrunkFound, and it’s set in exactly one place pkg/service/psrpc.go, only when the control plane returns the explicit error code SIP_TRUNK_AUTH_ERROR_NO_TRUNK_FOUND from the GetSIPTrunkAuthentication RPC:
case rpc.SIPTrunkAuthenticationError_SIP_TRUNK_AUTH_ERROR_NO_TRUNK_FOUND:
return sip.AuthInfo{ Result: sip.AuthNoTrunkFound, ... }, nil
So this isn’t the edge failing to match locally the edge asked the control plane and got that code back explicitly. Useful for whoever picks it up, since it points at that specific RPC rather than at edge behaviour.
One dimension that might be worth checking while you wait: that RPC sends From, FromHost, To, ToHost and SrcAddress. I can’t see what the control plane keys on from the open repo, but ToHost is sent, and you tried three different hostnames (global, ;transport=tcp, and us.sip.livekit.cloud). Since you’ve already confirmed the number byte-for-byte, pulling the exact Request-URI host out of the same PCAP is cheap and rules that one in or out.
and it looks like the same root cause.