https://livekit.io logo
Join Slack
Powered by
I'm currently trying to set up a self-hosted LiveK...
# ask-ai
h
I'm currently trying to set up a self-hosted LiveKit (server, agent, and SIP) and integrate it with an inbound call from my Twilio number. The service stack seems to be running, but every time I attempt an inbound call, the LiveKit SIP service immediately closes the call with a 486 "flood" error. The Issue & Log Evidence The SIP service successfully receives the 
INVITE
but rejects it seconds later. • Key Log Line: The call is closed with status 486 and reason "flood". This points to an internal rate-limiting mechanism being triggered in the LiveKit SIP component. Code snippet:
Copy code
livekit-sip | 2025-11-08T18:02:56.280Z INFO sip sip/inbound.go:782 Closing inbound call {"nodeID": "...", "callID": "SCL_bpEBHK2W5LmX", "fromIP": "...", "fromHost": "...", "status": 486, "reason": "flood"}
My Setup Context • LiveKit Components: Self-hosted LiveKit Server, Agent, and SIP. • Call Origin: An inbound call originated from Twilio (which then connects to my SIP endpoint). • Error Cause: The log suggests the call is being rejected for perceived "flooding," even if it is a single legitimate call attempt. Is there a specific configuration or environment variable in the LiveKit SIP service that controls the inbound call rate-limiting (e.g., calls per second from a single IP)? Or any solution for this? Thanks!
t
Thanks for reaching out, Ayush. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I see you're getting a 486 "flood" when an inbound Twilio call reaches your self-hosted LiveKit SIP and the service accepts the INVITE then closes the call. That log line indicates LiveKit's SIP flood-protection (rate limiting) is being triggered. What you can do • Increase the inbound rate limits by setting these environment variables for the 
livekit-sip
service: ◦ 
LIVEKIT_SIP_INBOUND_RATE_LIMIT
— max inbound calls per second from a single IP. ◦ 
LIVEKIT_SIP_INBOUND_BURST_LIMIT
— allowed burst above the rate limit. • Example:
Copy code
LIVEKIT_SIP_INBOUND_RATE_LIMIT=5
  LIVEKIT_SIP_INBOUND_BURST_LIMIT=10
Then restart the 
livekit-sip
service. Other checks to try if increasing limits doesn't help • Ensure Twilio isn't repeatedly sending retries (check Twilio call logs). Retries can look like a flood. • Confirm your firewall/NAT isn't causing multiple source IPs or rapid reconnects from Twilio's side. • If you have multiple proxies or load balancers, ensure client IPs are preserved so rate limiting sees Twilio’s IP correctly. Quick diagnostic question • After you increase the limits and restart, does the same single inbound call still hit 486? If yes, share a few more log lines around the INVITE and any subsequent SIP messages so I can help pinpoint whether retries, multiple source IPs, or another condition is triggering the flood protection. Sources: sip | livekit/livekit_composite | DeepWiki
h
This is my exact logs
Copy code
2025-12-22T11:14:13.048Z        DEBUG   sip     sip/inbound.go:434      Rejecting inbound flood {"nodeID": "NE_voLD4FPtmrxv", "callID": "SCL_WVYyXcdHHaej", "fromIP": "<http://129.XXX.XXX.XXX|129.XXX.XXX.XXX>", "toIP": "<http://34.XXX.XXX.XXX:5060|34.XXX.XXX.XXX:5060>", "fromHost": "<http://XXXXXXXXX.pstn.exotel.com|XXXXXXXXX.pstn.exotel.com>", "fromUser": "+917597XXXXXX", "toHost": "<http://34.XXX.XXX.XXX|34.XXX.XXX.XXX>", "toUser": "sip-server", "sipTag": "as5e2c1d3e", "sipCallID": "<mailto:XXXXXXXXX@tsep.mum1.exotel.com|XXXXXXXXX@tsep.mum1.exotel.com>", "jitterBuf": false}
t
Thanks — I see the exact log showing Rejecting inbound flood with the Twilio/Exotel source IP and SIP Call-ID. That confirms the SIP component is treating this incoming INVITE as a flood from that source. Next steps so I can help quickly 1. Did you already set 
LIVEKIT_SIP_INBOUND_RATE_LIMIT
and 
LIVEKIT_SIP_INBOUND_BURST_LIMIT
on your 
livekit-sip
container? If not, please set them (example below) and restart `livekit-sip`:
Copy code
LIVEKIT_SIP_INBOUND_RATE_LIMIT=5
   LIVEKIT_SIP_INBOUND_BURST_LIMIT=10
1. If you already set them, tell me the current values. If the flood persists after increasing limits, please provide: • A few more log lines around the INVITE (10 seconds before and after) so I can see retries or subsequent SIP messages. • Whether your SIP endpoint is behind a proxy/load balancer or NAT (and whether X-Forwarded-For / preserved client IPs are configured). • Twilio/Exotel call logs showing retry attempts or timing, if available. With those details I'll pinpoint whether retries, multiple source IPs, or another condition is triggering the flood protection and recommend the exact config change.
h
This is my docker-compose.yaml file in livekit-sip VM. Can you share the yaml with updated config?
Copy code
cat docker-compose.yaml
version: "3.9"
services:
  sip:
    image: livekit/sip
    network_mode: host
    environment:
      SIP_CONFIG_BODY: |
        api_key: "XXX"
        api_secret: "XXX"
        ws_url: "<wss://XXX.XXXX.com>"

        redis:
          address: "XX.XX.XX.XX:XXXX"

        sip_port: 5060
        rtp_ports:
          - 10000
          - 20000

        use_external_ip: true

        logging:
          level: debug
        flood_protection:
          enabled: false

        sip:
          inbound:
            enabled: true
            trunks:
              - name: exotel-inbound
                allow_unauthenticated: true
                allowed_addresses:
                  - XX.XX.XX.XX/XX
                destinations:
                  - type: room
                    room: inbound-calls
t
Thanks — I reviewed your compose and logs. Below is an updated docker-compose.yaml for the 
livekit-sip
VM that explicitly sets the inbound rate-limit and burst variables and keeps your existing SIP config. I left 
flood_protection.enabled
in the YAML as false (since you had it), but the rate-limit env vars are the primary controls used by the SIP service. Notes: • Set 
LIVEKIT_SIP_INBOUND_RATE_LIMIT
to the calls-per-second you want per source IP and 
LIVEKIT_SIP_INBOUND_BURST_LIMIT
to allow short bursts. • After deploying, restart the 
sip
service and test an inbound call. If you still see 486, share logs around the INVITE (10s before/after) so I can check for retries or multiple source IPs. Updated docker-compose.yaml:
Copy code
version: "3.9"
services:
  sip:
    image: livekit/sip
    network_mode: host
    environment:
      # Rate limit controls (adjust as needed)
      LIVEKIT_SIP_INBOUND_RATE_LIMIT: "5"
      LIVEKIT_SIP_INBOUND_BURST_LIMIT: "10"

      SIP_CONFIG_BODY: |
        api_key: "XXX"
        api_secret: "XXX"
        ws_url: "<wss://XXX.XXXX.com>"

        redis:
          address: "XX.XX.XX.XX:XXXX"

        sip_port: 5060
        rtp_ports:
          - 10000
          - 20000

        use_external_ip: true

        logging:
          level: debug

        flood_protection:
          enabled: false

        sip:
          inbound:
            enabled: true
            trunks:
              - name: exotel-inbound
                allow_unauthenticated: true
                allowed_addresses:
                  - XX.XX.XX.XX/XX
                destinations:
                  - type: room
                    room: inbound-calls
If you prefer to disable flood protection entirely (not recommended for public endpoints), set 
flood_protection.enabled: false
as you already have, and consider whitelisting the provider IP range under 
allowed_addresses
. Tell me the values you set or paste new logs if the issue persists.
h
I have set the suggested values in LIVEKIT_SIP_INBOUND_RATE_LIMIT and LIVEKIT_SIP_INBOUND_BURST_LIMIT still got this error
Copy code
2025-12-24T09:09:47.121Z        DEBUG   sip     service/service.go:111  starting service        {"nodeID": "NE_HBAZdZ8zZD7P", "version": "0.0.1"}
2025-12-24T09:09:47.122Z        DEBUG   sip     service/service.go:145  service ready   {"nodeID": "NE_HBAZdZ8zZD7P"}
2025-12-24T09:09:47.121Z        DEBUG   begin listening on      {"nodeID": "NE_HBAZdZ8zZD7P", "caller": "transport<TCP>", "net": "TCP", "addr": "[::]:5060"}
2025-12-24T09:10:11.632Z        DEBUG   Server transaction terminating  {"nodeID": "NE_HBAZdZ8zZD7P", "caller": "transaction.Layer"}
2025-12-24T09:10:11.632Z        DEBUG   Server transaction destroyed    {"nodeID": "NE_HBAZdZ8zZD7P", "caller": "transaction.Layer", "tx": "41380033__Call-ID: 5293190861@10.140.0.5__OPTIONS__1__Via: SIP/2.0/UDP 10.140.0.5:50361;branch=DuHbyf.1891808257;rport;alias__"}
2025-12-24T09:12:03.572Z        DEBUG   New connection  {"nodeID": "NE_HBAZdZ8zZD7P", "caller": "transport<TCP>", "raddr": "129.154.231.198:42823"}
2025-12-24T09:12:03.574Z        DEBUG   Getting connection      {"nodeID": "NE_HBAZdZ8zZD7P", "caller": "transport<TCP>", "addr": "129.154.231.198:42823"}
2025-12-24T09:12:03.577Z        INFO    sip     sip/inbound.go:178      processing invite       {"nodeID": "NE_HBAZdZ8zZD7P", "callID": "SCL_SZ6iuZj4Snoo", "fromIP": "129.154.231.198", "toIP": "34.100.214.221:5060", "fromHost": "<http://fabhotels1m.pstn.exotel.com|fabhotels1m.pstn.exotel.com>", "fromUser": "+917597287863", "toHost": "34.100.214.221", "toUser": "sip-server", "sipTag": "as374d8233", "sipCallID": "<mailto:799839420c6f42cc6ae37a5c600882e2@pstn.mum1.exotel.com|799839420c6f42cc6ae37a5c600882e2@pstn.mum1.exotel.com>"}
2025-12-24T09:12:05.608Z        DEBUG   sip     sip/inbound.go:434      Rejecting inbound flood {"nodeID": "NE_HBAZdZ8zZD7P", "callID": "SCL_SZ6iuZj4Snoo", "fromIP": "129.154.231.198", "toIP": "34.100.214.221:5060", "fromHost": "<http://fabhotels1m.pstn.exotel.com|fabhotels1m.pstn.exotel.com>", "fromUser": "+917597287863", "toHost": "34.100.214.221", "toUser": "sip-server", "sipTag": "as374d8233", "sipCallID": "<mailto:799839420c6f42cc6ae37a5c600882e2@pstn.mum1.exotel.com|799839420c6f42cc6ae37a5c600882e2@pstn.mum1.exotel.com>", "jitterBuf": false}
2025-12-24T09:12:05.608Z        DEBUG   Server transaction terminating  {"nodeID": "NE_HBAZdZ8zZD7P", "caller": "transaction.Layer"}
2025-12-24T09:12:05.608Z        DEBUG   Server transaction destroyed    {"nodeID": "NE_HBAZdZ8zZD7P", "caller": "transaction.Layer", "tx": "z9hG4bK7a26.e577b9b1691d9549d8836f18de8ba962.0__129.154.231.198__5070__INVITE"}
2025-12-24T09:12:05.608Z        INFO    sip     sip/inbound.go:782      Closing inbound call    {"nodeID": "NE_HBAZdZ8zZD7P", "callID": "SCL_SZ6iuZj4Snoo", "fromIP": "129.154.231.198", "toIP": "34.100.214.221:5060", "fromHost": "<http://fabhotels1m.pstn.exotel.com|fabhotels1m.pstn.exotel.com>", "fromUser": "+917597287863", "toHost": "34.100.214.221", "toUser": "sip-server", "sipTag": "as374d8233", "sipCallID": "<mailto:799839420c6f42cc6ae37a5c600882e2@pstn.mum1.exotel.com|799839420c6f42cc6ae37a5c600882e2@pstn.mum1.exotel.com>", "jitterBuf": false, "status": 486, "reason": "flood"}
2025-12-24T09:12:05.609Z        INFO    sip     sip/inbound.go:777      call statistics {"nodeID": "NE_HBAZdZ8zZD7P", "callID": "SCL_SZ6iuZj4Snoo", "fromIP": "129.154.231.198", "toIP": "34.100.214.221:5060", "fromHost": "<http://fabhotels1m.pstn.exotel.com|fabhotels1m.pstn.exotel.com>", "fromUser": "+917597287863", "toHost": "34.100.214.221", "toUser": "sip-server", "sipTag": "as374d8233", "sipCallID": "<mailto:799839420c6f42cc6ae37a5c600882e2@pstn.mum1.exotel.com|799839420c6f42cc6ae37a5c600882e2@pstn.mum1.exotel.com>", "jitterBuf": false, "status": 486, "reason": "flood", "stats": {"port":{"streams":0,"packets":0,"packets_ignored":0,"packets_input":0,"mux_packets":0,"mux_bytes":0,"audio_packets":0,"audio_bytes":0,"dtmf_packets":0,"dtmf_bytes":0},"room":{"input_packets":0,"input_bytes":0,"mixer_samples":0,"mixer_frames":0,"output_samples":48000,"output_frames":50},"mixer":{"tracks":0,"tracks_total":0,"restarts":0,"mixes":50,"mixes_timed":44,"mixes_jump":6,"mixes_zero":3,"input_samples":0,"input_frames":0,"mixed_samples":0,"mixed_frames":0,"output_samples":48000,"output_frames":50}}}
2025-12-24T09:12:06.610Z        DEBUG   Server transaction terminating  {"nodeID": "NE_HBAZdZ8zZD7P", "caller": "transaction.Layer"}
2025-12-24T09:12:06.610Z        DEBUG   Server transaction destroyed    {"nodeID": "NE_HBAZdZ8zZD7P", "caller": "transaction.Layer", "tx": "z9hG4bK7a26.e577b9b1691d9549d8836f18de8ba962.0__129.154.231.198__5070__INVITE"}
t
Thanks — I reviewed your latest logs showing the INVITE accepted then rejected with 486 "flood" ~2s later. Since you already raised `LIVEKIT_SIP_INBOUND_RATE_LIMIT`/`BURST_LIMIT`, this looks like flood detection triggered by behavior (retries/health checks/multiple connections) or retained flood state rather than simple per-second limits. What I recommend next (short checklist): 1. Restart LiveKit SIP to clear flood state, then wait ~1–2 minutes before retesting. 2. Temporarily raise limits for testing: ◦ 
LIVEKIT_SIP_INBOUND_RATE_LIMIT: "100"
◦ 
LIVEKIT_SIP_INBOUND_BURST_LIMIT: "200"
Restart and test a single inbound call. 1. Capture SIP traffic for the failed call: ◦ Run: 
tcpdump -i any -n port 5060 -w sip.pcap
while reproducing the call. ◦ Share the pcap (or paste relevant SIP dialog) so I can see OPTIONS/INVITES/retries and timestamps. 1. Check for probing/health checks from Exotel: ◦ Ask Exotel whether they send frequent OPTIONS or probing INVITEs and whether they retry quickly on failure. If so, ask them to reduce probe frequency or use a different IP/port for probes. 1. Confirm source IP behavior: ◦ Verify Exotel’s full outbound SIP IP range used for your calls and whitelist that range in your host/cloud firewall and in 
allowed_addresses
. 1. Confirm network path/preserve client IP: ◦ If you have a proxy/load balancer/NAT, ensure real client IPs are preserved (no IPs rotating) so rate limiting is applied correctly. If you want, do steps 1–2 now and share: • The tcpdump (or SIP text of the INVITE + any preceding OPTIONS/retries) • Whether Exotel confirmed they send OPTIONS/probes and the full IP list With that capture I can pinpoint whether retries, probes, multiple source IPs, or an internal detector cooldown are causing the flood rejection and recommend the exact safe config to keep enabled in production.
4 Views
Open in Slack
PreviousNext
Powered by