Re: doubt using rtpengine_delete

Regards
Tola
Sent from my iPhone; please excuse any typos.

> On Mar 25, 2026, at 11:56 PM, 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!

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