Hi Ilie, Glad it worked out for you, and thank you for forcing me to take a second look at the mechanics of this for myself. You could say we both learned something. :-) Likewise thank you to Daniel for the clarity.
-- Alex > On 29 Nov 2023, at 11:08, Ilie Soltanici <iliusha...@gmail.com> wrote: > > Hi Alex, > > Thanks for your reply. Indeed, it's based on this parameter - our objective, > however, is to avoid altering the global behavior of this parameter for a > specific feature that relies on the response from evapi_async_relay. > The feature is not critical for the call at all, so in our case it makes no > sense to delay the call for about 10 seconds if, for any reason, our external > application fails to respond within the first second. > > Finally, I figured out: > > t_set_fr(5000, 1000); > > It's actually the fr_timeout I needed to change, and not fr_inv_timeout > (which I was trying initially), and that makes sense as there is no > provisional reply from the end device yet. > With this configuration, the call is relayed to the end device after 1 second > if the external application doesn't provide a reply within that timeframe. > > Thanks again for your help. > Regards, > > > > On Wed, 29 Nov 2023 at 14:25, Alex Balashov <abalas...@evaristesys.com> wrote: > Hi Ilie, > > I think the confusion is about behaviour rather than transaction reality. A > transaction suspended by evapi_async_relay() does not generate any productive > replies back to the UAC, it's true. > > But it does go away, as Daniel says. Setting an example `fr_timer` value of 4 > sec: > > loadmodule "tm" > modparam("tm", "fr_timer", 4000) > > Then placing a test call at ~14:20:05, while echoing the output of RPC > `tm.stats`: > > bash-5.1# while : ; do date; kamcmd tm.stats | grep -i current; echo; sleep > 1; done > Wed Nov 29 14:20:01 UTC 2023 > current: 0 > > Wed Nov 29 14:20:02 UTC 2023 > current: 0 > > Wed Nov 29 14:20:03 UTC 2023 > current: 0 > > Wed Nov 29 14:20:04 UTC 2023 > current: 0 > > Wed Nov 29 14:20:05 UTC 2023 > current: 1 > > Wed Nov 29 14:20:06 UTC 2023 > current: 1 > > Wed Nov 29 14:20:07 UTC 2023 > current: 1 > > Wed Nov 29 14:20:08 UTC 2023 > current: 1 > > Wed Nov 29 14:20:09 UTC 2023 > current: 0 > > Wed Nov 29 14:20:10 UTC 2023 > current: 0 > > Wed Nov 29 14:20:11 UTC 2023 > current: 0 > > If I reset the `fr_timer` value to 10 sec, we can confirm that this is the > modulator: > > modparam("tm", "fr_timer", 1000) > > Wed Nov 29 14:23:50 UTC 2023 > current: 0 > > Wed Nov 29 14:23:51 UTC 2023 > current: 0 > > Wed Nov 29 14:23:52 UTC 2023 > current: 1 > > Wed Nov 29 14:23:53 UTC 2023 > current: 1 > > Wed Nov 29 14:23:54 UTC 2023 > current: 1 > > Wed Nov 29 14:23:55 UTC 2023 > current: 1 > > Wed Nov 29 14:23:56 UTC 2023 > current: 1 > > Wed Nov 29 14:23:57 UTC 2023 > current: 1 > > Wed Nov 29 14:23:58 UTC 2023 > current: 1 > > Wed Nov 29 14:23:59 UTC 2023 > current: 1 > > Wed Nov 29 14:24:00 UTC 2023 > current: 1 > > Wed Nov 29 14:24:01 UTC 2023 > current: 1 > > Wed Nov 29 14:24:02 UTC 2023 > current: 0 > > Wed Nov 29 14:24:03 UTC 2023 > current: 0 > > I think we can also agree that the timing of the transaction reaping is a bit > "approximate". > > But equally well, it is quite true that the reaping is silent and there is no > 408 Request Timeout reply backwards to the UAC. > > -- Alex > > > On 29 Nov 2023, at 08:31, Ilie Soltanici via sr-users > > <sr-users@lists.kamailio.org> wrote: > > > > HI Daniel, > > > > That would be great if it were possible, unfortunately, the code I > > attempted doesn't seem to be working. Here's the code snippet I tried: > > > > route[TEST] { > > t_set_fr(1000); > > t_on_failure("CONTACT_LOOKUP_FAILED"); > > evapi_async_relay({"field":"value"}) > > } > > > > failure_route[CONTACT_LOOKUP_FAILED] { > > xlogl("L_INFO","Failed Transaction ID [$T(id_index):$T(id_label)]\n"); > > route(RELAY); > > exit; > > } > > > > I'm wondering if there might be something I'm overlooking? > > > > Regards, > > > > On Wed, 29 Nov 2023 at 12:42, Daniel-Constantin Mierla <mico...@gmail.com> > > wrote: > > Hello, > > a suspended transaction is kept silently for the duration of the timeout > > (see t_set_fr()), then it fails and jumps to a failure route (if you set > > one) -- maybe you can leverage this mechanism somehow. > > Cheers, > > Daniel > > On 29.11.23 12:53, Ilie Soltanici via sr-users wrote: > >> Hello, > >> > >> I'm trying to use the evapi_async_relay function from the evapi module, > >> however,I don't want the transaction to be suspended for more than 1 > >> second. > >> For instance, if there's no response from the external application within > >> this time frame, I want the script to continue and remove that transaction > >> from memory. > >> One potential approach I am considering is to add suspended transactions > >> to a hash table with a timestamp value. Then, using rtimer module, I could > >> periodically parse this table every second and process the results, but > >> I'm not sure how efficient is that. > >> > >> Maybe you know other alternative, more efficient solutions (from a > >> performance point of view) that could achieve the same goal? > >> Any insights or recommendations would be greatly appreciated. > >> Thank you. > >> > >> __________________________________________________________ > >> Kamailio - Users Mailing List - Non Commercial Discussions > >> To unsubscribe send an email to sr-users-le...@lists.kamailio.org > >> Important: keep the mailing list in the recipients, do not reply only to > >> the sender! > >> Edit mailing list options or unsubscribe: > >> > > -- > > Daniel-Constantin Mierla (@ asipto.com) > > twitter.com/miconda -- linkedin.com/in/miconda > > Kamailio Consultancy and Development Services > > Kamailio Advanced Training -- asipto.com > > __________________________________________________________ > > Kamailio - Users Mailing List - Non Commercial Discussions > > To unsubscribe send an email to sr-users-le...@lists.kamailio.org > > Important: keep the mailing list in the recipients, do not reply only to > > the sender! > > Edit mailing list options or unsubscribe: > > -- > Alex Balashov > Principal Consultant > Evariste Systems LLC > Web: https://evaristesys.com > Tel: +1-706-510-6800 > -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-le...@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: