Thanks — this is a great, concise problem statement and the checks you’ve already done are exactly the right ones. I’m responding to your questions about LiveKit SIP mistakenly classifying Twilio INVITEs as a flood and how to tune/disable flood protection. I don’t have your LiveKit version or current SIP flood-protection settings yet, and that information will be needed to give precise guidance. Could you please provide the following so I can narrow down next steps? 1. LiveKit server version (output of

livekit-server --version

or image tag). 2. Your SIP configuration (the

sip

section from your LiveKit config file or values you set via environment variables), especially any flood-related fields. 3. A short excerpt of SIP logs around an INVITE that was rejected as

486 flood

(timestamped lines showing the INVITE and the rejection). Redact any PII if needed. 4. Whether you’re running LiveKit behind a load balancer/proxy that might reuse connections or cause rapid re-INVITEs from the same source IP. 5. Whether Twilio sends multiple rapid INVITEs for the same call (if you can capture them) or whether you see one INVITE that’s rejected. While you gather that, here are immediate, safe troubleshooting steps and considerations you can try — they’re designed to confirm whether flood protection is the cause and to reduce false positives from Twilio: • Verify LiveKit version ◦ Different LiveKit releases may include tuning/bug fixes for SIP handling. If you’re not on a recent stable release, note that a version upgrade may already resolve the issue. • Confirm source IP behavior ◦ Ensure the SIP signaling source IPs in logs match Twilio’s published SIP trunking source ranges. If a proxy/load balancer is in front of LiveKit, it can change apparent source IPs or create many connections from a small set of IPs, which can trigger flood logic. • Temporarily increase flood thresholds (safe, short test) ◦ If your config exposes flood-control thresholds, raise them temporarily to see if calls then connect. Run tests for a short window and monitor carefully. ◦ If you don’t have per-source limits configured, note the behavior observed when thresholds are relaxed so we can tune permanently. • Check for retransmissions / transport mismatch ◦ Even if transport was aligned (TCP/UDP), network retransmissions or duplicated INVITEs (for example, due to UDP packet loss) can look like a flood. Capture a packet trace (tcpdump) for a failed call to confirm whether multiple INVITEs arrive in quick succession. • Preserve original source IP ◦ You already set externalTrafficPolicy: Local — confirm that any hostNetwork, NAT, or proxy layers also preserve source IP and that X-Forwarded-For is not being relied on for SIP source identification. • Inspect call flow from Twilio side ◦ Ask Twilio for their SIP signaling logs for the attempted call — confirm whether Twilio shows multiple INVITEs or errors toward the SIP target (this supports whether Twilio’s system is retrying). If you want me to suggest specific config changes, please share the version and the

sip

config (or flood-related fields). If you can also paste the relevant SIP log snippet (INVITE and the SIP 486/reason flood lines) I’ll analyze the timestamps and recommend exact tuning values or further steps to disable/adjust flood protection safely for Twilio trunks. I’m here to help walk through the log analysis and safe configuration changes once you share those details.