**Hi Kamailio Community,**

I am experiencing an issue with delayed SIP processing and dropped packets 
under high load, and I would appreciate some advice on tuning or architecture.

**Environment & Setup:**
*   **Kamailio:** v6.1.2
*   **RTPEngine:** ngcp-rtpengine 13.5.1.3+0~mr13.5.1.3 (using kernel module 
`table=0`)
*   **OS:** Debian 13
*   **Hardware:** 56 CPU Cores (Note: Kamailio and RTPEngine are running on the 
*same* physical server)
*   **Kamailio Config Snippet:** `children=40`, `tcp_children=40`

**The Scenario & Symptoms:**
The system handles traffic coming from FreeSWITCH. When the concurrent calls 
(CC) reach around 3000, we start observing two major issues:

**1. RTPEngine UDP Queue Warnings:**
We frequently see the following warning in the RTPEngine logs:
`Too many packets in UDP receive queue (more than 50), aborting loop. Dropped 
packets possible`

**2. Kamailio missing SIP packets (Silent Drops):**
FreeSWITCH sends an `INVITE` to Kamailio. When I capture traffic with 
`tcpdump`, I can see the initial `INVITE` arriving at the server's network 
interface, followed by several retransmissions. 
However, Kamailio (verified via the `sipdump` module and xlogs) does not seem 
to receive the initial requests. It often only registers the `INVITE` on the 
4th or 5th retransmission.

**3. Latency checking:**
To check if the Kamailio routing script is blocking, I enabled 
`latency_cfg_log=1`. The logs show acceptable execution times during this 
high-load period:
`NOTICE: request-route executed in: 18510 usec` (~18.5ms)

**My Questions:**

1.  Since `tcpdump` sees the packets but Kamailio doesn't, is this a classic 
case of OS-level UDP receive buffer (`rmem`) overflow, possibly exacerbated by 
CPU context switching between Kamailio and RTPEngine?
2.  With `children=40` for Kamailio and RTPEngine also running on the same 
56-core machine, is this configuration leading to significant CPU contention or 
an imbalanced distribution of workload, especially at 3000 CC? Should 
Kamailio's `children` count be adjusted (e.g., increased closer to 56, or 
perhaps fewer to leave more for RTPEngine and OS network processing)?
3.  Does this scenario typically imply that the host CPU is 
exhausted/interrupt-bound, or is there a specific Kamailio/OS tuning I am 
missing?

Any insights or recommendations on how to further debug this would be greatly 
appreciated!

Thanks,
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- 
[email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the 
sender!

Reply via email to