On 01.11.2022 17:12, Conrad de Wet wrote:
This works, except I want to extend this even further. I want these 4
branches to keep trying on a loop until the transaction timeout occurs
or one of the calls is answered. Except I find that the
“failure_route” has two main problems, firstly if I try a “t_relay()”
in the failure_route, the original call gets relayed again and I can’t
seem to refer back to the branch.
This causes the number of branches to quickly run out (I think max is
16), as it seem to nest the branch. Also because the t_relay() appears
to act on the main branch, all the urls are reset, so I don’t really
know where I was originally sending this request to.
failure_route[my_on_failure]{
seturi($branch(uri)); # <-- This is null
t_relay(); # causes new branches that don’t seem to
kill the old ones.
}
Hi, Conrad!
Re: the confusion around failure_route: the failure route callback
actually means a "failure to relay", not a "failure of a specific
branch". So no matter how many branches you attempted to relay in
parallel (1, 2, 8, etc.), it means they *all* failed (some explicitly
with, e.g. a 404, others implicitly with a 408 internal timeout). So
now you're in this callback and you're only given the original
Request-URI of the message, with an opportunity to build a new set of
branches to relay (optionally with a new failure route callback), or
just give up and pass the error message back upstream.
On topic: I'm assuming the need to "keep trying these branches in a
loop" stems from the fact that the "lookup()" operation may produce
different results throughout the duration of the call attempt. So
instead of having a long transaction timeout, you prefer to have a
shorter one and keep redo'ing the "failure_route + lookup()" loop in
hope that the WS device comes online, correct? If so, you may indeed
often run into the "max branches exceeded" limitation quite easily this
way, at least with how the code currently works...
Possible cheap workaround: recompile with a larger MAX_BRANCHES (say, go
from 12 to 31). At least you may get your PoC working this way and move
to solving other problems. Medium-term, maybe we can look into
developing some support for creating lots of branches in the "master"
OpenSIPS tree.
Best regards,
--
Liviu Chircu
www.twitter.com/liviuchircu |www.opensips-solutions.com
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
