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,
>
>
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
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:
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
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] {
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
