Hi,
I didnt cross my mind that I can use t_on_failure before t_suspend. I'll
try that right away. Used to writing that before t_relay every time.
Thanks,
- Jayesh
On Tue, Jul 12, 2016 at 4:50 PM Sebastian Damm wrote:
> Hello,
>
> On Tue, Jul 12, 2016 at 12:55 PM, Daniel-Constantin Mierla
> wr
Hello,
On Tue, Jul 12, 2016 at 12:55 PM, Daniel-Constantin Mierla
wrote:
> if you set t_on_failure() before t_suspend(), then you should get
> failure_route executed when the transaction timed out in suspended state.
That's exactly how it works. We set up something like this last week.
route{
Hello,
if you set t_on_failure() before t_suspend(), then you should get
failure_route executed when the transaction timed out in suspended state.
Or are you looking for something else?
Cheers,
Daniel
On 12/07/16 11:38, Jayesh Nambiar wrote:
> Hello,
> So the question fundamentally is, if I t_
Hello,
So the question fundamentally is, if I t_suspend a transaction and kamailio
sends a 408 to that leg because of the fr_timer configured, would I have
access to that response?
Thanks again.
- Jayesh
On Mon, Jul 11, 2016 at 6:26 PM Jayesh Nambiar wrote:
> Hi Carsten,
> Thanks for respondin
Hi Carsten,
Thanks for responding.
1) I basically call a t_suspend for an incoming INVITE and resume it when
the call is ready to be patched.
2) I set my fr_timer as 30 seconds as I do not want the caller to wait for
a long time to get connected.
3) So when kamailio responds back with a 408 after 3
Hi Jayesh,
you should be able to catch this in a regular failure_route(). What do
you want to achieve? Replace the response?
failure_route[myfailure] {
# Execute, in case we
# - get a local generated "408"
# - receive a 5xx or 6xx reply from the proxy.
if (t_branch_timeout() || t_
