'[SR-Users] Re: Evapi Async - suspend transaction for a limited time'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       serusers
Subject:    [SR-Users] Re: Evapi Async - suspend transaction for a limited time
From:       Alex Balashov via sr-users <sr-users () lists ! kamailio ! org>
Date:       2023-11-29 16:10:52
Message-ID: A10529E8-75B3-4CA9-936A-F8C9AD687360 () evaristesys ! com
[Download RAW message or body]

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.md@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 <abalashov@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 <miconda@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-leave@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-leave@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-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic