Hi Sergio, On 1/16/26 12:32, Sergio Charrua via sr-users wrote: > Hello everyone! > > For future reference and to close this subject, I have resolved the > issue using the wait_idle and wait_increase parameters. While these are > documented, I believe the underlying mechanism could be more clearly > explained.
One of the great things about kamailio being an open source project is
that you can contribute to it improving, in this case, the documentation.
> Issue Summary: During testing at 1 call per minute, we observed random
> delays of 0.1 to 1.5 seconds between the EVAPI client response and
> Kamailio relaying the call.
>
> Findings:
> Debug logs (level 3) showed that the delay occurred between
> evapi_queue_add(), when the response is received and queued, and
> evapi_queue_get(), when it is fetched for processing.
>
> 2026-01-15T10:45:52.640261+01:00 ire-lab-kamailio1 kamailio[1489415]:
> DEBUG: {1768470259.772039 1489415 1 1 OPTIONS 123} evapi
> [evapi_dispatch.c:140]: evapi_queue_add(): adding message to queue
> [RESPONSE:30920:1266302652:{"action"
> 2026-01-15T10:45:53.637553+01:00 ire-lab-kamailio1 kamailio[1489416]:
> DEBUG: {1768470352.135725 1489416 1 1 OPTIONS 123} evapi
> [evapi_dispatch.c:187]: evapi_queue_get(): getting message from queue
> [RESPONSE:30920:1266302652:{"acti
> 2026-01-15T10:45:53.637930+01:00 ire-lab-kamailio1 kamailio[1489416]:
> DEBUG: {1768470352.135725 1489416 1 1 OPTIONS 123} evapi
> [evapi_dispatch.c:880]: evapi_run_worker(): processing task:
> 0x7fa97d286b00 [RESPONSE:30920:1266302652
>
> - Despite not developing C/C++ for about 30 years, reviewing the code
> (at https://github.com/kamailio/kamailio/blob/5.8.4/src/modules/evapi/
> evapi_dispatch.c <https://github.com/kamailio/kamailio/blob/5.8.4/src/
> modules/evapi/evapi_dispatch.c>), lines between 877 and 890 where a
> While loop would actively check for queued messages (at least, that is
> my understanding)
> - the loop makes use of the _evapi_wait_increase and _evapi_wait_idle
> variables, that match Evapi's module parameters waint_increase and
> wait_idle.
> - the line 890 is where the delay is generated:
>
> sleep_us(_evapi_wait_idle_step * _evapi_wait_idle);
>
>
> While this delay likely disappears under high load (our target is 1500+
> CAPS), it caused our QA tests to fail at low volumes. By setting
> wait_idle to 50ms and wait_increase to 1, the delay was reduced to a
> range of 20ms to 70ms.
>
> Thanks god Kamailio is open-source! ;)
>
> Hoping that Kamailio Dev / Docs teams won't mind, I would suggest to
> detail more the Evapi Module.
> Documentation doesn't say anything about a queue managing the responses
> from EVAPI Client. In fact, the word "queue" is only mentioned once in
> the wait_idle description, but it really is not clear, technically, why
> the queue exists or how it is handled and how to manage it.
> The Evapi Module is a fantastic tool once you understand it, as with any
> other tool (software or hardware), but it is unclear how it works behind
> the scenes.
> More low-level details about the internal processing logic would be very
> helpful for users to optimize their configuration.
>
We don't mind quite the opposite. Please create a pull request with your
desired changes.
> Hope this helps.
Looking forward to see that improvement as a pull request.
--
-----------------------------------------------------------------
| ⢀⣴⠾⠻⢶⣦⠀ Victor Seva |
| ⣾⠁⢠⠒⠀⣿⡁ [email protected] |
| ⢿⡄⠘⠷⠚⠋⠀PGP: 8F19 CADC D42A 42D4 5563 730C 51A0 9B18 CF5A 5068 |
| ⠈⠳⣄⠀⠀⠀ Debian Developer |
-----------------------------------------------------------------
OpenPGP_0x51A09B18CF5A5068.asc
Description: application/pgp-keys
OpenPGP_signature.asc
Description: PGP signature
__________________________________________________________ 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!
