in self hosting livekit server on a vm this error occur on the sip server "jitterBuf": false, "status": 486, "reason": "flood", "stats": {"port": and the agent suddenly stopped accepting the call what is the cause of the issue and how to fix it

Thanks for reaching out, Yasser. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

does the root cause coming from livekit side or from the call center? explain in details the call center route all its calls to livekit server then livekit agent answer the calls

Thanks — I’ll explain clearly which side is responsible, why that 486/"flood" response happens, and what to check on both LiveKit and the call center so you can pinpoint and fix it. Short answer • The 486 "Busy Here" with reason "flood" is coming from the LiveKit side (the SIP gateway/agent) — it’s signaling that the LiveKit agent or gateway is refusing calls because it believes it’s being overwhelmed or is unavailable. The call center is correctly routing calls to your LiveKit server; the decision to accept or reject is being made by your LiveKit components. Why that happens (detailed) • Agent availability and dispatch behavior: ◦ LiveKit Agents act as the endpoint that accepts dispatched jobs (incoming calls). If an agent is busy, crashed, or explicitly rejects a job, LiveKit will respond that the agent is unavailable (resulting in a 486). ◦ Some configurations or versions stop dispatching jobs after a rejection (so subsequent calls are not routed to other agents) — this will make it appear like agents “suddenly stop accepting calls.” • “Flood” reason meaning: ◦ The "flood" tag indicates the SIP gateway or agent believes it is receiving too many requests in a short time (INVITEs, re-INVITEs, or other SIP transactions) or sees duplicate/rapid requests that look like a flood/DoS. ◦ That can be caused by legitimate high call volume, retransmissions/repeats due to network issues, or overly aggressive anti-flood thresholds on the SIP gateway. • Resource exhaustion or process state: ◦ If the SIP gateway or the agent process is starved for CPU, memory, or threads, it may stop processing new calls and start rejecting them. ◦ A buggy agent implementation or a state where the agent never returns to a ready state after an error can also cause repeated rejections. What to check now (practical diagnostics) 1. Agent behavior and logs ◦ Check the LiveKit agent/gateway logs around the time of 486/flood. Look for: ▪︎ Job/dispatch rejections, exceptions, or crash traces. ▪︎ Lines showing "reject" or "busy" states. ◦ Confirm whether the agent process is still running and healthy. 1. SIP traces / packet capture ◦ Capture a short pcap (tcpdump) on the LiveKit VM around the event and inspect for: ▪︎ Multiple INVITEs from the call center in quick succession. ▪︎ Retransmissions or duplicate messages that could look like a flood. 1. Metrics / VM resource usage ◦ Monitor CPU, memory, and network usage at the time of the issue to spot saturation. ◦ Check process counts and thread usage of the SIP gateway/agent. 1. Dispatch / configuration settings ◦ Check agent dispatch settings: are rejected jobs preventing further dispatching? Is the dispatch pool large enough? ◦ Inspect anti-flood/DoS thresholds on your SIP gateway. See if thresholds are too low and classify normal traffic as a flood. 1. Call center behavior (quick checks) ◦ Confirm the call center is not unintentionally retrying calls rapidly on failure (which would create a burst). ◦ Verify they are routing to the correct SIP endpoint and not sending duplicate calls from multiple upstream nodes. How to fix (concrete actions) • If LiveKit is actually overloaded: ◦ Scale agent instances (add more agents or gateway workers). ◦ Increase VM resources (CPU/RAM) or distribute load across additional VMs. • If the SIP gateway is rejecting due to anti-flood: ◦ Increase anti-flood thresholds or whitelist the call center IP(s). ◦ Apply more permissive rate limits while you tune production limits. • If network issues cause retransmissions: ◦ Fix packet loss or high latency on the path between the call center and LiveKit. ◦ Verify NAT/firewall behavior and disable or adjust SIP ALGs if present. • If an agent or job-handling bug: ◦ Restart the agent/gateway to restore service while you investigate logs. ◦ Fix the agent logic so it returns to ready state after calls complete or on transient errors. Next steps I can help with • If you share the following pieces I can give exact next commands and targeted config changes: ◦ LiveKit server and SIP gateway/agent version. ◦ A short excerpt of the SIP/gateway log around the 486/flood. ◦ A brief summary of call rate (calls per second or concurrent calls) when the issue happens. ◦ VM CPU/RAM metrics at the time (or current resource sizes). If you prefer, tell me whether you want to start with LiveKit logs or a network pcap and I’ll provide exact commands to collect them and what to look for. Sources: Why do jobs stop after agent rejection? | LiveKit | Agents telephony integration | LiveKit Documentation