hey David,

rtpengine has plenty of parameters for fine tuning, depending on the VM resources where it runs.

regarding the UDP Recv-Q can you confirm mb with the logs, whether this is only queue congestion or rtpengine is actually failing to keep up and causing dropped or timed-out control commands?

imo a high Recv-Q on the control socket by itself does not automatically prove rtpengine is at fault, to conclude that there is an actual issue with rtpengine i'd suggest to collect some evidence: missing replies, timeouts/retries on the network and CPU resources starvation.

As for the "query" as I know this is distinct operation from the "delete".

Arsen

On Thu, Mar 26, 2026 at 7:58 AM David Escartin Almudevar via sr-users < sr-users@lists.kamailio.org> wrote:

Hi,

We are observing an unexpected behavior when using Kamailio together with rtpengine and would like to understand if this is expected or if there is a way to control it.

Environment:

Kamailio version: 6.0.4 rtpengine version: 12.5.1.48 (mr12.5.1 branch) Transport: UDP NG control socket Observation:

...

From the rtpengine logs, we consistently see that every delete command is

preceded by a query command for the same call, coming from the same Kamailio instance and even the same source port.

Mar 19 08:51:05 mia-rtpengine-6 rtpengine[109401]: INFO: [SD7kus901-8c2067aa09bf3bfafd4b18ca3df0eeb9-v300g00010]: [control] Received command 'query' from 192.168.9.56:49983 Mar 19 08:51:05 mia-rtpengine-6 rtpengine[109401]: INFO: [SD7kus901-8c2067aa09bf3bfafd4b18ca3df0eeb9-v300g00010]: [control] Replying to 'query' from 192.168.9.56:49983 (elapsed time 0.000043 sec) Mar 19 08:51:05 mia-rtpengine-6 rtpengine[109401]: INFO: [SD7kus901-8c2067aa09bf3bfafd4b18ca3df0eeb9-v300g00010]: [control] Received command 'delete' from 192.168.9.56:49983 Mar 19 08:51:05 mia-rtpengine-6 rtpengine[109401]: INFO: [SD7kus901-8c2067aa09bf3bfafd4b18ca3df0eeb9-v300g00010]: [control] Replying to 'delete' from 192.168.9.56:49983 (elapsed time 0.000036 sec) We are not explicitly calling rtpengine_query() anywhere in our Kamailio configuration. Our usage is limited to rtpengine_offer(), rtpengine_answer(), and rtpengine_delete().

Is this query before delete expected behavior (e.g. implicitly triggered by rtpengine_delete() to retrieve statistics)?

If so, is there any way to disable this behavior so that rtpengine_delete() does not trigger a query?

related issue ?¿ Seems under high load conditions, we have observed that the NG control socket (UDP) occasionally becomes congested. For example, we have seen cases where the rtpengine server receive queue (Recv-Q) for the control socket grows significantly (hundreds of thousands of bytes), indicating that rtpengine is not draining the socket fast enough.

ss -lunp | grep 7772 UNCONN 214272 0 192.168.9.129:7772 0.0.0.0:* users:(("rtpengine",pid=3320,fd=9)) this issue could have some relation with an overload of control commands, in some particular scenarios if we have these parameters set for rtpengine instances selection?

modparam("rtpengine", "queried_nodes_limit", 2) modparam("rtpengine", "rtpengine_retr", 2) modparam("rtpengine", "rtpengine_tout_ms", 350)

Thanks in advance for your help. David Escartín __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!

On 26/03/2026 02.32, David Escartin Almudevar via sr-users wrote:

Is this query before delete expected behavior (e.g. implicitly triggered by rtpengine_delete() to retrieve statistics)?

No, they're two different and distinct methods. The only exception is access of $rtpstats/$rtpestats, which implicitly triggers a "query."

Seems under high load conditions, we have observed that the NG control socket (UDP) occasionally becomes congested. For example, we have seen cases where the rtpengine server receive queue (Recv-Q) for the control socket grows significantly (hundreds of thousands of bytes), indicating that rtpengine is not draining the socket fast enough.

Very likely this is unrelated and usually points towards some sort of resource shortage. If it's not CPU or memory (swapping), another possibility is stalling when doing external I/O, such as talking to a slow Redis instance or a slow logging system holding up operation.

Cheers