Re: EVAPI processing delays

Victor Seva via sr-users <[email protected]> Wed, 21 Jan 2026 15:52:23 +0000
Newsgroups	gmane.comp.voip.ser
Message-ID	<[email protected]>
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 |
   -----------------------------------------------------------------

__________________________________________________________
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!
OpenPGP_0x51A09B18CF5A5068.asc (application/pgp-keys, 18.3 KB)
OpenPGP_signature.asc (application/pgp-signature, 235 B)