Hello, if you watched the network traffic and the communication with the external application is very fast, then you have to investigate what action is slow in Kamailio config. You can set the latency-related core parameter and see if anyone is reported to take long to execute.
Cheers, Daniel On 13.01.26 17:36, Sergio Charrua via sr-users wrote: > Hello all, > > using Kamilio 5.8.2 with EVAPI module, connecting to a Python client. > Kamailio is using following modules: > > jsonrpcs.so > db_mysql.so > db_cluster.so > kex.so > corex.so > tm.so > tmx.so > sl.so > rr.so > pv.so > maxfwd.so > textops.so > textopsx.so > siputils.so > xlog.so > sanity.so > ctl.so > cfg_rpc.so > evapi.so > jansson.so > rtjson.so > dispatcher.so > permissions.s > app_jsdt.so > uac.so > xhttp.so > xhttp_rpc.so > dmq.so > dialog.so > htable.so > > The (very reduced) logic is: > 1 - INVITE received > 2 - send request to EVAPI client with SIP headers transformed into > JSON object > 3 - receive response from EVAPI client > 4 - depending on response type, relay the call with routes supplied in > response using RTJSON > > On its side, EVAPI Client upon receiving request from Kamailio (step #2) > 1 - sends request to HTTP REST service requesting routes > 2 - receives full RTJSON object (may include custom headers to add or > update or remove) > 3 - return full RTJSON to Kamailio as a response > > All this is working fine. *Except* that we noticed that, under testing > at 1 Call per minute (not performance testing yet), the delay betway > EVAPI step #3 and Kamailio step #3 goes anything between 200ms up to > 1.2 seconds! > EVAPI client is running on the same node where Kamailio is running > too, using 127.0.0.1:8448 <http://127.0.0.1:8448> for connection. > Knowing that there is nothing else running on the server, and that the > CAPS is like 1 call per minute, there is no load, no traffic, so why > these delays?! > > Additional settings: > # ----- evapi params ----- > modparam("evapi", "workers", 4) > modparam("evapi", "bind_addr", "127.0.0.1:8448 > <http://127.0.0.1:8448>") > modparam("evapi", "netstring_format", 1) > > Some logs: > Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949838]: INFO: > {1768314358.181270 1949838 2 1 INVITE > [email protected]} <script>: > local-response - replied locally > Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949838]: INFO: > {1768314358.181325 1949838 1 1 INVITE > [email protected]} <script>: HANDLE_INVITE > - suspended transaction 5701 - Label: 625621129 > Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: > {1768314358.761888 1949871 1 1 OPTIONS 123} <script>: Part 0: 'RESPONSE' > Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: > {1768314358.761928 1949871 1 1 OPTIONS 123} <script>: Part 1: '5701' > Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: > {1768314358.761936 1949871 1 1 OPTIONS 123} <script>: Part 2: '625621129' > Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: > {1768314358.761943 1949871 1 1 OPTIONS 123} <script>: Part 3: > '{"action": "ROUTE", "routes": ... > Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: > {1768314358.762018 1949871 1 1 OPTIONS 123} <script>: > evapi:message-received - t_continue for 5701/625621129 > Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: > {1768314358.762078 1949871 1 1 INVITE > [email protected]} <script>: EVAPIRESPONSE > - TRANSACTION 5701|6256 > Jan 13 14:25:58 bl1642 /usr/local/sbin/kamailio[1949871]: INFO: > {1768314358.762089 1949871 1 1 INVITE > [email protected]} <script>: EVAPIRESPONSE > - Resumed with RESPONSE ... > > Above, we can see that Kamailio sends a request to EVAPI client > at 1768314358.181325 and response is received by EVAPI client > at 1768314358.761888, about 600ms later, which is too much! > On the other hand, EVAPI client takes less than 20ms to receive the > request, query REST service and reply back to Kamailio. > If there were anything else between Kamailio and EVAPI client, I would > probably assume there was some network delay somewhere, but both > services are running on the same server, which is mostly idle, so no > network delay can be found. > I even captured packets with tcpdump , on port 8448, and indeed, > communications between Kamailio and EVAPI client is like 20 to 30ms max! > So, why Kamailio is taking between 500ms to 1sec to process > the response received from EVAPI client? at least, this is what it > seems doing.... > > Any clue? Any advice? > > Greatly appreciated. > > Atenciosamente / Kind Regards / Cordialement / Un saludo, > > * > * > > *Sérgio Charrua* > > *www.kahea.ai <http://www.kahea.ai> / www.voip.pt <http://www.voip.pt>* > > *OpenTelecom* - Consulting for Telecoms, Lda > Tel.: +351 <callto:+351+91+104+12+66>91 631 11 44 > > Email : *[email protected]* > > This message and any files or documents attached are strictly > confidential or otherwise legally protected. > > It is intended only for the individual or entity named. If you are not > the named addressee or have received this email in error, please > inform the sender immediately, delete it from your system and do not > copy or disclose it or its contents or use it for any purpose. Please > also note that transmission cannot be guaranteed to be secure or > error-free. > > > > > > > > > __________________________________________________________ > 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! -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio World Conference, May 7-8, 2026 - Berlin, Germany -- kamailioworld.com
__________________________________________________________ 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!
