Re: doubt using rtpengine_delete

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 <
[email protected]> 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 --
> [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!
>


-- 
Arsenii Semenov

__________________________________________________________
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!