[SR-Users] Re: Evapi Async - suspend transaction for a limited time
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 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 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
> > 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
> > 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
[SR-Users] Re: Evapi Async - suspend transaction for a limited time
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
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
[SR-Users] Re: Evapi Async - suspend transaction for a limited time
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
> 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
> 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
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to
[SR-Users] Re: Evapi Async - suspend transaction for a limited time
Hi, I use evapi_async_relay() very extensively, and can say that the transaction does time out if it goes unreplied, and relatively quickly. I haven't checked exactly which timer guides this, but it doesn't remain suspended indefinitely. I don't think that's a concern. -- Alex > On 29 Nov 2023, at 07:42, Daniel-Constantin Mierla via sr-users > 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 __ 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:
[SR-Users] Re: Evapi Async - suspend transaction for a limited time
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
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:
[SR-Users] Re: Evapi Async - suspend transaction for a limited time
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:
